Subject: Re: [ietf-smtp] Email standard revision

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Feb 2020 07:20:36 -0800

Folks,

After some discussion with Barry, what seems to have been missing is a 
clear statement of needs and goals.  Many different approaches to 
revision are possible and reasonable.  So the reasons for choosing one 
needs to be clear.

Logic for a limited effort:

     The current, well-established, core specifications for email are at 
a lower standards level than what the (realistically) long-obsolete 
versions.  The goal is to (finally) establish the later versions as full 
standards (and, I assume, declare the earlier versions as obsolete.)

     Any substantive revision to the current specifications runs the 
risk -- actually the likelihood -- of resulting in the output being 
labeled at a /lower/ standards level than it current has, thereby 
exacerbating the original issue.

     Hence the revision effort needs to be constrained to altering only 
essential, /minor/ details.  A cleanup exercise, if you will.

Yes?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 Feb 2020 19:08:54 +0100

Hi,

On Tue 18/Feb/2020 16:20:36 +0100 Dave Crocker wrote:
> After some discussion with Barry, what seems to have been missing is a clear
> statement of needs and goals.  Many different approaches to revision are
> possible and reasonable.  So the reasons for choosing one needs to be clear.
> 
> 
>     The current, well-established, core specifications for email are at a lower
> standards level than what the (realistically) long-obsolete versions.  The goal
> is to (finally) establish the later versions as full standards (and, I assume,
> declare the earlier versions as obsolete.)
> 
>     Any substantive revision to the current specifications runs the risk --
> actually the likelihood -- of resulting in the output being labeled at a
> /lower/ standards level than it current has, thereby exacerbating the original
> issue.
> 

I agree.  I don't think a cleanup, like e.g. the one you proposed[*], would
revert rfc5321bis to proposed standard.  However, I'm not clear on how that
works.  Certainly, rfc2821 was reverted to proposed standard, but I wasn't
there and I don't know who/how decided to label that I-D to a lower standard.

BCP 9 is not so precise:

   [I]f the specification has been changed very significantly, the IESG
   may recommend that the revision be treated as a new document, re-
   entering the standards track at the beginning.
                        https://tools.ietf.org/html/rfc2026#section-6.2

Since there are quite some issues to be clarified[†], I think the new WG will
need some detailed guidelines about what would be a very significant change.

Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/ietf-smtp/K1MpIrubUzq6-90Ikdl4yuh7n3o

[†] I annotated some YAM issues at hypothes.is.  Additions welcome.
https://hyp.is/QQqD1iW3Eeq0pQfOL0z_1Q/tools.ietf.org/html/draft-klensin-rfc5321bis-00

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Feb 2020 14:12:30 -0500

Dave,

I agree with your logic.  I just don't see it as being as simple
as all that, primarily because I don't see a way to alter only
"minor" details while ignoring major issues if there are any of
those -- and some have asserted that there are.

Disclaimer: as editor, I'm willing to do whatever the consensus
is about this, even if that requires holding my nose.

In principle, I'm fine with "a cleanup".  The difficulty I see
is that the language in RFC 2026 seems very clear to me: "no
known technical omissions with respect to the requirements
placed upon it" without an explicit IESG waiver for Proposed
Standards; not even an exception procedure for Internet
Standard.   Unless you and Barry (and/or the other ADs) see a
way to waive that section of 2026 and intend to do so, I believe
the only option is for a WG to go through the list of issues in
Appendix G of draft-klensin-rfc5321bis-02 and determine, for
each one, whether it is "cleanup" (including technical
omissions) or new work that can be handled elsewhere (or not at
all).  I think (or at least hope) that some things on that list
can be quite quickly disposed of as inconsistent with a cleanup.
As examples, pushing into authentication or TLS issues apprear
to me to rather clearly on that list but others may disagree.
Some of the other items listed may be less clear.  But I see no
way to separate what is, or is not, "cleanup" by writing general
scope statements: sooner or later, either someone is going to
assert the authority to make command decisions and people are
going to decide to accept that or "we" are going to have to go
through that list one item at a time.

And, of course, there is nothing particularly special about that
list: if someone identifies an issue tomorrow that is
significant enough to be a "known technical defect", I see no
way to bar that issue from the discussion.

best,
   john

--On Tuesday, February 18, 2020 07:20 -0800 Dave Crocker
<[email-masked]> wrote:

> Folks,
> 
> After some discussion with Barry, what seems to have been
> missing is a clear statement of needs and goals.  Many
> different approaches to revision are possible and reasonable.
> So the reasons for choosing one needs to be clear.
> 
> 
>      The current, well-established, core specifications for
> email are at a lower standards level than what the
> (realistically) long-obsolete versions.  The goal is to
> (finally) establish the later versions as full standards (and,
> I assume, declare the earlier versions as obsolete.)
> 
>      Any substantive revision to the current specifications
> runs the risk -- actually the likelihood -- of resulting in
> the output being labeled at a /lower/ standards level than it
> current has, thereby exacerbating the original issue.
> 
>      Hence the revision effort needs to be constrained to
> altering only essential, /minor/ details.  A cleanup exercise,
> if you will.
> 
> 
> 
> Yes?
> 
> d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Feb 2020 14:26:15 -0500

--On Tuesday, February 18, 2020 19:08 +0100 Alessandro Vesely
<[email-masked]> wrote:

>...
>  I don't think a cleanup, like e.g. the one you proposed[*],
> would revert rfc5321bis to proposed standard.  However, I'm
> not clear on how that works.  Certainly, rfc2821 was reverted
> to proposed standard, but I wasn't there and I don't know
> who/how decided to label that I-D to a lower standard.
> 
> BCP 9 is not so precise:
>...

At the time, there was at least one important issue and it was
independent of the BCP 9 text you cited.  2821 was essentially a
merge of RFCs
  821 (a full standard)
  974 (don't remember its status at the time 2821 was in
progress, but note that it is listed as part of STD 10, so I
assume full standar)
  some text from 1123 (another full standard)
  1829 (another full standard)
  and bits and pieces of text, some of it completely new, either
picked up from assorted places or inserted to better align 2821
with 2822 than 821 and 822 were aligned.

That new text, and the merger itself, were, in principle and
maybe in practice, untested for how they would work in terms of
comprehension, implementations, and deployment in the future.
Hence PS.  Could we have pushed it through as full standard?
Maybe.  But the experience of the changes that needed to be made
to get to 5321 (virtually all of which were "cleanup") suggests
that would have been a bad decision.
  
> Since there are quite some issues to be clarified[†], I
> think the new WG will need some detailed guidelines about what
> would be a very significant change.

Yes.  See my earlier note.  And, again, I'm skeptical that can
actually be done by guidelines rather that a case-by-case review.

    best,
     john

---

From: Michael <[email-masked]>
Date: Tue, 18 Feb 2020 12:04:44 -0800

Curious, does this cleanup fall under the auspices of email security, as a whole?
Wondering if it fits into the idea that I proposed under the DISPATCH to consider a WG that covers email security issues, including deprecating some of the older recommendations that allow sending authentication over insecure channels?

On Tue, 18 Feb 2020 14:26:15 -0500
John C Klensin  wrote:
>  wrote:
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
> 

--
-- 
"Catch the Magic of Linux..." 
------------------------------------------------------------------------ 
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------ 
A Wizard IT Company - For More Info http://www.wizard.ca 
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Feb 2020 16:30:36 -0500

Michael,

They can and should speak for themselves, but as I understand
Dave's (and Barry's) proposal, changing authentication models or
requirements would definitely be excluded under "clean up only"
criteria.  

If you, or others, disagree, that reinforces my impression that
we are going to need to work through the issues list, one at a
time, and decide on each on a case by case basis.  FWIW, note
that authentication issues are listed in
draft-klensin-rfc5321bis-02 in G.4 and G.6.  If you look at
those descriptions and think they are inadequate to identify the
issues, please suggest text (noting that, at this point, I [1]
am interested only in problem descriptions, not specific
proposals

best,
   john

[1] As editor, working draft curator, and self-appointed keeper
of the list.  That role changes, and my personal opinions become
irrelevant, as soon as there is a WG (with, of course, a
character and designated leadership).

--On Tuesday, February 18, 2020 12:04 -0800 Michael
<[email-masked]> wrote:

> Curious, does this cleanup fall under the auspices of email
> security, as a whole? Wondering if it fits into the idea that
> I proposed under the DISPATCH to consider a WG that covers
> email security issues, including deprecating some of the older
> recommendations that allow sending authentication over
> insecure channels?

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Feb 2020 14:34:45 -0800

1. It's not my proposal.  I merely offered some wordsmithing to 
characterize an approach that has been suggested.

2. Status:

On 2/18/2020 11:12 AM, John C Klensin wrote:
> The difficulty I see
> Standards;

Since the goal for the effort described in the text I offered is for 
full standard and not proposed, I have no idea what your reference, 
here, pertains to.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Feb 2020 17:42:05 -0500

--On Tuesday, February 18, 2020 14:34 -0800 Dave Crocker
<[email-masked]> wrote:

> Since the goal for the effort described in the text I offered
> is for full standard and not proposed, I have no idea what
> your reference, here, pertains to.

Please read the rest of that sentence, which read...

>  not even an exception procedure for Internet
> Standard. 

Unless someone is going to argue that the omission of any
specific mention of Internet Standard in that discussion means
that known technical omissions are ok in full standards, I think
that is a bar to adoption of documents as full standards that
contain such defects.

The rest of the paragraph may or may not be useful, but the
above should answer the question of what the reference pertains
to.

best,
  john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Feb 2020 14:47:40 -0800

>>   not even an exception procedure for Internet

I'll guess you mean that the criteria for Proposed extend to Full, but 
that's just a guess.

At that, I still have no idea how it is applicable here.  My guess is 
that you have some unstated assumptions or analyses or conclusions that 
establish the relevance, but I don't know what it/they are.

d/