Subject: Re: Last Call: <draft-housley-suite-b-to-historic-04.txt> (Reclassification of Suite B Documents to Historic Status) to Informational RFC

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2018 11:18:44 -0400

Why are we having a second Last Call on this document?

The first Last Call began on 16 Feb 2018 and ended on 16 Mar 2018.

Russ

> On Mar 27, 2018, at 11:14 AM, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'Reclassification of Suite B Documents to Historic
> Status'
>  <draft-housley-suite-b-to-historic-04.txt> as Informational RFC
> 
> The Last Call for the document draft-housley-suite-b-to-historic is related to 
> the status change document, also in Last Call, for status-change-suiteb-to-historic.
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-04-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document reclassifies the RFCs related to the U.S.  National
>   Security Agency (NSA) Suite B cryptographic algorithms as Historic,
>   and it discusses the reasons for doing so.  This document moves seven
>   informational RFCs to Historic Status: RFC 5759, RFC 6239, RFC 6318,
>   RFC 6379, RFC 6380, RFC 6403, and RFC 6460.  In addition, this
>   document moves three obsolete informational RFCs to Historic Status:
>   RFC 4869, RFC 5008, and RFC 5430.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-housley-suite-b-to-historic/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-housley-suite-b-to-historic/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Mar 2018 13:04:24 -0500

> The first Last Call began on 16 Feb 2018 and ended on 16 Mar 2018.

II[UR]C, the process for moving things to historic requires a
separate status-change document that goes out for 4-week IETF LC
alongside the document effecting the status change.  I don't think
the status-change document existed in last month's last call.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2018 14:43:38 -0400

> the status-change document existed in last month's last call.

Indeed it did.  I do not know whether the Last Call properly included it, bu the history tab clearly shows that the status change document was created on 10 Feb 2018.

See https://datatracker.ietf.org/doc/status-change-suiteb-to-historic/history/ <https://datatracker.ietf.org/doc/status-change-suiteb-to-historic/history/>

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Mar 2018 14:56:35 -0500

> See https://datatracker.ietf.org/doc/status-change-suiteb-to-historic/history/ <https://datatracker.ietf.org/doc/status-change-suiteb-to-historic/history/>

I was just looking at
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html,
which does *not* show an IETF Last Call being issued for
"Reclassification of Suite B Documents to Historic Status" (the
status change document) until today.  So that seems to be the part
that was missed last time.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2018 16:05:07 -0400

> that was missed last time.

I do not believe that the additional month will yield any new information.

I do not think that anyone who read the document missed the reclassification.
The Abstract includes it:

The status-change document is essentially the same information, and it
even points to draft-housley-suite-b-to-historic for the full rationale.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Mar 2018 15:08:30 -0500

> I do not believe that the additional month will yield any new information.

I don't believe that anyone thinks it will.  But, until the IESG
decides to revise
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
it is the process we are stuck with.  (And given the document load
for the next couple telechats, I don't expect the IESG to get around
to deciding to revise this statement before the four week LC is
up...)

-Ben

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Mar 2018 17:02:32 -0400

Just two observations by someone who is not at all involved in
this.  As others have observed recently in other contexts, one
of the main distinctions that used to characterize the IETF and
its work was that we focused on doing the right thing for the
Internet, with flexibility to do The Right Thing in specific
cases, rather than getting completely constipated by large
collections of rigid rules, applied mindlessly.   I favor being
very careful about what we identify as Historic and about having
traceability and easily-accessed information, but this
discussion seems to be headed down the path toward "well, we
made these rules that didn't allow for all of the cases, so we
need to follow them without thinking".  That doesn't seem
desirable, especially if it represents a trend.

I do see a special issue in this case: as I understand it, NSA
has posted documents that are intended to replace some of the
documents under discussion and has asked the ISE to publish
them.  If those documents were slated for publication in the
IETF Stream, I assume the Right Thing to do would be to have
them contain text obsoleting the earlier versions and
eliminating any confusion.  But they are not, which I presume is
one of the reasons we are in this tangle.  

FWIW, would strongly encourage the IESG to take advantage of the
considerable trust and flexibility the community has given it
(and which has been taken advantage many times in the past when
doing so has suited the IESG's convenience) to consider and cut
through this knot rather than taking a position that sounds too
much like "well, we made up this procedure, the community is
stuck with it, and we think it is better to subject the entire
community to the costs of an unnecessary Last Call than to
figure out how to consider the facts of the situation".

best,
   john-the-grump

--On Tuesday, March 27, 2018 15:08 -0500 Benjamin Kaduk
<[email-masked]> wrote:

>> > I was just looking at
>> > https://www.ietf.org/mail-archive/web/ietf-announce/current
>> > /maillist.html, which does *not* show an IETF Last Call
>> > being issued for "Reclassification of Suite B Documents to
>> > Historic Status" (the status change document) until today.
>> > So that seems to be the part that was missed last time.
>> 
> I don't believe that anyone thinks it will.  But, until the
> IESG decides to revise
> https://www.ietf.org/iesg/statement/designating-rfcs-as-histor
> ic.html it is the process we are stuck with.  (And given the
> document load for the next couple telechats, I don't expect
> the IESG to get around to deciding to revise this statement
> before the four week LC is up...)

---

From: Pete Resnick <[email-masked]>
Date: Tue, 27 Mar 2018 17:59:05 -0500

While I generally agree with John here, let's not forget what caused the 
IESG to put together that procedure in the first place and let's not get 
back to that previous state:

The problem is that "moving to Historic" is really a Standards Track 
thing to do. What was happening before is that these "moves" were being 
done in Informational RFCs, and anyone who didn't happen to notice the 
Last-Call for the document, or decided not to care all that much because 
the document was Informational, was not going to notice that the IESG 
was making this declaration that another document had moved to Historic 
status. Not only that, these moves to Historic were not being properly 
kept track of, and it took a good deal of research to figure out when 
certain old docs became Historic, and why.

(BTW: Personally, I think it's bad form for any document to say, "This 
document moves X to Historic", as it does in this case. I think "This 
document requests that X be moved to Historic" is probably more 
accurate.)

In this case, the name of the Informational draft is so painfully 
obvious that I think the IESG could "just do the right thing". They 
certainly don't need to re-Last-Call this document; simply Last-Calling 
the move to Historic is (more than) sufficient. But lets not go back to 
the previous state of randomly, and without any breadcrumbs, declaring 
things as Historic.

pr-the-only-slightly-less-grumpy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Mar 2018 21:35:17 -0700

On Tue, Mar 27, 2018 at 12:56 PM, Benjamin Kaduk <[email-masked]> wrote:

> > Indeed it did.  I do not know whether the Last Call properly included
> it, bu the history tab clearly shows that the status change document was
> created on 10 Feb 2018.
> >
> > See https://datatracker.ietf.org/doc/status-change-suiteb-to-
> historic/history/ <https://datatracker.ietf.org/
> doc/status-change-suiteb-to-historic/history/>
>
> I was just looking at

This is my assessment as well. I didn't request this, but looks like the
secretariat caught the error!

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Mar 2018 11:03:01 -0400

Pete,

--On Tuesday, March 27, 2018 17:59 -0500 Pete Resnick
<[email-masked]> wrote:

> While I generally agree with John here, let's not forget what
> caused the IESG to put together that procedure in the first
> place and let's not get back to that previous state:
> 
> The problem is that "moving to Historic" is really a Standards
> Track thing to do. What was happening before is that these
> "moves" were being done in Informational RFCs, and anyone who
> didn't happen to notice the Last-Call for the document, or
> decided not to care all that much because the document was
> Informational, was not going to notice that the IESG was
> making this declaration that another document had moved to
> Historic status. Not only that, these moves to Historic were
> not being properly kept track of, and it took a good deal of
> research to figure out when certain old docs became Historic,
> and why.

Yes, absolutely.   That is also the reason why several of us
have argued for much clearer (and more obviously
available)definitions of what "obsolete" and "historic" actually
mean (and the relationship between the two) and against those
actions being taken by a note in the datatracker that can't be
found unless one knows where to look.  It is also why I believe
a reference to the documentation and rationale for the action
should be included in the RFC Editor's index pages.  

Those more formal and well-documented actions are particularly
important given our history of sometimes specifying the action
or its rationale in a statement or brief paragraph in the middle
of a document that is mostly about something else.  I assume
that was the reason the IESG has asked that a note about
documents being obsoleted be included in the abstract about the
obsoleting one.  IMO, while it may call attention to the action,
that information is sometimes appropriate in an abstract and
sometimes not, but it is rarely the best way to proceed if the
intent is to heighten awareness rather than to provide cover.

However, my point was that those concerns do not justify our
descending into mindless following of rules that may not
adequately cover all cases... or of forcing documents that
propose particular actions into rigid formats, especially
formats rigid enough to discourage actual reading.

> (BTW: Personally, I think it's bad form for any document to
> say, "This document moves X to Historic", as it does in this
> case. I think "This document requests that X be moved to
> Historic" is probably more accurate.)

Yes, probably.  But this is ultimately the same problem with
tense that we run into with "IANA is requested to..." (almost
always true in I-Ds) and "IANA has..." (typically true of RFCs
given current procedures for coordination between the RFC
Editor, IANA, and the IESG).  In a perfect world, we would
probably use the first forms in I-Ds and let the RFC Editor
change the text after the IANA action is taken and confirmed.
However, while I believe the current Production Center
arrangements are more reliable than things used to be, there
have been examples of the changes slipping through the cracks,
which creates a different type of confusion.   Perhaps what we
should be saying is more along the lines of "Thie memo documents
the move of X to Historic and the reason(s) for that move."

> In this case, the name of the Informational draft is so
> painfully obvious that I think the IESG could "just do the
> right thing". They certainly don't need to re-Last-Call this
> document; simply Last-Calling the move to Historic is (more
> than) sufficient.

Yes, exactly.  The intent was not exactly secret or easily
missed.   

> But lets not go back to the previous state
> of randomly, and without any breadcrumbs, declaring things as
> Historic.

Strongly agree.  If anything, we need clearer definitions,
better documentation, and more consensus about criteria.  What
we don't need is rigid rules that lack provision for exceptional
cases and that need to be followed mindlessly.

    john