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

[Dave Crocker <dhc@xxxxxxxxxxxx>]

Folks,

I'd like us to bring the working group to a close. The IESG directive
is delaying that. Given that ESMTP Conneg is a normative reference is
FFPIM, it means that that document, too, is delayed from publication.

As Claudio notes, it is entirely up to the working group to decide
this matter.  I am sending this note to make sure the working group
has more background about the concern with the IESG.


CA> While the CONNEG mechanism was invented inside the specific ifax scenario
CA> as an applicability area, it is also clear that other areas can use it,
CA> and its protocol definition is NOT tied to ifax only.
CA> I would suggest an applicability statement, which uses ifax as one of the
CA> examples, but also points out the other ones, but indeed is built upon the
CA> generic case considerations, i.e.:
CA>     - the mechanism requires that no "transformations"
CA>       (gateways, security checks, ...) are in between the negotiating
CA>       parties;
CA>     - the store/forward limits the applicability, and list the cases
CA>     - ...
CA> This will also likely avoid furhter doubts for implementers, and
CA> nevertheless let CONNEG be of good use for the whole e-mail system.
CA> Do you agree to this proposal? It is the WG who has to accept it... and of
CA> course who has to help the editor(s) in making the job.

I was conducting an offline exchange with Ted Hardie, in an effort to
resolve his concerns about the ESMTP Conneg specification.

I was not able to understand what _specific_ technical concerns he has
with the specification or with the ability of an implementor to
understand how to deliver the ESMTP Conneg capability.

The feedback from the IESG continues to lack this specificity: Quite
simply we do not have any way of knowing _exactly_ what will satisfy
the them.

I noted this basic process management problem in my communication to
Ted. Apparently he and the IESG do not see this as an issue.

Adding a bit of qualifying text to a specification probably does not
do much harm to it. On the other hand, there is no evidence that it
helps, particularly when the text is not responding to a known,
specific problem.

Further, it is always clear that an IESG intervention like this adds
an unknown amount of delay to the process. There is plenty of IETF
history to substantiate that assessment. Not always, of course. But
that is my point. We have no way of knowing exactly what will resolve
the IESG's concern. Their requirement to us is open-ended.

Claudio's note is optimistic that the addition of some text will fix
the IESG's concern. My own doubt is that we must guess what will
satisfy them. If we guess incorrectly, we get to guess again.  And
again.

In the interest of that completeness, I am including a copy of the
last note that I sent to Ted.  It received no response.


d/
--
 Dave Crocker <mailto:dcrocker@xxxxxxxxxxxxxxx>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>


 - - - -

Date: Thu, 15 Jul 2004 21:05:25 +0800
From: Dave Crocker <dcrocker@xxxxxxxxxxxxxxx>
To: Ted Hardie <hardie@xxxxxxxxxxxx>
CC: Scott Hollenbeck <shollenbeck@xxxxxxxxxxxx>, tamura@xxxxxxxxxxxxxxxx, Claudio Allocchio
<Claudio.Allocchio@xxxxxxx>, Graham Klyne <GK-lists@xxxxxxxxxxxxxx>, Pete Resnick <presnick@xxxxxxxxxxxx>
Subject: Re: IESG Review: draft-ietf-fax-esmtp-conneg-10.txt

Ted,

I have re-read your notes and my responses (including this note) and
decided to modify the distribution list to simplify the dynamics, at
this stage.

I am concerned about your comments. Frankly, they seem to me to be
quite vague, they appear to express no technical basis for assessing
protocol specification weaknesses, and the requirements for satisfying
your concerns seem pretty open-ended.

At base it is sounding as if you have some general discomforts rather
than technical or operational criticisms.

ffpim-06 has been submitted.  Please look it over.

If you still feel that changes are needed, please provide some
candidate text.

With respect to your specific comments:


TH> Scott Hollenbeck and I had a chance to chat about this early today,
TH> and one question which came up was using Experimental
TH> RFC status for this document, rather than trying to write an
TH> applicability statement.  If, as you say, there is no clear
TH> set of use cases or sense of where the dragons lie, an Experimental
TH> RFC with a later revision that did include the results of
TH> initial experience might be useful.  I had assumed from the
TH> existing text that the directly connected Internet fax case
TH> was the primary use case (and certainly would be *a* use case), but
TH> if the intent of the larger project is to map out this territory,
TH> Experimental might make sense.

I believe the risks are documented well enough. I believe the Direct
mode is merely one use case, and I think it is sufficient to document
it, since it is the use case that motivated the work.

My response to you was commenting that you made an open-ended request
which I could not know how to satisfy.

If we, ourselves, had felt the need of documenting additional use
cases, rest assured that we would have done that. But we didn't and I
believe we still do not.

Since you are uncomfortable with this capability, it would help if you
stated what details about the specification worry you. And I mean
stating them as technical concerns to which there can be technical
responses, either explaining how they do not apply in this case or how
they can be fixed.

Please remember that this mechanism does not really create a new
exposure. Yes, it passes information that was not being passed before,
but the information is about sender desires, and about recording
changes that have been made. That is all. (Sending the capabilities of
the recipient has already been standardized, so ESMTP Conneg is merely
adding a new channel for passing that information.)

However, intermediaries have always been able to do whatever they
want.  So telling them the desires of the originator hardly
constitutes an increase in risk.

This specification has undergone lengthy development, review and
revision.  I mean really.  I don't just mean lots of time passing.

If you have concrete technical criticisms of it, I am not
understanding what they are.


TH> There is a difference, at least to me, from saying "you must be
TH> this tall to implement this spec", which does sound paternalistic,
TH> and "we built this tool for this purpose and that drove the following
TH> design choices;

And there is a difference between specifying a capability, versus
telling people how to use it, versus telling people what the
underlying design rationale was.

The first is what a specification must do, of course.

The second is sometimes helpful as an advisory, if there is concern
that users might be unsure how to use it. The third is sometimes
helpful if there is concern that the implementors will not understand
the details of the specification or to counter potential resistance to
adopting the specification.

We have neither of those concerns for this specification.

And a treatise about design rationale is useful for educational
documents, but is hardly a common requirement for IETF specifications.


TH> if you are using it for some other purpose, you
TH> might want to check if the same design constraints apply".

I am tempted to wander down a number of different paths, such as
noting that that stricture always applies to all specifications.

However I'll leave it at this: Is the specification imprecise or
incomplete? Are the capabilities of the specification unclear? Is
there a basis for knowing that it won't work or that it will cause
problems for the Internet?

I believe the answer to all of these questions is that the current
specifications satisfies the IETF's requirements for Proposed
Standard.

Consequently I believe that the line of concerns you are raising have
to do with your comfort level, rather than with technical or
operational weaknesses of the specification. While I can more than
sympathize with the discomfort, I am not understanding the technical
or operational basis for delaying publication of the specification.


TH>  That
TH> may be pedagogy, but it is also useful context for those
TH> implementing the spec and those reading it outside the original
TH> working group context.

Useful?  How, exactly?

I am not aware of this being something that is typically required of
IETF specifications. Nor do I think it should be. Hence what makes it
appropriate for you to require it here?


>>TH> There is no citation of RFC 3238, and I do not see any discussion of the
>>TH> issues it raises in the text.
...
>>As noted above, adding a citation is not unreasonable.
TH> The citation will help.

The citation has been added to the draft I just submitted.


TH> So, are the protocol mechanisms in place sufficient to indicate
TH> that a transformation has already occurred?

>From the conneg specification:

     A record of conversions is placed into MIME Content-Previous headers.


>>>>SH>  the document
>>>>SH> permits a message intended for multiple recipients to be split according
>>>>SH> to the capabilities of the recipients and fails to specify whether the
>>>>SH> recipient
>>>>SH> list is retained or split;
>>>>
>>>>In what ways is "Each version is then sent separately, to an
>>>>appropriate subset of the recipients" unclear, imprecise, inaccurate
>>>>or incomplete?
>>
>>TH> I send a message to foo@xxxxxxxxxxx, bar@xxxxxxxxxxx, and baz@xxxxxxxxxxxx
>>TH> The message is split according to the capabilities, and one 
>>message is sent
>>TH> to bar@xxxxxxxxxxx, and a different message sent to foo@xxxxxxxxxxx, and
>>TH> baz@xxxxxxxxxxxx  What in the split message to bar@xxxxxxxxxxx shows the
>>TH> original recipient list included foo and baz?
>>
>>Huh?  The TO and CC fields show the recipient list specified by the
>>originator.  The RCPT-TO list contains the current subset.
>>
>>There is nothing unusual about this disparity. In fact it is at the
>>core of the aggregation/dis-aggregation methodology of Internet mail.
>>It is, in fact, why the distinction between envelope list and message
>>content address list is essential.
>>
>>So if I've missed your point, please clarify.
>>

TH> It wasn't clear to me that this was the method you were using.  Again,
TH> with new territory (content transformation), I could imagine other strategies
TH> and other problems (some already evident in some back-to-back user
TH> agent deployments).  A simple statement that this is all that is going
TH> would solve this problem.

Ted, I'm sorry.  I still have no idea what you are talking about.

Again you hint at complexities and possibilities but I have no idea
what they are.

Also please note that I asked you to explain what was insufficient in
the cited specification text, but you did not do that.

This is an email-related spec that is doing nothing to change or add
to basic email transfer. So while you might be able to imagine some
things, I do not know what they are.


TH> <elided text discussion of larger system/how servers get information>
>>
>>Why?  How does this affect the normative specification.
TH> Let's say we have a simple system:
TH> MUA1--MSA--MTA--MTA2--MDA--MUA2
TH> If the User discloses CONPERM information via MUA2 to the MDA
TH> and the MDA  discloses it as a walk up the single line, we have one
TH> security story.  If MUA2 discloses it directly to MTA2 , we have a different
TH> security story.   The text you're responding to read:
TH> "the document punts completely how the SMTP service
TH> gets the CONNEG data in the first place, putting a critical part of the
TH> security story out of reach."

TH> Perhaps badly, I was trying to get out not just that the mechanism wasn't
TH> specified, but that the actors/network elements using the mechanism
TH> don't seem to be.  That makes it hard even for local policy to be set.
TH> While you seem to be discouraging any non-normative text, I believe
TH> that some example of how to deploy it so it works would be useful,
TH> even if that is not the only way it can work and is clearly marked as such.

Indeed, such discussion of usage and operations often is extremely
helpful and I think it would be a fine thing for someone to write such
a document. However it has little to do with the technical
specification of other components of the system.

Apparently, you are quite worried that something bad will happen in this
unspecified portion of the service.  Hence you apparently want such
details resolved before you are comfortable with having this component
(or set of components) published.

Let's generalize this model:  We get no SMTP until we have also
specified POP (and maybe IMAP) and, of course, ACAP, and...

We get no Internet infrastructure until we have published BGP, OSPF,
ARP, and...

And so on.

Yes, it would be delightful to have all the components of a
potentially large and complex system be fully specified before
deploying any one of the components. OSI, for example, was wonderfully
successful with that approach. (Come to think of it, IPv6 has been
doing an excellent job of showing us the benefits, too. We are at 10
years and still awaiting a critical mass of deployment.)

And if it wasn't clear why I pruned the distribution list before, I
suspect it is now.

And I really would like to end with something that at least tries to be
upbeat, shows I'm willing to be flexible, etc. etc.  But this is not
about my inflexibility, even if I have moved into a full-fledged rant.

The problem is that after two iterations with you, I have not seen a
single technical criticism. What I have seen is generic concerns that
can (and are) expressed by lots of us about lots of systems.

The concerns are all reasonable.  Having them be the basis for
delaying publication is not.

No doubt others will moderate my excesses about this.

d/
--
 Dave Crocker <mailto:dcrocker@xxxxxxxxxxxxxxx>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>