Re: draft-ietf-fax-esmtp-conneg-10.txt

Howdy,
	Some responses in-line.  There are several places in the text
below where I ask the working group as a whole for responses.  While
I am more than happy to be cc'ed on individual responses, I will rely
on the chairs to indicate their call of the rough consensus.
			regards,
				Ted Hardie


At 4:56 PM -0700 7/22/04, Dave Crocker wrote:
>Ted,
>
>
>TH> Apparently there has been some miscommunication on
>TH> the DISCUSS position I entered for this draft.
>
>MANY thanks for contributing to this exchange.  It's always useful to
>get source material...
>
>
>TH> working group; after a few rounds Scott and I asked the Chairs to take
>TH> the issue to the working group, as the scope of the discussed 
>fixes would need
>TH> WG approval.
>
>Consulting the working group is, of course, fine.

And as I noted, you were meant to be given a pointer to that venue
as the place to continue this discussion; I've already apologized that
it did not happen, and I am glad now to see your concerns voiced
in the working group context, since the whole working group must
come to rough consensus on the result.

>
>TH> raised.  Dave agreed that a reference to the OPES docs would be useful,
>
>Given the difficulties obtaining clarity in this process, I must take
>exception to your assertion.
>
>I think that incorporating the analytic _concerns_ of the OPES work is
>useful, not the addition of a citation to OPES. We incorporated the
>concerns long ago. In fact I believe there is no significant utility to
>the citation, but it does not hurt anything to add it. It does, however,
>hurt things to have our interactions misunderstood.

Very well; does the rest of the working group concur that the analytic
concerns of the OPES working group have been incorporated?

Does the rest of the working group concur that a citation does no harm?

>
>TH> but does not see the need for any text elucidating the mechanisms in this
>TH> light.
>
>The specification has an obligation to be clear.  It does not have an
>obligation to include a tutorial on a general topic.   In fact such
>material is more likely to distract the implementor.

And we obviously differ on exactly how much text it would take to
be clear.   The community has expressed concern about this topic,
and we have a published RFC which goes to significant lengths to
describe the issues.  The OPES working group, writing on a related
topic, went to similar lengths to explain to the community how
they addressed the concerns.  I have not asked the group to
write a separate document; I have asked the group to consider
how to tell the community that it has incorporated those concerns
in its design.

To make a parallel:  the community decided a long time ago that
congestion control was a concern for any protocol that was deployed
on the Internet.  If you wrote an IETF specification for a protocol
without such congestion control, text explaining why congestion
control was not required would be expected.  This is not tutorial
(and I have no idea why you think of tutorial as a pejorative); it is
communication with your colleagues about the applicability
and characteristics of the protocol you've specified.

Since, as you have repeatedly said, the working group did consider
and incorporate these issues, I don't understand the reluctance
here, and I have to ask:  does the rest of the working group concur
that inclusion of this text would harm the specification?

>
>TH> The "copy of a copy" problem I mentioned above might be
>TH> better called "transform of a transform".  ...
>TH>   I did not see a way around that problem with the
>TH> mechanisms provided nor did I see a description of it for those who might
>TH> deploy this mechanism.
>
>That's why I said that adding a generic reference to the issue is
>reasonable.

Okay.  Does the rest of the working group concur that including
such a generic reference to the issue is reasonable?


>
>TH> The third issue was around whether the group was using the
>TH> standard SMTP methods for recipient splitting or using new methods; Dave
>TH> has assured me that the standard mechanisms are intended.
>
>Not "intended", Ted.  The specification has no "intention" to modify or
>comment on standard SMTP practise. And, indeed, is therefore has no text
>on the matter.
>
>It does not help a specification to includes text saying all the things
>it is NOT specifying.
>
>This is, apparently, another example of your wanting tutorial text on
>SMTP basics in the specification.
>
>TH> An explicit pointer to them in the text might be useful, but I am
>TH> happy to drop the point.
>
>Thank you.

To confirm:  does the rest of the working group concur that no new
text is needed on this issue?



>
>TH> The last issue is that the document does not describe how the
>TH> SMTP service gets CONNEG data in the first place (even at the example
>TH> level),
>
>You have yet to explain why a specification for a couple of components
>for an overall service is expected to describe the rest of the service.
>
>For that matter, Ted, was there something incomplete or inaccurate about
>my own response to the hypothetical scenario that you sent me before?
>
>
>TH> Since there is no description of which system is expected
>TH> to be the point of injection, there seems to be a possibility 
>that MTA3 might
>TH> get a direct injection via relationship with MUA2 and also data 
>from the MDA.
>TH> What does it do in that case?  A mention of the problem in the text would
>TH> be valuable, and at least *a* solution (though not necessarily the
>TH> only solution)
>
>Really?  It helps to have a specification for one part of a system
>provide a partial specification to another part of the system that
>really should be done fully in an independent effort?

It is not clear from the above whether you object to the inclusion of
the problem in the specification, so I'll pose the question in a slightly
different way:  does the working group as a whole concur that
including a statement of this problem in the text is acceptable?

I assume you are not proposing an independent effort to specify
the rest of the system.  If the problem is clear and the working
group chooses to say that the solution is not stated, I think
the spec will be clear; I personally believe, however, if you know
a solution or a system in which this works writing it down
does no harm and might do good.


>This is an example of the slippery slope that bloats a specification
>with material that is frankly out of its scope.
>
>
>TH>  I have suggested that
>TH> Experimental status might be appropriate,
>
>And it might not.
>
>It would help if you responded to my observation that this mechanism
>does not create any new capabilities for mis-behavior.
>
>Intermediaries can (and do) already mess things up.
>

You could argue that the existence of the monkey in the middle
attack obviated the need for any specification of intermediary
behavior, since the monkeys in the middle have free reign.
But it would be somewhat strange.

If we don't understand how this is expected to work on the
Internet, we should say so to the community in some fashion.
Experimental would say so.  An applicability statement
that lays out where you do expect it to work and says "terra incognita"
over there does the same.  More importantly, it goes past
Experimental to confirm that there is a known territory.


>TH>  I have also suggested using an applicability
>TH> statement (essentially, porting Appendix A to that role)
>
>Appendix A is a tailored technical specification, not an applicability
>statement.
>
>And you have not actually said what needs to be in the applicability
>statement or why.
>
>For example, to know how to constrain applicability, it is necessary to
>have a description from you of the mis-applications of this mechanism
>that are to be avoided.

I am at a loss to understand this view of an applicability statement.
"This works here in the following way" (which is one way of looking
at the direct smtp text in Appendix A) followed by "other uses
may be possible, but require supporting mechanisms which have
not yet been specified and may not be interoperable across implementations
or deployments" certain seems like an applicability statement to me.

Does the working group as a whole concur that the inclusion of such
an applicability statement would be harmful?

>Please note that I have been asking you for such detail.
>
>
>TH>  Dave
>TH> seems concerned that I have not made what it takes to satisfy 
>the issue--any
>TH> of the above would.
>
>And that is why I have bothered to re-hash my detailed points about the
>_lack_ of sufficient detail from you.
>
>Forgive me, but none of "the above" that you cite actually has much
>substance with respect to the specification. So responding to it is
>really an effort at guessing.

Since we have now traded some hundreds of lines of email on this
topic, Dave, I think it would be fairer to say it as an effort at 
communication.

Sorry you don't see it that way.

>
>TH>  If the working group chose to make no changes, I would
>TH> suggest an IESG note highlighting the issues before publication
>
>Or you could write the text now, thereby showing us what will satisfy
>you, and then the working group can decide whether to include it.  (I'll
>make a prediction that the answer will be yes.)
>


The working group does not decide whether to include an IESG note.
If I wrote one (and I hope it does not come to that), it would include
the fact that the working group decided not take other actions.  Until
the working group decides to take no action, I will not write one.

Does the working group concur that it should take no action with
respect to this document, preferring an IESG note be added documenting
the IESG concerns?

>TH> ; that might or
>TH> might not be the consensus  position of the IESG if I proposed it.
>
>If there is anyone else on the IESG who share your specific concerns,
>they have not voiced them.

Several agreed with these points during the call, but felt that I 
should hold the
DISCUSS.  If you would like me to ask them to put in their own
DISCUSSes, I'll talk to Scott about it.  But it isn't normal procedure
because it slows things down.  Given that there are already other unrelated
discusses, though, I am surprised that you feel that this would be
a good course of action.


>I offered text intended to respond to the concerns documented from other
>ADs and have not yet been told that those formulations are unacceptable.
>

I assume you mean Steve and Alex; perhaps Scott can help you work
with them (and Joel, whom Alex had review the doc) on those issues.

			regards,
				Ted Hardie


>
>d/
>--
>  Dave Crocker <mailto:[email protected]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>