Subject: Re: Last Call: <draft-resnick-retire-std1-00.txt> (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 3 Sep 2013 14:32:41 +0000

the quoted text came from RFC 1602 and is descriptive not proscriptive
removing a description of a process that is no longer followed makes
sense to me but might not warrant a RFC to do

but the 3rd paragraph in section 6.1.3 says:
   The RFC Editor shall publish periodically an "Internet Official
   Protocol Standards" RFC [1], summarizing the status of all Internet
   protocol and service specifications.

is a process requirement - 
this requirement is the specific text that should be removed 
and is worth spinning a RFC to do

and while you are at it - maybe you should remove the 2nd 
paragraph in the same section
   An official summary of standards actions completed and pending shall
   appear in each issue of the Internet Society's newsletter.  This
   shall constitute the "publication of record" for Internet standards
   actions.

should also be removed since that is not being done either
and it is not good to say we have a publication of record that 
does not actually exist

Scott
 
Scott O Bradner
Senior Technology Consultant

Harvard University Information Technology
Innovation & Architecture
(P) +1 (617) 495 3864
1033 Mass Ave, room 462
Cambridge, MA 02138

On Sep 3, 2013, at 10:16 AM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Retirement of the "Internet Official Protocol Standards" Summary
>   Document'
>  <draft-resnick-retire-std1-00.txt> as Best Current Practice
> 
> 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 2013-10-01. 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 updates RFC 2026 to no longer use STD 1 as a summary of
>   "Internet Official Protocol Standards".  It obsoletes RFC 5000 and
>   requests the IESG to move RFC 5000 (and therefore STD 1) to Historic
>   status.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-resnick-retire-std1/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Sep 2013 11:16:35 -0500

> and is worth spinning a RFC to do

Good catch. I'll switch the citation and the quote to the bit from 
6.1.3, but I'll also note the removal of the piece in 2.1. I also found 
a mention in the last paragraph of 3.3. I'll make sure to note in the 
document that we're removing that too.

> and it is not good to say we have a publication of record that

I agree it should probably be removed. Should we replace it anything?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2013 08:13:50 +1200

> I agree it should probably be removed. Should we replace it anything?

Maybe an informational statement that the current standards status is always
at http://www.rfc-editor.org/rfcxx00.html ? (Or whatever stable URL
the RFC Editor prefers to cite.)

      Brian

---

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Sep 2013 13:45:45 -0700

On 9/3/13 1:13 PM, Brian E Carpenter wrote:
>>> ...the 3rd paragraph in section 6.1.3...
>>>        

Here's what I've got as a replacement for section 1:

    RFC 2026 [RFC2026] and its predecessors call for the publication of
    an RFC describing the status of IETF protocols:

       The RFC Editor shall publish periodically an "Internet Official
       Protocol Standards" RFC [1], summarizing the status of all
       Internet protocol and service specifications.

    The "Internet Official Protocol Standards" document, now as RFC 5000
    [RFC5000], has always been listed in the Internet Standard series as
    STD 1.  However, the document has not been kept up to date in recent
    years, and it has fallen out of use in favor of the online list
    produced by the RFC Editor [STDS-TRK].  The IETF no longer sees the
    need for the document to be maintained.  Therefore, this document
    updates RFC 2026 [RFC2026], effectively removing the above mentioned
    paragraph from section 6.1.3, along with the paragraph from section
    2.1 that states:

       The status of Internet protocol and service specifications is
       summarized periodically in an RFC entitled "Internet Official
       Protocol Standards" [1].  This RFC shows the level of maturity and
       other helpful information for each Internet protocol or service
       specification (see section 3).

    and the paragraph from section 3.3 that states:

       The "Official Protocol Standards" RFC (STD1) lists a general
       requirement level for each TS, using the nomenclature defined in
       this section.  This RFC is updated periodically.  In many cases,
       more detailed descriptions of the requirement levels of particular
       protocols and of individual features of the protocols will be
       found in appropriate ASs.

    Additionally, this document obsoletes RFC 5000 [RFC5000], the current
    incarnation of that document, and requests that the IESG move that
    document (and therefore STD 1) to Historic status.

Makes me go over 2 pages, but such is life.

> the RFC Editor prefers to cite.)

I've fixed the reference to [STDS-TRK] so that it shows the URL. I'm not 
sure we need to make further reference to it.

Thinking about this more, we're starting to drift afield of the purpose 
of this document if we start removing that paragraph. Removing that 
paragraph requires a different explanation than the rest. Speaking for 
myself only, I'm leaning against dealing with it. Anyone want to speak 
strongly for or against?

pr

---

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 3 Sep 2013 20:49:17 +0000

in line

> Makes me go over 2 pages, but such is life.

life is hard sometimes :-)

the above text works for me

> I've fixed the reference to [STDS-TRK] so that it shows the URL. I'm not sure we need to make further reference to it.
> 
> Thinking about this more, we're starting to drift afield of the purpose of this document if we start removing that paragraph. Removing that paragraph requires a different explanation than the rest. Speaking for myself only, I'm leaning against dealing with it. Anyone want to speak strongly for or against?

no strong feeling either way

Scott

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 03 Sep 2013 15:58:03 -0500

On 9/3/2013 3:49 PM, Bradner, Scott wrote:
>   at it - maybe you should remove the 2nd

I agree that the explanation is different, but I go back to Scott's "it 
is not good to say we have a publication of record that does not 
actually exist".

Not that Pete and I get paid by the document on telechat agendas, but is 
this another candidate for a short draft?

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2013 10:17:05 +1200

Comment at the end...

On 04/09/2013 08:58, Spencer Dawkins wrote:
>>> I've fixed the reference to [STDS-TRK] so that it shows the URL. I'm
>>> not sure we need to make further reference to it.
>>>
>>> Thinking about this more, we're starting to drift afield of the
>>> purpose of this document if we start removing that paragraph.
>>> Removing that paragraph requires a different explanation than the
>>> rest. Speaking for myself only, I'm leaning against dealing with it.
>>> Anyone want to speak strongly for or against?
> 

<rant class="short">So that the reader of RFC 2026 will need to read yet
another document to get the full picture? There are currently 8 RFCs that
update RFC 2026, some of which have been updated themselves.</rant>

Quite seriously - I appreciate Pete's reluctance to overload the draft, but
it is a related topic. I'd be inclined to include it.

  Brian

---

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Sep 2013 16:02:24 -0700

> it is a related topic. I'd be inclined to include it.

OK, does this do anything for anyone?

    Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the
    publication of an "official summary of standards actions completed
    and pending" in the Internet Society's newsletter.  This has also not
    been done in recent years, and the "publication of record" for
    standards actions has for some time been the minutes of the IESG.
    [IESG-MINUTES] Therefore, that paragraph is also effectively removed
    from section 6.1.3.

pr

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 03 Sep 2013 18:20:19 -0500

>    [IESG-MINUTES] Therefore, that paragraph is also effectively removed

That would work for me.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2013 11:32:36 +1200

>>    [IESG-MINUTES] Therefore, that paragraph is also effectively removed

Me too.

   Brian

---

From: SM <[email-masked]>
Date: Tue, 03 Sep 2013 16:28:23 -0700

Hi Pete,
>    [IESG-MINUTES] Therefore, that paragraph is also effectively removed

I suggest using "IETF Announce mailing list" as the "publication of 
record".  The mailing list probably has a wider readership and anyone 
can subscribe to it.  The usage of the mailing list is also 
consistent with other parts of RFC 2026.

Regards,
-sm

---

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Sep 2013 17:03:31 -0700

On 9/3/13 4:28 PM, SM wrote:
> can subscribe to it.  The usage of the mailing list is also consistent 
> with other parts of RFC 2026.

The IETF Announce list does not say anything about "pending" standards 
actions. The IESG minutes do.

pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 5 Sep 2013 10:10:58 -0700

Having seen no further comments, Jari has asked me to post -01 with the 
changes. Done.

pr

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 5 Sep 2013 17:45:20 -0400

looks good to me except that maybe using the IETF Announce list rather than 
IESG minutes as the publication of record

Scott

On Sep 5, 2013, at 1:10 PM, Pete Resnick <[email-masked]> wrote:

> Having seen no further comments, Jari has asked me to post -01 with the changes. Done.
> 
> pr
> 
> --

---

From: Pete Resnick <[email-masked]>
Date: Thu, 5 Sep 2013 15:20:20 -0700

> IESG minutes as the publication of record

The only reason I went with the IESG minutes is because they do state 
the "pending" actions too, as well as the completed ones, which the IETF 
Announce list does not. For instance, the IESG minutes say things like:

"The document remains under discussion by the IESG in order to resolve 
points raised by..."

"The document was approved by the IESG pending an RFC Editor Note to be 
prepared by..."

"The document was deferred to the next teleconference by..."

The minutes also of course reflect all of the approvals. So they do seem 
to more completely replace what that paragraph as talking about. And we 
have archives of IESG minutes back to 1991; we've only got IETF Announce 
back to 2004.

I'm not personally committed to going one way or the other. The minutes 
just seemed to me the more complete record.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Sep 2013 10:40:21 +1200

I tend to agree with Pete - the minutes are more like an official
record, as well. BTW, the IESG Charter (RFC 3710) says:

"The IESG publishes a record of decisions from its meetings on the
Internet,..."

In any case, apart from this detail, I think the draft is good to go.

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 6 Sep 2013 01:41:45 +0300

I also agree that the minutes are the most complete/official record we have.

Jari

---

From: SM <[email-masked]>
Date: Thu, 05 Sep 2013 16:54:51 -0700

>IESG minutes as the publication of record

What draft-resnick-retire-std1-01 says is that the "publication of 
record" has been the IESG minutes.  I read what Scott Bradner wrote 
as meaning that the IETF will use the IETF Announce list as the 
publication of record.

Suggested text:

    Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the
    publication of an "official summary of standards actions completed
    and pending" in the Internet Society's newsletter.  This has also not
    been done in recent years.  Therefore, that paragraph is also
    effectively removed from section 6.1.3.  The "publication of record"
    for standards action is the IETF Announce list.

The idea here is to announce the standards action that has been 
taken.  By the way, "publication of record" is different from formal record.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Sep 2013 21:48:19 -0400

--On Thursday, September 05, 2013 15:20 -0700 Pete Resnick
<[email-masked]> wrote:

> The only reason I went with the IESG minutes is because they
> do state the "pending" actions too, as well as the completed
> ones, which the IETF Announce list does not. For instance, the
> IESG minutes say things like:
>...
> The minutes also of course reflect all of the approvals. So
> they do seem to more completely replace what that paragraph as
> talking about. And we have archives of IESG minutes back to
> 1991; we've only got IETF Announce back to 2004.
> 
> I'm not personally committed to going one way or the other.
> The minutes just seemed to me the more complete record.

Pete, Scott,

The purpose of the "Official Protocol Status" list was, at least
IMO, much more to provide a status snapshot and index than to
announce what had been done.  I think the key question today is
not "where is it announced?" but "how do I find it?".  In that
regard, the minutes are a little worse than the announcement
list today, not because the announcement list contains as much
information, but because the S/N ratio is worse.

With the understanding that the Official Protocol Standards list
has not been issued/updated in _many_ years, wouldn't it make
sense to include a serious plan about information locations,
navigation, and access in this?  For example, if we are going to
rely on IETF minutes, shouldn't the Datatracker be able to
thread references to particular specifications through it?  The
tracker entries that it can access appear to be only a tiny
fraction of the information to which Pete's note refers.

   john