Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Sep 2016 12:58:37 +1200

> Note to Readers
> 
>    This draft should be discussed on the wgchairs mailing list [1].

Um, no. That's a closed list.

Regards
   Brian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 15 Sep 2016 08:58:36 -0400

I noticed that as well in the announcement. The proper place to discuss
this draft is most probably [email-masked] .

Cheers,
Andy

---

From: Erik Wilde <[email-masked]>
Date: Thu, 15 Sep 2016 09:15:39 -0400

hello andy.

On 2016-09-15 08:58, Andrew G. Malis wrote:
> this draft is most probably [email-masked]
> <mailto:[email-masked]> .

https://github.com/dret/I-D/commit/b829472334b60fd0f9124b0448e3a33c1d81129d 
fixes that, thanks for letting me know. it will be updated in the next 
published version.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Sep 2016 11:13:41 -0400

As the draft is probably about IETF process, not RFC Editor rules, I 
would think that [email-masked] would be the venue for discussing the 
draft, unless Jari thinks it needs a separate list (which I doubt).

Yours,
Joel

On 9/15/16 8:58 AM, Andrew G. Malis wrote:
> On Wed, Sep 14, 2016 at 8:58 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > Note to Readers
>     >

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Sep 2016 12:37:14 -0400

--On Thursday, September 15, 2016 11:13 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> As the draft is probably about IETF process, not RFC Editor
> rules, I would think that [email-masked] would be the venue for
> discussing the draft,
>...

I concur with Joel about the above.   

Note that there have been multiple discussions on the topics of
"what does 'updates' mean" and "what should saying 'updates'
require" with the RFC Editor and, at least as few times, with
the IESG in the last decade or so.   My recollection is that
there have also been a few discussions of the same topic on this
list, mostly during Last Call discussions about the adequacy of
various documents and the closely-related topic of what it means
to have a normative reference to an obsoleted document or an
updated section of an earlier one.   Those discussions have
exposed another issue, which is that we have no way to obsolete
a section (even an appendix) of a document, only to update it to
deprecate that section.  

There are also some interactions between this work and the late
NEWTRK efforts whether one views the failure of those efforts to
be a good thing or, at the other extreme, an abuse of power by
the IESG and a significant loss to the community.  However, one
obvious lesson from that work is that our failure to be specific
about something in a BCP sometimes indicates that we have made
an effort to agree and failed, rather than that we have not
considered the issue.

NEWTRK aside, it is not clear to me that any of those
discussions have reached any conclusion, almost certainly not a
conclusion that has been put through Last Call or otherwise
gotten to a stage where anyone could claim community consensus
around the conclusions.  It appears to me that several of them
suggest that being precise about what is changed or what
sections of earlier documents are affected is at least as
important as the "reason for changes" on which the current I-D
appears to be focused.  Independent of where it is discussed (as
long as it is on a public list), this I-D would be, at least
IMO, a much more satisfactory basis for discussion if it
demonstrated more convincingly that the author was aware of
those earlier discussions and had considered them, rather than
assuming (or appearing to assume) that no one had thought about
these topics.

best,
     john

---

From: Heather Flanagan <[email-masked]>
Date: Thu, 15 Sep 2016 10:49:28 -0700

From the RFC Editor perspective, I’m hoping that this document will touch on more than just the IETF stream. Both the IAB and the Independent Submissions streams (but not the IRTF stream) contain Updates/Obsoletes. Not many, but they do exist and should be accounted for.

-Heather

On September 15, 2016 at 9:11:40 AM, Joel M. Halpern ([email-masked]) wrote:

Yours,  
Joel  

-- 
Heather Flanagan
RFC Series Editor

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Sep 2016 13:56:58 -0400

I agree that it would be good if those streams paid attention to the 
discussion.  It would be particularly good if they made the same choices 
about meaning.
But due to our history, it seems to me that the decision to do that is 
up to each stream.  And thus the IETF having the discussion is helpful. 
I would hope that if the IAB or IRTF (or ISE) have observations about 
the approaches, the IETF would pay attention to that.

Yours,
Joel

On 9/15/16 1:49 PM, Heather Flanagan wrote:
> From the RFC Editor perspective, I’m hoping that this document will
> touch on more than just the IETF stream. Both the IAB and the
> Independent Submissions streams (but not the IRTF stream) contain
> Updates/Obsoletes. Not many, but they do exist and should be accounted for.
>
> -Heather
>
> On September 15, 2016 at 9:11:40 AM, Joel M. Halpern
> ([email-masked] <mailto:[email-masked]>) wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Sep 2016 08:58:49 +1200

Everybody's correct, IMHO. We need to have a general explanation of
what "updates" (and "obsoletes", but that's simpler) means that will
apply to all RFCs, and we need specific guidance within the standards
track in particular.

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Sep 2016 15:02:54 -0700

Brian,

> On Sep 15, 2016, at 1:58 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree.  However, it would be confusing if the streams adopted different definitions of what update and obsolete means.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2016 14:09:50 +1200

Hi,

First two general comments:

1. I do think we need to clarify this topic. However, I want to
repeat my earlier comment: IMHO the *generic* explanation of
what "Updates:" means should come from the RFC Editor. It can
be quite short, and there should be some community discussion.

So I will treat this draft as describing how the IETF stream
interprets "Updates:", within that generic explanation, and the
other RFC streams are free to make their own interpretations
(or adopt this one, if they want).

2. John Klensin, at
https://mailarchive.ietf.org/arch/msg/ietf/qdDAtDC0jIKoUgZUFwGUuQSDQyo
referred to earlier discussions, including in NEWTRK. Indeed we have
some unfinished business - how on earth is a consumer of RFCs supposed
to know which bits of which RFCs she needs to implement, and which bits
*not* to implement, to produce interoperable code? If A claims to
be the standard, but B updates it, while C obsoletes A without mentioning
B, etc. etc., what is a poor programmer to do?

If you don't appreciate the complexity of this question, here are
two illustrations, one of which is close to home for the IETF itself:
https://tools.ietf.org/html/rfc6434
https://www.ietf.org/about/process-docs.html
They are both out of date, of course.

I suggest that this complicated question still needs to be answered,
but this draft is not the place to do it.

Now for my specific comments:

>    RFC authors that use "Updates" in their document should include
>    individual "Reasons for updating ..." sections for each updated RFC.
>    These sections should be placed relatively early in the document.  In
>    each of these sections, there should be a short description of the
>    nature of the update.

IMHO this is too bureaucratic and will make the result noisy and awkward
to read. I believe it is reasonable to require that the changes are easy
to find, but that doesn't require separate sections. For example, in
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
which updates RFC 4861, searching for the text string 4861 will do the
trick, and you will see the changes in context.

So I would advocate something more like:

RFC authors that use "Updates" in their document should ensure that
the specific updates are easy to identify, preferably by citing the
specific section of the updated RFC in the updating text. A general
rationale for the updates should be prominent in the document's
Introduction.

(Then the word "sections" in the following two paragraphs could
be changed to "updating text".)

An organizational comment: The three paragraphs starting with
"Generally speaking,..." would be much better moved to the beginning
of section 3, since they motivate what follows.

>    The second motivation is that the updating RFC is a backwards
>    compatible extension, which means that strictly speaking, it does not
>    even need to mention the updated RFC.  

I disagree. If I maintain the code for foobar, I'd really like to
receive a ping when the RFC extending it to foobar+ comes out. So unless
we introduce a new metadatum "Extends:", I think that we really should
use "Updates:" for extensions. At the minimum, I need to check that
incoming foobar+ extensions won't break anything.

You might want to review RFC6709, in which the IAB uttered:
"  1.  Modifications or extensions to the underlying protocol.  An
       extension document should be considered to update the underlying
       protocol specification if an implementation of the underlying
       protocol would need to be updated to accommodate the extension.
       This should not be necessary if the underlying protocol was
       designed with a modular interface."
(https://tools.ietf.org/html/rfc6709#page-5)

By the way, a can of worms that you don't mention is updates by other
SDOs. There's a BCP for that: https://tools.ietf.org/html/rfc4775

Regards
   Brian Carpenter

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Sep 2016 11:24:19 +0300

FWIW, [email-masked] is probably a good place to discuss the general topic of Updates: and its semantics. I realise that there’s a distinction between what the RFC format and IETF stream semantics are. But frankly, I can’t get excited about that, and in either case… this is a topic that the community needs to discuss if we are going to define better semantics.

My personal opinion is roughly where Brian’s comments were.

I’ll add that there’s plenty of variation of thought for the semantics of Updates, both in terms of what different people think and what has been done over time for different RFCs. The semantics have been vague, and even if we institute a new agreed policy, it doesn't change past RFCs. Going forward, in general, I’m in favour of explaining, explicitly, in the RFC what it means. Why are we updating, obsoleting or extending something previously defined? What are the changes? What are the impacts if you do this or don’t do this?

Jari

---

From: Erik Wilde <[email-masked]>
Date: Thu, 29 Sep 2016 21:55:23 +0200

hello joel.

> draft, unless Jari thinks it needs a separate list (which I doubt).

ok, thanks for the feedback, and i have changed the recommended 
discussion list to be [email-masked].

thanks again and kind regards,

dret.