Subject: Re: [yam] Last Call: <draft-ietf-yam-rfc4409bis-02.txt>

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2011 01:50:23 +0200

Hi, I support to get 4409bis as STD, as already stated in
<http://thread.gmane.org/gmane.ietf.rfc822/11805/focus=5100>

The "bug" reported 59 months ago is not fixed in 4409bis,
it is still "MAY add Sender", but I'm not more trying to
"fix" other RFCs for SenderID.

Folks here suggested to smuggle in an informative reference
to RFC 6186.  I've no problem with this subversive proposal,
RFC 6186 is obviously "on topic", but I haven't checked it.

For the similar to proposal to reference RFC 5451 I have a
clear idea what it is about, but I don't see what it has to
to with message *submission*.

My favourite MISSREF would be RFC 5068, it might be one of
the reasons why deployment of RFC 4409 increased in the last
years, and that could be state in section 1.2.

Actually the normative reference to RFC 4409 is the main
point of RFC 5068 after some other points did not make it
into this document.  Free bonus:  BCP 134 is no "downref".

Unrelated, it is very good that folks here feel that they
are at most two months away from "5321 to STD".  Please go
for it - it would be very silly to close a WG weeks before
the most important IETF progress since STD 68 from my POV.

I reserve the right to change my mind if "two months" is
"USEFOR terminology" and actually means "5+ years"... ;-)

-Frank

---

From: S Moonesamy <[email-masked]>
Date: Wed, 17 Aug 2011 00:29:38 -0700

Hi Frank,
>"fix" other RFCs for SenderID.

I missed the "bug" and it was unfortunately not brought up during the 
discussion of draft-ietf-yam-rfc4409bis.  One of the authors, John 
Klensin, responded to your message on September 28, 2006.  My reading 
of the reply is that it imposes additional requirements.  If the 
conclusion is incorrect, please send a message with suggested text 
and rationale so that the working group can comment.

>RFC 6186 is obviously "on topic", but I haven't checked it.

See http://www.ietf.org/mail-archive/web/ietf/current/msg68465.html

>into this document.  Free bonus:  BCP 134 is no "downref".

Section 1.2 will be removed before publication.

Regards,
S. Moonesamy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2011 17:22:16 +0200

On 17 August 2011 09:29, S Moonesamy wrote:

 [<http://thread.gmane.org/gmane.ietf.rfc822/11805/focus=5100>]
> I missed the "bug" and it was unfortunately not brought up during
> the discussion of draft-ietf-yam-rfc4409bis.

Nevermind, the main issue wrt SenderID's "PRA' was in RFC 2822, and
it was discussed and intentionally NOT fixed in RFC 5322.  I mainly
want to have it on public record that 4409bis also was intentionally
NOT fixed for the ambitious goals of SenderID, and that's clear now.

For 4408bis I can produce the op=pra draft which never got traction
for a demonstration of a good faith effort to "fix" email everywhere
for SenderID - and failing everywhere due to lack of support.

>From my POV folks interested to highlight a "responsible" party - or
more important an ominously missing "responsible" party - in MUAs
can use DKIM instead of SenderID, where that "responsible" party is
not simply the Return-Path covered by RFC 4408 or its successor.

And if they are interested to reject mail a.s.a.p. they can use SPF
instead of SenderID's PRA, or pick any scheme they like better.  But
hoping that 2822bis and 4409bis will make SenderID work as designed
would be now stupid, as it obviously didn't happen.  For a value of
"now" determined by 5322, not 4409bis.

> My reading of the reply is that it imposes additional requirements.
> If the conclusion is incorrect

No, you are right.  My good faith effort didn't go so far to publish
an I-D trying to fix 4409, but I did that for 4408 with op=pra, and
folks were not convinced:  After all they already have any SenderID
info in their DNS cache when they evaluate SPF, and shortcuts in the
PRA evaluation (where that is at all desired) would not help wrt DNS
traffic.

Senders insisting on getting SenderID right "MAY add Sender", so at
least that (interpreting MAY as SHOULD) works for anybody trying it.
The more complex syntax issues in 2822 and 5322 fortunately affect
nobody else, notably not 4409bis or 4408bis.

 [6
> See http://www.ietf.org/mail-archive/web/ietf/current/msg68465.html

ACK, I interpret that as "John doesn't like RFC 6186", otherwise he
would find a way to mention it somewhere.  I had my share of "let's
try discovery for NNTP" elsewhere, and won't mention it again here.

But referencing RFC 5068 (BCP 134) would be good, if readers arrive
at a "the IETF really wants this" conclusion.

> Section 1.2 will be removed before publication.

Oops, right, but the "historical context" in John's drafts is often
very important for me, because I have no idea what used to be a say
FTP design problem before 1995.  Presumably others are in a similar
position with SUBMIT issues before 2010, and a pointer to BCP 134 in
4409bis appendix A can be helpful for anybody trying to reconstruct
"the history of email RFCs" in the future.

-Frank

---

From: S Moonesamy <[email-masked]>
Date: Wed, 17 Aug 2011 11:39:58 -0700

Hi Frank,
>try discovery for NNTP" elsewhere, and won't mention it again here.

The decision is based on input from both editors and other YAM WG 
participants [1].  Alexey also suggested adding the reference to RFC 
6186 [2].  As I mentioned previously, given that the draft is 
intended to be published as Full Standard, the maturity of a 
dependency has to be considered.  The reference would have been 
added, assuming the YAM WG agreed, if there was an interoperability report.

>at a "the IETF really wants this" conclusion.

I'll make a note of this as part of the Last Call comments.  The 
determination of "the IETF really wants this" reference would be 
based on the feedback received.

>"the history of email RFCs" in the future.

For what it is worth, John and Randy worked on 
draft-ietf-yam-rfc4409bis.  BCP 134 was published after RFC 4409 and 
it focused on Triple-A whereas RFC 2476 also provided for limited 
changes to a message when it is submitted and a degree of separation 
for implementing local policies.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/yam/current/msg00636.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00682.html

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Aug 2011 19:27:05 -0400

Frank,

I don't think a two-way debate between the two of us will be
useful to the WG or others, but I'd like to clarify four things.

(1) Randy and I worked together on 4409bis, 4409, and 2476.  For
reasons that had a lot more to do with time availability than
anything involving decision-making, Randy was the primary
pen-holder for 2476 and 4409 and I took over with 4409bis.  But
I think it is accurate to say that we consulted each other
closely on everything that was the slightest bit controversial.
More important, 4409bis-02 reflects a lot of comments that
neither Randy nor I would have made on our own.  I'd have to go
through the document to tell you which changes we made that I
don't like (and don't consider that a good use of my time), but
my personal preferences are really not an issue in this.

(2) Having been involved in the various discussions about the
meaning of maturity levels and downward references over the
years, I do have strong opinions on the subject.  Some of those
opinions got IETF consensus and are reflected in BCP 97.  My
reading of those documents and the original rules is that the
exceptions are intended to apply to circumstances in which the
document that requires a downward reference represents a
protocol that is tested and mature, even if the document itself
hasn't been updated.  It seems sensible to me to be even more
discriminating about that principle with Full Standards than
with Drafts although, maybe, some might disagree.  Under that
criterion, 6186 just does not seem to be mature enough.  If
someone demonstrates otherwise -- e.g., with an implementation
report that shows fairly widespread adoption-- I'd be delighted
to add it (see below).

(3) As far as my "not liking" 6186 is concerned, it just isn't
true.  If you searched the mail archives into fairly ancient
history, long before RFC 2782, you would find me whining about
the problems associated with manual configuration of outbound
SMTP servers (what we'd now call Submission Servers) into email
clients.   That whining got particularly loud when I had to
deploy a lot of email clients for clueless users around 94-95.
Many of us thought for a while that IMSP and later ACAP would do
the job, changing the "where to find the outgoing SMTP server(s)
specifically" into "where to find that IMSP/ACAP server so it
could supply the rest of the information".  When ACAP failed in
the marketplace (more's the pity, IMO), 6186 came along (you'd
have to ask Cyrus but I strongly believe that, had ACAP been
wildly successful, the equivalent of 6186 would be titled "SRV
Record for Locating ACAP Servers".  

But my disliking it or being opposed to it?  Nah, not a chance.
I just wish I had it in my MUA (sorry, Cyrus :-( ).

(4) As an editorial style matter, RFCs that specify protocols
tend to not reference supplemental documents that make
operational recommendations.  The references run the other way
and the other way only.  I would consider a reference from
4409bis to 5068 an exception to that general principle.
However, if the WG or IETF conclude that such a reference is
wanted, you will get absolutely no resistance from me to doing
so.  I just have too many more important issues to worry about.

     john

--On Wednesday, August 17, 2011 17:22 +0200 Frank Ellermann
<[email-masked]> wrote:

>...
>  [6
>> See
>> http://www.ietf.org/mail-archive/web/ietf/current/msg68465.ht
>> ml
> 
> ACK, I interpret that as "John doesn't like RFC 6186",
> otherwise he would find a way to mention it somewhere.  I had
> my share of "let's try discovery for NNTP" elsewhere, and
> won't mention it again here.
> 
> But referencing RFC 5068 (BCP 134) would be good, if readers
> arrive at a "the IETF really wants this" conclusion.
>...

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 18 Aug 2011 02:34:10 +0200

On 18 August 2011 01:27, John C Klensin wrote:

> 4409bis-02 reflects a lot of comments that neither Randy
> nor I would have made on our own.  I'd have to go through
> the document to tell you which changes we made that I
> don't like (and don't consider that a good use of my time)

Just in case I looked at the diffs back to 4409 before posting
a "+1" for the Last Call here, and I found no obvious problems.

The BCP 97 rules are perfectly clear, the "double downref" for
RFC 4954 attracted my attention.  Not touching the status of
this RFC, because it could result in another round of "let's
finish off CRAM-MD5" is only my personal POV, but I digress...

> 6186 just does not seem to be mature enough.

Okay, I cannot judge it, and in fact I have not read it, but I
certainly understand it when authors hope that their work gets
a reference in related RFCs; a kind of "spamvertizing" I'd like
if it is not too obtrusive.

> As far as my "not liking" 6186 is concerned, it just isn't
> history, long before RFC 2782
[...]

Admittedly I didn't search old archives, finding the thread
where I suggested to promote RFC 4409 to STD was bad enough.
But I recalled that the IESG was seriously NOT interested in
obscure kinds of "NNTP discovery" in a memo about NNTP URIs.

> But my disliking it or being opposed to it?  Nah, not a
> chance. I just wish I had it in my MUA (sorry, Cyrus :-( ).

Thanks for info, I wasn't aware of that.

> As an editorial style matter, RFCs that specify protocols
> operational recommendations.  The references run the other
> way and the other way only.  I would consider a reference
> from 4409bis to 5068 an exception to that general principle.

I also wasn't aware of that general principle, and thought
that "getting the credits right" is only a chronological
question:  If A and B address topic X, and B is published
after A, then B should have a reference to A.

The "protocol" vs. "operational" consideration makes sense,
but again, I didn't know that general principle.  Certainly
no big issue, I just felt like adding my own "MISSREF" after
looking at the two "MISSREFs" posted by others here.

-Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Aug 2011 20:59:46 -0400

> after A, then B should have a reference to A.

Before I accidentally start another argument, I deliberately
said "tend to not" -- I don't believe it has ever been a rigid
rule.  I also imagine a search for exceptions would find them
(and would encourage people who are inclined to do such a search
to ask themselves whether their time could be better spend in
other ways).  
 
> looking at the two "MISSREFs" posted by others here.

:-(

As an editor who is (I hope temporarily) close to exhaustion on
that document, I'd like to see the WG concentrating on what it
takes to get it out in a satisfactory form that properly
reflects our intentions about the specification of the protocol,
rather than on how it can be decorated with, e.g., informational
references about assorted things that implementers or operators
of Submission servers or clients might want to know.   But that
is just my opinion and preference.. YMMD and I wouldn't dream of
trying to suppress your right to say so.

    john

 best,
   john

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Aug 2011 17:51:42 -0700 (PDT)

> I just wish I had it in my MUA (sorry, Cyrus :-( ).

Complete agreement with John here.

Full standard is supposed to give operators confidence that there won't be any
problems with the technology. It does this by demonstraing substantial
sucessful operational experience. AFAIK such experience does not presently
exist for RFC 6186. As such, much as I like RFC 6186 and would like
to see it widely deployed, referencing it in 4409bis is completely and totally
inappropriate.

Anyone who disagrees should feel free to describe the multiple commonly used
clients that support it as well as the multiple large operational setups that
have succesfully used it. If that happens I'll happily change my position and
support a downref to RFC 6186.

In short, this is a substantial concern about there being a lack of operational
experience. It is not simply a matter of blindly following process rules.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 18 Aug 2011 03:32:30 +0200

Now what, I confirmed everything you wrote before.  Is it some
case of bad DEnglish on my side, that you interpret "I wasn't
aware of" as "I don't believe you"?  I simply meant "I didn't
know this", no tricks, no intention to dig through 6000+ RFCs
in a weird quest to find any exceptions from an editorial or
stylistic principle I did not know until you mentioned it.

> YMMD and I wouldn't dream of trying to suppress your right
> to say so.

Hopefully the folks trying to evaluate the Last Call comments
identify this thread as one "+1" wrt 4409bis, and nothing more
or else.  I've no idea why that apparently upsets you, sorry.

-Frank