--On Sunday, March 06, 2016 15:10 +0000 Stephen Farrell
<stephen.farrell@xxxxxxxxx> wrote:
>
> Hi all,
>
> The 2nd IETF last call for this started on Feb 8th.
> Thanks again for the lively discussion.
>
> The tl;dr version is: once a revision addresses the
> substantive issues raised as per below, taking into
> account reactions to this summary, and we have a chance to
> take a quick look at -08 (I'll extend the LC to the date
> of the -08 version plus one week), then if no new
> substantive issues arise, I think we have rough consensus
> to go forward with this experiment (and others to come)
> and let the IESG review the document.
>...
> 3. The local-part (lhs) issue and i18n
> ---------------------------------------
>
> This has always been and will always be an issue for any
> solution in this space. Absent changes to the mail
> architecture, or major changes to email protocols and
> deployment, it will always be an issue. And it's quite
> related to the "joe+ietf" kind of lhs too, which'd need
>...
> "Section 3 above defines how the local-part is used to
> determine the location in which one looks for an
> OPENPGPKEY record. Given the variety of local-parts seen
> in email, designing a good experiment for this is difficult
> as: a) some current implementations are known to lowercase
> at least US-ASCII local-parts, b) we know from (many)
>...
Stephen,
I've been thinking about this for a few days and have concluded
that I do not agree with your "resolution" and proposed
approach. All of what you write would be reasonable (whether we
agree or not), except for two closely-related issues:
(1) The IETF should not be encouraging experiments on the public
Internet that could be harmful to the Internet or to existing
deployed applications, especially standards-track ones. Several
people with significant email operational experience have made
the claim that this experiment could be harmful to the
Internet's email infrastructure, if only by encouraging a
violation of a fairly explicit (and very important, IMO)
provision of SMTP. As far as I can tell from reviewing the
discussions, there has not even been effort to refute those
claims or explain why they are not relevant.
The attitude associated with the problem -- and why I think it
is an important problem -- is perhaps best summarized in a note
from the author posted today:
--On Friday, March 11, 2016 07:51 -0500 Paul Wouters
<paul@xxxxxxxxx> wrote:
>...
> I believe the chairs stated that the experiments of dane for
> openpgpkey and smime can continue without tackling every
> corner case of local-parts. Fixing the local-parts is up to th
> email community, not the dane community.
First, there is apparently disagreement with the email community
about what is and is not a corner case. Many of the issues that
have been raised (and the text that appears in -08) appear to at
least some of us to involve relatively mainstream cases.
Equally important, a "corner case" in email addresses may
represent a few million messages a day, which I don't believe
should be so lightly dismissed.
I believe it has been said before, but the first sentence of
Section 4 is either much more informal language than it appears
to be (and somewhat misleading in the process) or it is wrong.
Most (final delivery) mail systems support aliases for mailbox
names. The specifications make no assumptions, and systems
differ, about whether there are lexical or semantic
relationships among the set of aliases for a given mailbox, much
less what those relationships might be. Whether those aliases
are somehow "variant forms" is in the mind of the beholder.
However, if the specification simply hashes the local part
string as given (as specified in section 3), then at least most
of that first paragraph of Section 4 is gratuitous and should be
out of scope for this document and dropped.
While I generally like the "it is just an experiment"
justification for publishing and moving on, it seems to me,
after having reviewed the discussion of Experimental status in
2026, including the specific comment about limited use in 3.3(d)
and thinking about evolution since 2026 was published, that
there are two reasons for publishing an experimental
specification from an IETF WG. One is to encourage widespread
experimentation, an approach we have often taken when we are not
sure enough about a proposal to standardize it. The other, I
believe much less used in recent years, is precisely the
"limited use" case that 2026 seems to anticipate: use only by a
prearranged group of people who understand what they are getting
into and a recommendation to the broader community that they
_not_ attempt to use it until after the experiment is reported
upon. While your new paragraph in Section 1.1 and the end of
Section 4 of -08 is a considerable improvement in other ways, it
does not contain any hint of that "limited use" restriction or
other warning notice nor is there any warning in Section 8.
Given that there are unrefuted claims that this "experiment"
could cause harm in or to the deployed email infrastructure or
create additional security risks, that seems necessary.
(2) In general, we've explained the purpose of an IETF Last Call
as allowing review across area and from multiple perspectives
with the intention of resolving issues that are identified by
the process prior to publication. When one community finds a
problem in a specification, we generally (I believe never) allow
the document's authors to say "we've made this mess, if you
think it is a problem, it is your job to clean it up". I'm
sympathetic to the next text at the end of Section 4 and the
desire to experiment first and deal with the so-called
canonicalization problems later but:
(a) Saying "some current implementations... lowercase at least
US-ASCII local-parts" misses the point to the degree that it is
misleading. RFC 5321 rather explicitly allows a final delivery
MTA ("MDA") to make whatever equivalence rules it likes,
certainly including applying any lower-case procedure it
considers appropriate. However, nothing else is allowed to do
so and it is no more appropriate for me, as a sender of mail to
you, to assume that Stephen.Farrell@xxxxxxxxx will work and
reach you rather than your colleague Joe Bloggs than it is for
me to assume that stevie@xxxxxxxxx will reach you and not Steven
Bloggs. Because at least one of the "possible harm" scenarios
is associated with that particular alternate-local-part-guessing
procedure, this example is significant rather than facetious.
(b) We've been told during the Last Call that repeated efforts
by email experts to inject these issues into the discussion and
have them properly reflected in the document have been ignored,
met with abuse, or turned into "we don't care about that
problem, you solve it if you do" comments. I note that the last
sentence of the quotation from Paul Wouter's note above is
consistent with those claims -- it asserts that the problem is
the email community's to fix and not a DANE responsibility and
may imply that the definition of email local-parts (a definition
that is at least around 35 years old and arguably nearly a
decade older than that and supported in _very_ widely
implemented and deployed systems) is the problem and not how
DANE wants to handle them.
The situation with this document is in danger of turning into a
"victory for attrition" pattern, in which the "victor" is the
party with the most energy for continuing the discussion for the
longest period of time. Whichever side on is on, that is not a
good way to make decisions that are supposed to represent IETF
consensus. Extending the Last Call in a situation like this one
encourages that pattern by wearing those with concerns based on
relevant knowledge and expertise to just give up from exhaustion
and the demands of other work.
I therefore suggest that the approach of extending the Last Call
be dropped and that either the document be returned to the WG
for careful consideration of the input from the email community
(moving the WG into ART if that review cannot occur adequately
under SEC supervision) or that the IESG as a whole take a
position on it. If it does decide to advance it, I strongly
suggest inclusion of an applicability statement that specifies
limited use and that carries appropriate warnings.
best,
john
p.s. I hope this can be resolved in a less time-consuming way
and without my having to decide on whether a next step is needed
(and would welcome comments from others on that subject), but I
trust you have noticed that the statement above is in
substantially the form that could be considered as the "contact
the relevant AD" first step in an appeal of how this document is
being handled.