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

[Dave Crocker <dcrocker@xxxxxxxxxxxxxxx>]

Ted,

Thanks for the followup.

Just so no one gets confused:  I'm responding on my own initiative and
with my own opinions, but of course any editorial decisiona belong to
the working group.

(additional disclaimer: i've got constrained access and schedule right
now, so what follows is written more quickly and with less review than
I would prefer.)


TH> Would you consider putting this forward with an applicability statement
TH> that described in more detail the use cases for which this was
TH> expected to be useful and the cases in which it is not expected
TH> to be useful?

If I thought that we were really certain of the use cases, and certain
of what would correctly and completely cover their analysis, then this
might make sense.

However...

There are always unknowns with using a mechanism that explores new
territory.  Conperm/Conneg certainly does that and, therefore, warrants
concerns.  The combined mechanisms are frankly more complicated than I
would have liked, but they are simple as we could make them while
dealing with the requirements for originator and recipient
communications to the unknown intermediary.

Because it is new, there are no experts. So I think it is useful for a
specification to mark the boundaries of what is significantly new and,
therefore, might carry unexpected consequences.

However I think that attempts to have a specification include analytic
treatises about that new territory are not very helpful.  I think
their real purpose is to make us feel as if we have duly warned the
naive reader, but frankly that is a bit paternalistic.   After all, it
is not as if we know for certain what the real dangers are.

So I'm afraid that I think the actual effects of adding significant
amounts of cautionary analysis are to make the document bigger, to
distract the implementor with material that is not needed for
implementing, and to delay issuing the specification.

Let me comment about the 'distraction' reference:  Most of the
cautionary analysis really deals with strategic issues about using the
specification.  However it is rare that those making the strategic
decisions read the specification.  Worse, they either already know
that the specification covers new territory or, I suspect, they have
other business concerns that dominate.

All of that notwithstanding, I certainly agree that the fact that the
use of intermediary conversions warrants flagging that it is unknown
territory.  FFPIM does not do that and I will add some text and add a
citation to the IAB document.  This will ensure that a reader is aware
that there is a "topic" involved in this bit of mechanism.


>>SH>   Among the issues are:  the document allows for the
>>SH> conversions
>>SH> to happen off the message path,
>>
>>That is not what the specification says.  It says that conversions do
>>not HAVE to happen "along" the message path.
...
TH> Here's the text from 2.1:
...
TH> If the intent is only to describe a use case in which CONPERM
TH> passes from the originator to the recipient, I suggest deleting
TH> the first paragraph above.  If the intent is to describe a
TH> mechanism in which an MTA passes the message to
TH> a (non-MTA) server for conversion and then along the message
TH> path, more text on how this expected to work is needed.

This is a good example of the dangers in adding cautionary text.
Concern for its precision becomes the focus, even though it is not
really offering any normative specification.


>>SH>  but has not dealt with the issues raised
>>SH> by the IAB in the context of OPES;
>>On the contrary, we reviewed IAB and OPES draft documents that were
>>available at the time the specification was written and we factored
>>those concerns in.
...
TH> There is no citation of RFC 3238, and I do not see any discussion of the
TH> issues it raises in the text.

Again, that is a question of what pedagogy to include, versus what
technical factors to consider in the design.  Conperm/Conneg very much
reflect the technical factors raised in the the IAB paper, but the
specification does not delve into analytic pedagogy about its
application, since this is a specification rather than a treatise.

So, the content of the IAB paper is reflected in the specification,
not the form of citing it.

As noted above, adding a citation is not unreasonable.


TH>  draft-ietf-opes-iab-05, currently in the
TH> RFC Editor's queue, contains a description of how the OPES working group
TH> saw their work in the light of the requirements it put forward. 

That is nice, but it is not normative.  Hence it is difficult to see
the issue as being in the critical path of issuing the specification.


>>SH>  the document allows for conversion
>>SH> and continuation of the use of CONPERM so that a later conversion may
>>SH> take place--creating the classic "copy of a copy" syndrome;
..
TH> Would "transform of a transform" be clearer?  I.e, I allow conversion from
TH> PDF to HTML and POSTSCRIPT but prefer POSTSCRIPT;

Ahh.  Yes, now I understand. And yes, it should be a concern.

My own suggestion is to add another caution within the conperm
document about this.  Something along the lines of "this could be
dangerous" with a form of the exemplary implication you describe.

Any sort of cascading sequence of actions will tend to carry this
danger, so it needs to be stated as a "proceed at your own risk"
concern.

(I'd offer candidate text but it will be a full day before I can do
that and I wanted the iteration with you quicker than that.)


>>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.


>>SH> the document punts completely how the SMTP
>>SH> service
>>SH> gets the CONNEG data in the first place, putting a critical part of the
>>SH> security story out of reach.
>>That is correct.  The document specifies a particular mechanism, not a
>>complete "system".  It states the security implication of this in the
>>opening lists of the security section.
>>By way of comparative example, note that the BGP specification does
>>not say how a BGP speaker obtains the list of hosts it announces paths
>>to? The BPG spec just refers to "local policies".
TH> This isn't a close parallel, as BGP peers are limited to ASes with whom
TH> an AS has a peering agreement--a shared understanding of where and
TH> how the two parties trade traffic.  At the moment, MTAs may speak to other MTAs
TH> on an as-needed basis, and they have no such shared understanding
TH> outside of the standards themselves.

Sorry but I have no idea what you mean, in terms of implications for
this specification.

The simple statement is:  yes, this specifies one portion of a whole
system.  It is self-contained and leaves local information passing
issues to the local environment.  (Added example:  how do acap servers
get their information?  How do ANY servers get their innformation?)


>>The fact that portions of a larger system remain unspecified ought not
>>to invalidate having a public portion of such a service.

TH> With an applicability statement that limited the expected use to a
TH> private service,

Frankly I find such applicability statement to have no pragmatic
benefit, except as a source of later debating.  They are not normative
and there is not much that an implementor can do with them.


TH> I would agree.  If you expect this to work generally for all SMTP 
TH> speakers, though,
TH> having at least an example of how an SMTP speaker *might* derive
TH> this data without doing violence to the SMTP service model seems
TH> to me like a useful addition.

Why?  How does this affect the normative specification.

d/

ps.  again, apologies for not letting the response sit for an hour and
reviewing it.  We have to go to a balinese arts festival...
--
 Dave Crocker <mailto:dcrocker@xxxxxxxxxxxxxxx>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>