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

Scott,

I think it is great that you and Claudio think this is all pretty
simple. As much I as I wish you were right, the problem is that neither
of you are the ones withholding approval for this document.

If this were all that simple, then I'm sure Ted could have supplied me
with the detail I requested.

So let's take Claudio's attempt to guess at what will satisfy the IESG:


>> I would suggest an applicability statement, which uses ifax
>> as one of the 
>> examples, but also points out the other ones, but indeed is

"the" other ones?  what does that mean?

What is the set of other scenarios that is expected? How can the working
group know if it is sufficiently extensive to be considered complete by
the IESG?

And for reference, I'm not being pedantic or whimsical here.

As someone who has worked on this topic for quite awhile and gone
through the extensive development process of the ESMTP Conneg
specification, I honestly have no idea what the answers to these
questions are. And it strikes me as rather risky to have us have to
guess.


>> built upon the 
>> generic case considerations, i.e.:
>> 
>>     - the mechanism requires that no "transformations"
>>       (gateways, security checks, ...) are in between the negotiating
>>       parties;
>>     - the store/forward limits the applicability, and list the cases
>>     - ...
>> 
>> This will also likely avoid furhter doubts for implementers, and 
>> nevertheless let CONNEG be of good use for the whole e-mail system.
SH> That's it.

Yes, indeed.  Sounds simple.

Here's the problem:

There are 3 bullets to that list.  Unfortunately, I don't really understand the
first two, and the third is an ellipses.

1. That means the rest of the bulleted list is unspecified.

2. I do not understand why the fact that no transformations are "required"
constitutes a "generic case consideration" nor do I understand the
implication of that view.

3. I do not understand what it means to say that store/forward limits
applicability.  And, again, I do not know what "the" cases are.

Perhaps someone else does know what the necessary details are. I would
certainly have hoped that the AD lodging the veto would have been able
to elucidate these points. Since he hasn't, how can any of the rest of
us?


SH>  As I see it, we're talking about a subsection, maybe in the
SH> intro, with a few new paragraphs.

Perhaps you are right.  How can we be sure, without going through an
open-ended process of guessing and being told we haven't got it right
yet?

In other words, how can the working group KNOW what should be in those
paragraphs?

Let ME try to make this simple:  The IESG needs to specify exactly what
it is requiring.  Not have the working group chair guess and then have
one AD say "as I see it" the guess is correct.  I mean we need enough
specificity to KNOW what will get the document published.

As things stand now, the IESG is blocking these documents but will not
provide concrete detail instructing the working group how to remove the
block.

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>