Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

From: Flemming Andreasen <[email-masked]>
Date: Thu, 1 Sep 2016 11:12:31 -0400

+1

On 8/31/16 10:53 AM, Christer Holmberg wrote:
> +1
>
> -----Original Message-----
> From: WGChairs [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 31 August 2016 17:28
> To: [email-masked]
> Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?
>
> I can understand how these terms might have originated without formal definition. But is that all there is? It sounds like this has been discussed before, and there has been an inability to agree. Is that true?
>
> It also sounds like there is a lack of desire (on the part of the IESG) to have a formal definition. I find that to be the most troubling.
>
> If we cannot agree on a definition for UPDATES, then ISTM we would be better off without having this as a formal piece of metadata.
>
> If there is active disagreement on what UPDATES means, but there is still desire to have metadata about this, then I propose that we define
> *new* terms that *can* be agreed upon.
>
> 	Thanks,
> 	Paul
>
> On 8/30/16 5:44 PM, Stephen Farrell wrote:
>> Hiya,
>>
>> On 30/08/16 22:01, Flemming Andreasen wrote:
>>> I share your concern and agree there is a need to get the meaning of
>>> these terms clearly defined
>> So I'd note that the sky has not fallen despite pretty much all RFC
>> metadata (incl. Updates) being ill-defined for many years.
>> (When I started on the IESG that also irritated me and I tried but
>> failed to write down a self-consistent and useful description of them
>> all;-)
>>
>> So is it really true that there is "a need" here? Or is it maybe more
>> that we pretty much all much prefer tidy situations?
>>
>> Personally, I think it's the latter in this case.
>>
>> I also think it's quite unlikely that we spend productive cycles that
>> arrive at a rough consensus that works.
>>
>> So, while I'd be happy (as an IESG member) to see such a rough
>> consensus of the IETF, I can't see it happening tbh. But if some folks
>> want to give it a shot, you have my best wishes.
>>
>> Cheers,
>> S.
>>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 1 Sep 2016 13:58:29 -0700

On 8/31/16 12:14 PM, joel jaeggli wrote:
> On 8/30/16 7:45 AM, Adrian Farrel wrote:
>> All,
>>
>> I'm discombobulated by the wide variety of views on this subject. It
>> is not the views themselves that bother me, but the variety.
>>
>> In my experience as a document author, this divergence is both
>> frustrating and a destabilising waste of time when deciding whether
>> and how to set the metadata for a document. The authors debate it,
>> the WG debates it, the chairs give advice, the AD changes that
>> advice, the IESG makes a pronouncement. This means that the authors
>> would be best advised to make a guess and then make no more changes
>> until the IESG tells them what to do.
>>
>> Of course, it would be nice if the IESG would give some solid
>> guidance for *new* RFCs. Then we would all know what we are saying
>> when we mark a document as "Updates".

The difference between something we choose to call -bis(twice) and
updates seems instructive.

The bis document I would expect to be stand-alone with respect to
previous ones. it is self contained barring normative references.

When I am looking at a document for which there are updates I interpret
the whole thing inclusive of the updates rather than consider the
document in isolation. Similar considerations apply to the inclusion of
normative references. Updates may offer clarification, extension,
implementation advice, deprecation, criticism, but the assumption should
be that the  specification being updated needs to be read as including
them; as it has been updated.

>> I prefer the meaning "If you are implementing RFCxxxx you now need to
>> also implement RFCyyyy" (where yyyy updates xxxx). This is very
>> different to the case where RFCzzzz provides some extensions that
>> form part of a suite that comprise a protocol: IMHO we have no
>> metadata for this.
>>
>> It may be helpful to not think about "implementing an RFC" but to
>> think about implementing a protocol (or process). For example, the
>> IETF's IPR policy is documented in RFC 3979. That document is updated
>> by RFC 4879. If someone were to say "I am compliant with RFC 3979"
>> this would not be the same as saying "I am compliant with the IETF's
>> PR policy".
>>
>> FWIW, the advice I try to give as chair (and that I tried to give as
>> AD) is that "Updates" means "forms part of and must be implemented
>> along with". And, as been noted by others, "Y updates X" means you
>> could rewrite X to include the text of Y and produce "Z obsoletes X"
>> (something we really should do more often). But Y is in the same set
>> of documents as X does not (must not) give rise to "Y updates X".
>>
>> Now, arguably, this is something the RFC Editor can lay down. I don't
>> mind if it comes from there or from the IESG, but I believe it would
>> be helpful (for new documents) if we all meant the same thing.
>>
>> Adrian
>>
>>> -----Original Message----- From: WGChairs
>>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat Sent:
>>> 30 August 2016 15:15 To: [email-masked] Subject: Re: "Updates:
>>> RFC xxx" - what does it actually mean ?
>>>
>>> On 8/30/16 9:44 AM, Donald Eastlake wrote:
>>>
>>>> An RFC isn't change by an updating RFC. A Protocol might be
>>>> normatively changed or just optionally extended or whatever. But
>>>> if you were compliant with RFC X, you are still compliant with
>>>> RFC X regardless of what other RFCs are published.  If RFC X
>>>> specifies protocol Z, the publication of another RFC might means
>>>> that you were no longer compliant with the current protocol Z,
>>>> but that is a different matter.
>>>
>>> This is an interesting position. But I don't understand what it
>>> means in practice.
>>>
>>> This might work fine if protocol Z is versioned, with RFC X
>>> specifying version N and the update specifying version N+1. But
>>> what if the updates don't update a version number?
>>>
>>> Thanks, Paul
>>
>>
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:30 +0000

The answer no, because anyone reading the original RFC would not automatically be reading the updated RFC. All your statement would effectively say is that anyone implementing the updated RFC should comply with the updated RFC, which all RFCs take as read.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 30 August 2016 20:06
To: Drage, Keith (Nokia - GB); Cullen Jennings; Flemming Andreasen
Cc: [email-masked]
Subject: RE: "Updates: RFC xxx" - what does it actually mean ?

Hi,

To give an example from my own work: I have a draft which updates an RFC by modifying text in one or more chapter.

Do I also need to say whether someone using the RFC now also automatically supports the modified text in the draft???

Regards,

Christer

-----Original Message-----
From: Drage, Keith (Nokia - GB) [mailto:[email-masked]]
Sent: 30 August 2016 21:55
To: Christer Holmberg <[email-masked]>; Cullen Jennings <[email-masked]>; Flemming Andreasen <[email-masked]>
Cc: [email-masked]
Subject: RE: "Updates: RFC xxx" - what does it actually mean ?

To add a few notes from my own perspective.

1)	Any RFC that updates a prior RFC should be absolutely clear on how it modifies the prior document. In that respect, discussion of EXTENDS and REVISES is irrelevant.

2)	It is perfectly legitimate to implement an historical RFC. In the same respect it is perfectly legitimate to implement an RFC that has been subsequently updated. Conformance takes no account of whether the result works or interoperates. 

3)	Anybody, and especially an SDO, referencing an RFC should be very precise as to whether the requirements of the update are included in their reference or not. It may be that the update is totally irrelevant to the purpose of the original reference; conversely it may be essential for interoperability.

So my response to Fleming's original questions:

1)	No.
2)	Not applicable.
3)	Not in detail. One has to follow the precedent set by "replaces".

Regards

Keith

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30 August 2016 12:04
To: Cullen Jennings; Flemming Andreasen
Cc: [email-masked]
Subject: Re: "Updates: RFC xxx" - what does it actually mean ?

Hi,

In my experience, we produce update drafts when there is a bug, and/or when the procedures are incomplete/unclear, in the base RFC. We don¹t produce update drafts in order to add new features and functionality (unless it¹s needed to fix/clarifying the existing procedures).

So, while people may claim they are compliant with the base RFC, most likely they have made their own decisions and assumptions regarding the missing/unclear/broken stuff, which likely will cause interoperability problems with others that also claim RFC compliance.

Supporting the update drafts is good for the internet :)

Regards,

Christer

On 30/08/16 01:30, "WGChairs on behalf of Cullen Jennings"
<[email-masked] on behalf of [email-masked]> wrote:

>
>> On Aug 29, 2016, at 1:22 PM, Flemming Andreasen <[email-masked]>
>>wrote:
>> 
>> Greetings
>> 
>> Let's say I have "RFC X", and I then publish "RFC Y", which includes
>>"Updates: RFC X" on its title page.
>> 
>> 1) In order for me to be compliant with RFC X, MUST I now also be 
>>compliant with RFC Y ?
>
>FWIW ... I've had customer outside the IETF treat it much like an 
>"errata" in other SDOs and say that device were not compliant with X 
>unless they also did the things the updates required.  I guess the 
>question is if it does not mean this, what does it mean and how is it 
>different than not having an update.
>
>When we say RFC 5378 updates RFC 2026. I don't think we mean things can 
>continue doing what was in 2026 and disregard 5378. I realize that 
>might be slightly different than the case at hand.
>
>> 
>> 2) If yes, what if RFC Y introduced a non-backwards compatible change 
>>to RFC X ?
>> 
>> 3) Is the answer to 1) documented somewhere ?
>> 
>> Thanks
>> 
>> -- Flemming
>> 
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:35 +0000

The vendor has to be clear as to what is implemented, but that is nothing to do with IETF. That is part of normal contract law.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 31 August 2016 16:45
To: Ben Campbell
Cc: Mirja Kuehlewind; Cullen Jennings; Flemming Andreasen; [email-masked]; [email-masked]; Drage, Keith (Nokia - GB); RFC Editor
Subject: RE: "Updates: RFC xxx" - what does it actually mean ?

Hi,

....

>The idea of a formal definition for "updates" seems to focus more on compliance than interop.

That's what vendors are normally asked by their potential customer: "Are you compliant with RFC X".

Then, if RFC X has been updated by RFC Y, the customer and vendor may have a different understanding regarding the compliance. One may think that it includes RFC Y, while the other may not.

Regards,

Christer

>> Am 31.08.2016 um 14:36 schrieb Cullen Jennings <[email-masked]>:
>>
>>
>> Adding IESG and RFC Ed to see if they have any input on what RFC X 
>> "updates"  RFC Y means
>>
>>
>> So here is my understanding of how it "updates" works - I have no 
>> idea why I thought this and it is possibly totally wrong. I'm not 
>> aware of it being writing down anywhere
>>
>> If RFCs A, B, and C normatively reference X, then we discover a 
>> problem in X that needs to be fixed, we make an RFC Y that fixes that 
>> and Y is marked as "updating" X. Now A, B, and C normatively depend 
>> on Y.  The reasons to have this process is so that when this type of 
>> change is needed to X, we don't want to have to go and issue new 
>> version of A, B, and C to point at Y instead of X.
>>
>> I know that at one point of time the IESG did use this type of 
>> approach when deciding to use update or not - no idea what they do 
>> now. Whatever you think "update" means, there are probably many 
>> examples that violate that definition because this thread has made it 
>> obvious it's not totally clear to everyone what updates means.
>>
>>
>>
>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:35 +0000

While interoperability is a fundamental issue of RFC design, it has nothing to do with whether an RFC has an update or not. 

One would hope that an implementation to RFC xxxx as updated by RFC yyyy would interoperate with one to RFC xxxx alone, but there are many reasons where it would not do so, if only because what is being corrected is an interoperability fault in RFC xxxx.

Keith

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 31 August 2016 16:14
To: Christer Holmberg
Cc: Mirja Kuehlewind; Cullen Jennings; Flemming Andreasen; [email-masked]; [email-masked]; Drage, Keith (Nokia - GB); RFC Editor
Subject: Re: "Updates: RFC xxx" - what does it actually mean ?

On 31 Aug 2016, at 9:28, Christer Holmberg wrote:

> Hi,
>
>> https://tools.ietf.org/rfc/ says:
>>
>> "Obsoletes xxxx refers to other RFCs that this one replaces; 
>> Obsoleted by xxxx refers to RFCs that have replaced this one.
>> Updates xxxx refers to other RFCs that this one merely updates but 
>> does not replace); Updated by xxxx refers to RFCs that have updated 
>> (but not replaced) this one.  >Generally, only immediately succeeding 
>> and/or preceding RFCs are indicated, not the entire history of each 
>> related earlier or later RFC in a related series.“
>>
>> So your definition below is probably not quite correct because 
>> ‚updates' does not replace the original document. It only means if 
>> you want to implement the RFC you >should also read the ones that 
>> update it because they might change part of the spec.
>>
>> Does it make sense?
>
> What if I state compliance with the original document? Does that mean 
> I am also compliant with the update(s)?
>

A better question would be "Do I still interoperate with other implementations of the protocol?" (Let's call it FOO.)

I think that's where the disconnect lies between the IETF and other SDOs (and unfortunately commercial companies). None of this is about compliance. The IETF in general does not think in terms of compliance, it thinks in terms of interoperability. That may sound like too fine of a point, but I don't think it is. If my implementation interoperates with other implementations of FOO, then I support FOO. All those 2119 keywords in the potentially many RFCs that describe FOO are a tool to that end, not an end in themselves.

>> idea
>> why I thought this and it is possibly totally wrong. I'm not aware of
>> it being writing down anywhere
>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:47 +0000

My original comment was slightly complimentary to this - that the UPDATE has to be very clear on how it modifies the original document, i.e. which elements using any RFC 2119 language are modified or rescinded.

Keith

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 31 August 2016 17:07
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

Yes, that (clearity early in the document) is probably a good answer.
I note that id-nits does complain if there is no reference to the updating in the abstract.

So maybe we are already doing as good a job as we reasoanably can.

Yours,
Joel

On 8/31/16 12:01 PM, Ben Campbell wrote:
> I agree with both cases. That's why I suggested that the updatING RFC 
> should explain the nature of the update. Preferably in a place one can 
> find quickly, such as the abstract. E.g...
>
>   "This document updates RFC XXXX to better support turnip twaddling 
> using the FOO protocol."  --which one could ignore if you didn't care 
> bout that use case, vs...
>
>   "The FOO protocol as described in RFC XXXX will melt the Internet 
> and send all your private data to the mob. This document updates that 
> specification to fix critical bugs." -- which one probably shouldn't 
> ignore.
>
> Both are reasonable uses of "updates".
>
> Ben.
>
> On 31 Aug 2016, at 10:52, Joel M. Halpern wrote:
>
>> I agree that the guidance in terms of "updates" that is helpful is 
>> guidance to the reader as to how to understand the marking.
>>
>> The problem is that we have not been consistent, and are not 
>> currently consistent.  We use updates for two different cases, as far 
>> as I can
>> tell:
>>
>> One case is when a new document has to adjust a rule in the base 
>> document, for the case it covers.  For example, the base document 
>> (RFC
>> A) says that field X must be zero on transmission and ignored on 
>> reception.  The new document (RFC B) uses field X.  Obviously, if you 
>> are implementing RFC B, you need to be told that the existing text in 
>> this regard in RFC A is no longer correct.
>>
>> The other case is where we determine that some aspect of RFC A was 
>> not a good idea.  While we sometimes do this by obsoleting the base 
>> document, when the change is small we often do not want to do that.
>> So we instead publish the correction as an update.
>>
>> A reader presented with a tag saying "updated by" does not know which 
>> of these two cases apply.
>> Unfortunately, as far as I can tell, both are reasonable uses.  And 
>> trying to create another tag to distinguish them is likely to further 
>> confuse the reader rather than helping.
>>
>> Yours,
>> Joel
>>
>> On 8/31/16 11:23 AM, Ben Campbell wrote:
>>> I think a _formal_ definition would be at best pointless and at 
>>> worst harmful. I say that under the assumption is that a formal 
>>> definition would be one where the metadata fully defines the relationship.
>>>
>>> OTOH, some practical guidance might be useful But if we were to 
>>> write down a definition, I think it should be along the lines of "If 
>>> you see an "Updated by" label on an RFC, you need to also read (or 
>>> be aware of) the updating document. The updating document should 
>>> describe the nature of the update, preferably in the abstract."
>>>
>>> Ben.
>>>
>>> On 31 Aug 2016, at 9:27, Paul Kyzivat wrote:
>>>
>>>> I can understand how these terms might have originated without 
>>>> formal definition. But is that all there is? It sounds like this 
>>>> has been discussed before, and there has been an inability to 
>>>> agree. Is that true?
>>>>
>>>> It also sounds like there is a lack of desire (on the part of the
>>>> IESG) to have a formal definition. I find that to be the most 
>>>> troubling.
>>>>
>>>> If we cannot agree on a definition for UPDATES, then ISTM we would 
>>>> be better off without having this as a formal piece of metadata.
>>>>
>>>> If there is active disagreement on what UPDATES means, but there is 
>>>> still desire to have metadata about this, then I propose that we 
>>>> define *new* terms that *can* be agreed upon.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>>> I share your concern and agree there is a need to get the meaning 
>>>>>> of these terms clearly defined
>>>>>
>>>>> So I'd note that the sky has not fallen despite pretty much all 
>>>>> RFC metadata (incl. Updates) being ill-defined for many years.
>>>>> failed to write down a self-consistent and useful description of 
>>>>> them all;-)
>>>>>
>>>>> So is it really true that there is "a need" here? Or is it maybe 
>>>>> more that we pretty much all much prefer tidy situations?
>>>>>
>>>>> I also think it's quite unlikely that we spend productive cycles 
>>>>> that arrive at a rough consensus that works.
>>>>>
>>>>> consensus of the IETF, I can't see it happening tbh. But if some 
>>>>> folks want to give it a shot, you have my best wishes.
>>>>>
>>>>> Cheers,
>>>>> S.
>>>>>
>>>
>>>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 4 Sep 2016 14:39:04 +0000

On 9/3/16, 8:48 AM, "WGChairs on behalf of Drage, Keith (Nokia - GB)"
<[email-masked] on behalf of [email-masked]> wrote:

>While interoperability is a fundamental issue of RFC design, it has
>nothing to do with whether an RFC has an update or not.
>
>One would hope that an implementation to RFC xxxx as updated by RFC yyyy
>would interoperate with one to RFC xxxx alone, but there are many reasons
>where it would not do so, if only because what is being corrected is an
>interoperability fault in RFC xxxx.

I believe in the latter case everyone would agree that RFC xxxx updates
RFC yyyy. The case in question is where RFC yyyy enhances the basic
functionality of RFC xxxx in a backward compatible manner. At least in the
WG I co-chair, we have been treating the backward-compatible enhancement
as an update. Adrian has proposed that doing so is confusing and we should
not be flagging these enhancements as “updates”. I agree with Adrian and
many others who have lamented that we really do need a definitive
guideline moving forward.

Thanks,
Acee

>Cc: Mirja Kuehlewind; Cullen Jennings; Flemming Andreasen;
>[email-masked]; [email-masked]; Drage, Keith (Nokia - GB); RFC Editor
>A better question would be "Do I still interoperate with other
>implementations of the protocol?" (Let's call it FOO.)
>
>I think that's where the disconnect lies between the IETF and other SDOs
>(and unfortunately commercial companies). None of this is about
>compliance. The IETF in general does not think in terms of compliance, it
>thinks in terms of interoperability. That may sound like too fine of a
>point, but I don't think it is. If my implementation interoperates with
>other implementations of FOO, then I support FOO. All those 2119 keywords
>in the potentially many RFCs that describe FOO are a tool to that end,
>not an end in themselves.
>

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 4 Sep 2016 15:13:12 -0400

Hi,

On Tue, Aug 30, 2016 at 10:14 AM, Paul Kyzivat <[email-masked]> wrote:
>> An RFC isn't change by an updating RFC. A Protocol might be normatively
>> changed or just optionally extended or whatever. But if you were
>> compliant with RFC X, you are still compliant with RFC X regardless of
>> what other RFCs are published.  If RFC X specifies protocol Z, the
>> publication of another RFC might means that you were no longer compliant
>> with the current protocol Z, but that is a different matter.
>
> This is an interesting position. But I don't understand what it means in
> practice.

Then there must be some miscommunication because I think it is
startlingly simple. RFC's are and always have been immutable, like
books on a shelf. You should say what you mean and mean what you say.
If you say you are compliant with RFC X, it means just what it says.
No publication of other RFCs, whether or not they claim to "update",
"obsolete", "make historic" or whatever to RFC X actually changes even
a single letter in RFC X and makes not the slightest difference to
what you have to comply with to make your statement of compliance
true.

> This might work fine if protocol Z is versioned, with RFC X specifying
> version N and the update specifying version N+1. But what if the updates
> don't update a version number?

What do protocols have to do with it? The question had to do with
compliance with an RFC, not compliance with a protocol.

In any case, protocols in the IETF can be sort of implicitly version
by specifying what RFCs you are including in the protocol version you
are aiming for compliance with. For example, protocol X as of some
date, which implicitly references the relevant RFCs issued before that
data and only those RFCs. Or you can say things like Protocol X as
specified in RFCs through RFC Y but excluding RFC Z.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 4 Sep 2016 17:58:43 -0400

Hi,

On Tue, Aug 30, 2016 at 10:16 AM, Paul Kyzivat <[email-masked]> wrote:
> On 8/30/16 5:02 AM, Tero Kivinen wrote:
>>
>> Paul Kyzivat writes:
>>>
>>> I fear that what Steven says is true. But it doesn't seem like a good
>>> thing. ISTM it would be better to define what we want these things to
>>> mean. I think that means we ought to factor UPDATES into EXTENDS and
>>> REVISES.

Yes, deprecating Updates and providing the options of Extends or
Revises would be good. But perhaps this is something for the RFC
Editor and/or IAB to decide. On the other hand, the IESG seems to have
de facto control over the use of Updates. It used to be some merger of
revises and/or extends but lately the IESG has been refusing to
approve drafts that use Updates when the new document extends an older
protocol specification.

>>> What is one to do when the update fixes a true bug?

Why is this a question? If there is a real bug, you should document it
and the fix in a subsequent document.

>> I think the correct level is obsoletes.... I.e., if the bug is so bad
>> that everybody needs to fix it, obsolete the old rfc, and make new
>> one.

Obsoleting an RFC with a replacement RFC is obviously cleaner but is a
bit ridiculous if the original is lengthy and the fix small. I think
it is fine to normally just leave it up to the authors whether they
want to do a bis document or an Updates document. The WG/AD/IESG can
always step in if they think things are too extreme either way.

There can also be more complex cases. RFC 6325 is quite a lengthly and
detailed specification. There were some typos in it for which Errata
were entered. Several RFCs were issued "Updating" it due to either
substantially extending some facet of it or providing a substantially
more detailed specification of some facet. But over a few years there
was also an accumulation or assorted minor fixes and extensions so RFC
7180 was issued with "Clarifications, Updates, and Corrections" to
Update RFC 6325. RFC 7180 also covered the Errata to RFC 6325. A few
years further on, there were additional minor fixes and extensions. At
this point an RFC 6325bis could have been done rolling them all into
one. Or an additional updates RFC so that you have to look at 6325,
7180, and the additional RFC. Instead, an RFC 7180bis (RFC 7780) was
done incorporating all the updates from 7180 and obsoleting 7180 so
you were OK looking at 6325 and 7780 if you wanted to be up to date on
the protocol.

Thanks,
Donald

> The trouble with that is it means the updating RFC must be a full bis,
> rather than simply specifying the changes.
>
>         Thanks,
>         Paul
>
>
>> We did that for RFC4753, which defined the ECP Diffie-Hellman saying
>> that we use combined x and y, and then there was errata saying, we use
>> only x, but not all vendors noticed this errata, and then 3 years
>> later when this actually come out as an issue, when some vendors
>> implemented the base RFC4753 and others followed the errata, we fixed
>> this by obsoleting RFC4753 and repaced with RFC5903.
>>
>> Other case where we would like to everybody to fix things was the
>> Diffie-Helmman check for IKE, i.e. the RFC5996 said no checks needed,
>> but then we made new RFC6989 which defined tests you need to do if you
>> use certain groups, and/or reuse private values. This new RFC updateed
>> the RFC5996, so hopefully people implementing RFC5996 also read it and
>> followed it, especially if they reused private values.
>>
>> Then when RFC5996bis was done and published as RFC7296 the update done
>> in the 6989 was rolled in and is now mandatory part of the IKEv2.
>>
>> I.e., if there is really something that everybody needs to update,
>> then I think correct thing is to obsolete old document and replace it
>> with new. If it is something that is nice to have, or only needed in
>> certain cases, then Updates is ok.
>>
>> The bigger question what to do with extensions, which do not really
>> change anything in the base document, but defines new things.
>> Sometimes we just make them as separate standalone RFCs, sometimes we
>> say they update base document. It is matter of how important the
>> extension is. If it is something that is something that everybody is
>> expected to implement, then I think updates is good... If it is
>> experimental extension, or something that is only for certain cases,
>> then I think it can be separate standalone extension.
>>
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Sep 2016 01:58:44 +0100

On 04/09/16 22:58, Donald Eastlake wrote:
> lately the IESG has been refusing to

I don't believe that assertion is justified.

IESG members do ask about such stuff sure, but "refusing"
seems to me to not reflect history. Of course, I may be
wrong, in which case I'm sure it'd be possible to produce
counts of such events.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Sep 2016 08:45:49 -0500

FWIW,

> wrong, in which case I'm sure it'd be possible to produce

Depending on Donald's definition of "lately", of course ... but my
recollection is roughly what Stephen said, covering IESGs since May 2013.
ADs do ask "really?" from time to time, but don't push further if the
answer is "yes, really", and (beyond what Stephen said) it's not the same
ADs who ask "really?" each time - it does seem to be an honest question
from some AD that's satisfied with an honest answer.

Keeping in mind that of the 15 ADs on the IESG when I joined in 2013, only
5 are on the IESG today, of course, so what the IESG thinks can change over
a period of years ...

I can't speak to what individual ADs tell working groups before a doc drops
into IETF Last Call, of course, but that's a different question.

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Sep 2016 12:23:14 -0400

> what you have to comply with to make your statement of compliance

I understand all that.

> compliance with an RFC, not compliance with a protocol.

I was reacting to your statement:

   "If RFC X specifies protocol Z, the publication of another RFC
   might means that you were no longer compliant with the current
   protocol Z, but that is a different matter."

That is a useful way to address the issue *if* the protocol itself is 
versioned in a way that in a practical sense allows moving to a new 
version. (For a counter-example, SIP is versioned, but there are no 
provisions for backward compatibility between versions, so there will 
never be another version.)

> specified in RFCs through RFC Y but excluding RFC Z.

Yes, those who are in the know can carefully specify a profile of 
related RFCs. 3GPP is pretty thorough in doing that for SIP.

But typically when companies specify requirements they are much less 
thorough, and don't even understand the nuances of what they are requesting.

And product supplies typically specify standards compliance fairly 
generously, so they will meet the requirements of customer bid specs.

But, getting back to "UPDATES":

What is the point of having this metadata? Is it there for reviewers, or 
implementers, or who? How are they expected to use it?

OBSOLETES has a clear use for implementers. If you are reading the 
document YYY and it contains OBSOLETES XXX, and you currently implement 
XXX, then you should do your implementation as a replacement.

If you are reading XXX for the first time, with the intent of 
implementing it, and you see the metatdata OBSOLETED BY YYY, then you 
should instead be reading YYY. (Of course, you may not see OBSOLTED BY 
YYY if you are reading a static txt copy of XXX.)

If you are reading XXX and see UPDATED BY YYY, then you may or may not 
need to do anything. If YYY is a bug fix, then you probably need to read 
it and see if it matters to you. (Ideally, everybody who has implemented 
XXX ought to get an alert about the existence of this bug fix.)

If YYY is simply a backward compatible extension of XXX, then you might 
still want to know, but the need is much less compelling. Nothing bad is 
likely to be happen if you ignore YYY until somebody comes to you with a 
specific requirement for the functionality it provides.

Bottom line, the precise meaning of these metadata terms impacts 
document readers when deciding which documents it is important to read, 
and which might safely be ignored.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 5 Sep 2016 12:30:19 -0400

> always step in if they think things are too extreme either way.

That was exactly my point. Using OBSOLETES makes it pretty clear that 
future implementations should implement the new one rather than the old 
one, and old implementations should seriously be considering 
implementing the new one.

If we had REVISES, then would be an alternative to OBSOLETES in cases 
when it is not practical to issue a bis.

But UPDATES doesn't really serve the same purpose, because it so often 
is used to identify feature extensions.

	Thanks,
	Paul

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 5 Sep 2016 17:20:52 +0000

<with AD hat>
As a recent AD, I’ve seen discussion swing on what is an update among the different ADs, though it’s as Stephen noted, each WG does have a history. Hopefully, it’s not a “refusal” by the AD/IESG, and there is discussion involved to understand.

It’s difficult with any thread to discuss non-specifics. Here’s a very recent specific example where we did discuss/modify the “Update” (and the IESG was ok):
https://mailarchive.ietf.org/arch/msg/ietf/GEXdPkBbR8DLMq2ZeUePkFEcH0Y
Perhaps this was an easy one as Acee noted on his response. Others may even disagree with our decision. But most are not even this simple.

<all hats off>
The “what is an update question” has been asked over and over as noted by the former ADs on this thread. As Adrian says, maybe an IESG statement is long overdue, or maybe we do as we always have done, let it be discussed as it goes thru the document publication process.

My preference is ease for the implementer/operator referencing an RFC. If an RFC has 30 updates hanging on it, then one needs to check them all if applicable. Not very user friendly. If RFC YYY is an optional “whatever”, than does it need to say “update XXX”? It already has normative references to what one needs to know.

I’m not sure an IESG statement of a few sentences will be the ultimate “statement”. My preference would be an “advice” section on the WG Chairs wiki or a WG Chair could do on their own wiki (Lou started this one for TEAS):
https://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines
I see Paul has gone a step further now on his rationale in his latest email, saying “do we really need the metadata term “Updates”?” I think I could be convinced (with a beer) on that☺

Suggest why not have this as a topic for the WG Chairs lunch or have an informal (true) Bar BoF?

Deborah

From: WGChairs [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, September 05, 2016 9:46 AM
To: Stephen Farrell <[email-masked]>
Cc: Donald Eastlake <[email-masked]>; Working Group Chairs <[email-masked]>
Subject: Re: "Updates: RFC xxx" - what does it actually mean ?

FWIW,

On Sun, Sep 4, 2016 at 7:58 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Depending on Donald's definition of "lately", of course ... but my recollection is roughly what Stephen said, covering IESGs since May 2013. ADs do ask "really?" from time to time, but don't push further if the answer is "yes, really", and (beyond what Stephen said) it's not the same ADs who ask "really?" each time - it does seem to be an honest question from some AD that's satisfied with an honest answer.

Keeping in mind that of the 15 ADs on the IESG when I joined in 2013, only 5 are on the IESG today, of course, so what the IESG thinks can change over a period of years ...

I can't speak to what individual ADs tell working groups before a doc drops into IETF Last Call, of course, but that's a different question.

Thanks,

Spencer

S.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 6 Sep 2016 14:51:42 +0200

Dear all,

Ben's, Joel's and Keith's proposal is the most pragmatic solution on 
this email thread: the updatING RFC should explain the nature of the 
update, preferably in a place one can find quickly.

When I review a bis document, the first thing I look at (after reviewing 
the abstract) is the section generally titled "Summary of Changes from 
<OLD-RFC>".
I like it when this section is early in the document, as opposed to 
hidden in an appendix.
For UPDATES, we should follow the same convention, i.e. a new early 
section titled "Reasons for updating <UPDATED-RFC>".

This solution offers flexibility on the UPDATES meaning (which we need: 
I'm not keen on having a new set of keywords at this point), while being 
specific in the updatING RFC.

Regards, Benoit

> .

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Sep 2016 14:31:40 -0500

On Tue, Sep 6, 2016 at 7:51 AM, Benoit Claise <[email-masked]> wrote:

> Dear all,
>
> Ben's, Joel's and Keith's proposal is the most pragmatic solution on this
> email thread: the updatING RFC should explain the nature of the update,
> preferably in a place one can find quickly.
>
> I like it when this section is early in the document, as opposed to hidden
> in an appendix.
> My original comment was slightly complimentary to this - that the UPDATE
>> has to be very clear on how it modifies the original document, i.e. which
>> elements using any RFC 2119 language are modified or rescinded.
>>
>> Keith
>>
This seems about right to me - no new keywords, but being clear on what is
being updated and why is extremely helpful.

If a community-minded IETF participant put together a draft proposal for
the way we handle UPDATES going forward, along these lines, I'd be happy to
consider AD sponsoring it ... and it should be short ... :-)

Thanks,

Spencer

---

From: Erik Wilde <[email-masked]>
Date: Tue, 6 Sep 2016 17:22:59 -0700

hello all.

On 2016-09-06 12:31, Spencer Dawkins at IETF wrote:
> On Tue, Sep 6, 2016 at 7:51 AM, Benoit Claise <[email-masked]
> This seems about right to me - no new keywords, but being clear on what
> is being updated and why is extremely helpful.
> the way we handle UPDATES going forward, along these lines, I'd be happy
> to consider AD sponsoring it ... and it should be short ... :-)

https://github.com/dret/I-D/blob/master/updating-rfcs/draft-wilde-updating-rfcs-00.txt 
has not yet been submitted, but would be one possible first step. it 
certainly is short. it simply proposes to clearly document the reason 
for the update in individual section(s), and does so itself because it 
updates RFC 7322... ;-)

any feedback is very welcome, either by email, or via github (which 
often helps to organize discussions a little better). i am still using 
the "author XML and generate TXT/HTML" method, so for PRs, please use 
the XML as your starting point. thanks!

cheers,

dret.

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

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Wed, 7 Sep 2016 11:53:25 +0000

Looks like a very reasonable doc – short and sweet.

	Tony Hansen

On 9/6/16, 8:22 PM, "WGChairs on behalf of Erik Wilde" <[email-masked] on behalf of [email-masked]> wrote:

    hello all.

    
    
    cheers,
    
    dret.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 7 Sep 2016 14:22:38 +0200

Good job Erik,

Two pieces of feedback.
1. Probably obvious to us, but I would make it clear that the this new 
section complements and does not replace the UPDATES metadata in the header.
2.

    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. However, there may be reasons

    to establish the relationship between the RFCs so the implementers

    are aware of it and that new implementations of the updated RFC are

    more likely to also implement the extension in the updating RFC. In

    such a case, the section should be clear about the fact that the

    update is optional, and may make a case for new implementations to

    support the extension as well.

It seems that you come from a specification view only, while UPDATES 
might also be applicable to BCP
So not only about:
         The second motivation is that the updating RFC is a backwards 
compatible (protocol) extension
You might introduce the notion of "updated practice"

A similar draft for bis document and the "Summary of Changes from 
<OLD-RFC>" section ... would make me very happy. :-)

Regards, Benoit

---

From: Erik Wilde <[email-masked]>
Date: Wed, 7 Sep 2016 09:39:13 -0700

hello benoit.

thanks for the feedback!

> section complements and does not replace the UPDATES metadata in the header.

https://github.com/dret/I-D/commit/b773da8f424b634b32b952d3c66d23943b47c33f

> You might introduce the notion of "updated practice"

https://github.com/dret/I-D/commit/f46b2bb23b3337db1e568bfd29c2a9bfe52fa5cc

> <OLD-RFC>" section ... would make me very happy. :-)

any preference on whether that should be separate or could be part of 
this one? it is still unsubmitted and any PRs will be happily accepted!

thanks and cheers,

dret.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Sep 2016 11:58:07 -0500

Hi, Erik,

On Wed, Sep 7, 2016 at 11:39 AM, Erik Wilde <[email-masked]> wrote:

> any preference on whether that should be separate or could be part of this
> one? it is still unsubmitted and any PRs will be happily accepted!
>
> thanks and cheers,
>
>
> dret.
>
> --

I apologize for the process wonkery, but if I don't ask now, someone else
will ask later ...

Your draft targets Proposed Standard, and Updates 7322.

7322 applies to all RFCs, not just IETF-stream RFCs. If your intention is
that all streams would be enforcing this update, that would be good to
decide explicitly, and should be in the IAB stream (since IAB has oversight
over the RFC series as a one of their chartered responsibilities). If your
intention is only to have the IESG enforce this in IETF-stream drafts, I
wouldn't propose this as an Update to 7322.

7322 is Informational (not surprising for an IAB-stream document, because
the IAB doesn't do standards-track documents or BCPs). If this draft goes
in the IAB stream, it would also be Informational. If this draft goes into
the IETF stream, I'd suggest targeting BCP, which would have the same
gravitas as a Proposed Standard.

IIUC, your draft makes this practice mandatory. One alternative is to make
it advisory (https://tools.ietf.org/tools/idnits/ would not treat the
absence of this section as an error). I have opinions about this, but
they're only my opinions. It would be good to make that decision explicitly.

I hope this is helpful.

Spencer, as a potential AD for an AD-sponsored version in the IETF stream,
if that's what you shoot for

---

From: Erik Wilde <[email-masked]>
Date: Wed, 7 Sep 2016 10:09:27 -0700

hello spencer.

On 2016-09-07 09:58, Spencer Dawkins at IETF wrote:
> I apologize for the process wonkery, but if I don't ask now, someone
> else will ask later ...

great that you're bringing this up now, and thanks for that! to be 
honest, my draft currently targets whatever the draft targeted that i 
used as my copy/paste starting point... and i consciously haven't 
submitted it yet because i was sure that there were some issues around 
these questions.

i'll happily change the draft metadata to whatever people think makes 
most sense, so that even version -00 hopefully already is targeting the 
right track and status.

without understanding the formal process part of it, it seemed to me 
that it would be useful to see this as an update to RFC 7322, in the 
loosely defined way that if you are reading these best practices, then 
reading the new document might be helpful as well. there might be 
different/better ways to do this, and i am more than happy to adjust.

thanks and cheers,

dret.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Sep 2016 12:20:11 -0500

Hi, Erik,

On Wed, Sep 7, 2016 at 12:09 PM, Erik Wilde <[email-masked]> wrote:

> great that you're bringing this up now, and thanks for that! to be honest,
> my draft currently targets whatever the draft targeted that i used as my
> copy/paste starting point... and i consciously haven't submitted it yet
> because i was sure that there were some issues around these questions.

Mine usually do, too. I know how that works ;-) ...

My thought about asking these questions now is that if you want to Update
7322, you should probably be talking to Robert Sparks, who is the IAB lead
for https://www.iab.org/activities/programs/rfc-editor-program/, and asking
him how wrong Spencer is, this time.

Robert was my AD when I was a working group chair, so he probably already
has a mail folder for people who are asking that question :D

Spencer

> i'll happily change the draft metadata to whatever people think makes most
> sense, so that even version -00 hopefully already is targeting the right
> track and status.
>
> without understanding the formal process part of it, it seemed to me that
> it would be useful to see this as an update to RFC 7322, in the loosely
> defined way that if you are reading these best practices, then reading the
> new document might be helpful as well. there might be different/better ways
> to do this, and i am more than happy to adjust.
>
>
> thanks and cheers,
>
> dret.
>
> --

---

From: Erik Wilde <[email-masked]>
Date: Sat, 10 Sep 2016 10:44:38 -0700

hello.

thanks for the feedback, spencer and joel. what's the best way to proceed?

On 2016-09-07 10:20, Spencer Dawkins at IETF wrote:
> My thought about asking these questions now is that if you want to
> Update 7322, you should probably be talking to Robert Sparks, who is the
> IAB lead
> for https://www.iab.org/activities/programs/rfc-editor-program/, and
> asking him how wrong Spencer is, this time.

i don't really know if i want to update that RFC. if that results in all 
kinds of procedural unpleasantness, then maybe not?

apart from procedure, the two rather simple goals are:

- add a bit of clarification to the question of how to write RFCs that 
use the formal concept of "Updates".

- make it easy for RFC authors to discover that additional guidance so 
that they can take it into account as part of the writing process.

if that latter part is easier achieved by relying on google instead of a 
formal "Updates" relationship, then i am fine with that. i think i just 
liked the "eat your own dogfood" approach of demonstrating the proposed 
approach in the document proposing it.

the draft as it is now is still unpublished. should i submit it so that 
we have a better/public starting point to see where things are going?

thanks and cheers,

dret.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Sep 2016 14:21:57 -0400

Assuming we can get a BCP of some sort approved byt the IETF/IESG, and 
maybe with IAB signon, we can ask the RFC Editor to point to it from the 
web-page portion of the style guide.  We can also put a pointer on the 
wg-chairs web page, and possibly some other places.

That is my personal take, anyway.

Yours,
Joel

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Sep 2016 13:55:30 -0500

Hi, Erik,

On Sat, Sep 10, 2016 at 1:21 PM, Joel M. Halpern <[email-masked]>
wrote:

> Assuming we can get a BCP of some sort approved by the IETF/IESG,

This is the part of the process I can help with.

Given that the majority of RFCs are now published in the IETF stream, and
without actually looking, my best guess is that the vast majority of RFCs
that update other RFCs are in that stream, maybe that's all that's needed.

I'm definitely happy to talk to the other stream controllers and ask
whether they are interested in solving the problem for their own streams,
but that will be a more productive conversation if there's a draft for the
other stream controllers to look at.

So, I'd say, targeting a BCP in the IETF stream, and not asking the IAB to
approve an update to RFC 7322 (which is necessary if this procedure applies
to most/all streams), is the way to start out.

I am interested in hearing thoughts about just how mandatory this needs to
be, but that question can also be asked when there's a draft for the
community to look at.

That's my take. I hope it's helpful.

Spencer

> and maybe with IAB signon, we can ask the RFC Editor to point to it from
> the web-page portion of the style guide.  We can also put a pointer on the

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 13 Sep 2016 13:33:36 -0700

On 8/31/16 5:36 AM, Cullen Jennings wrote:
> Adding IESG and RFC Ed to see if they have any input on what RFC X "updates"  RFC Y means 

Hello all,

It sounds like this thread has moved on to the actual creation of an I-D
to help clarify what 'updates' and 'obsoletes' actually means. I am
definitely happy to hear that; I think having this clarified will be of
benefit to the people who implement the technology described in RFCs.

I have one particular point of concern: while I think it is very useful
to have these terms clarified, I don't consider the definitions a style
issue, any more than I consider the guidance on how to write the
security, internationalization, or IANA considerations sections of a
draft. If and when the guidance for updates/obsoletes is clarified the
RFC Style Guide will definitely point to them, but it will be in a
similar fashion to the considerations guidance. I wouldn't say that the
I-D (and subsequent RFC) that the community is putting together should
say it updates RFC 7322. What the style guide has now (section 4.1.4)
just provides some context to why those terms may be used in RFC metadata.

Examples from RFC 7322:

4.8.5.  Security Considerations Section

   All RFCs must contain a section that discusses the security
   considerations relevant to the specification; see "Guidelines for
   Writing RFC Text on Security Considerations" [BCP72] for more
   information.

   Note that additional boilerplate material for RFCs containing MIB and
   YANG modules also exists.  See "Security Guidelines for IETF MIB
   Modules" [MIB-SEC] and "yang module security considerations"
   [YANG-SEC] for details.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 14 Sep 2016 19:49:02 -0400

hello spencer.

On 2016-09-12 14:55, Spencer Dawkins at IETF wrote:
> I am interested in hearing thoughts about just how mandatory this needs
> to be, but that question can also be asked when there's a draft for the
> community to look at.

my probably naive thought was that if the style guide said that authors 
should consider this "Updating RFCs" document, and the document said 
something like a "SHOULD contain such a section", then it would set up 
things in a way that authors can figure out that this is something they 
should do, unless they have good reasons not to do it.

but i am sure there are many ways in which an end result like this can 
be achieved, and i'm more than happy to adjust to what most people think 
is the most reasonable and effective path forward.

thanks a cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 14 Sep 2016 19:49:17 -0400

hello all.

> benefit to the people who implement the technology described in RFCs.

https://tools.ietf.org/html/draft-wilde-updating-rfcs-00 is a first 
version so that there is something to discuss. the source lives at 
https://github.com/dret/I-D/tree/master/updating-rfcs and i am more than 
happy to discuss via issues/PRs, but at least for the bigger picture 
email lists probably make more sense.

> just provides some context to why those terms may be used in RFC metadata.

it seems that so far everybody has been in favor of not formally 
updating RFC 7322, so i have removed that particular bit of metadata 
from the draft before submitting it. however, it still has the section 
in there which talks about updating RFC 7322, so that may be confusing 
now and probably should be approached differently (it was my attempt at 
eating my own RFC food).

thanks a lot for all the feedback so far. keep it coming!

dret.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Sep 2016 04:05:33 +0000

There have been a number of mentions on this thread of "extends". If the original RFC has been defined with appropriate extension and forward compatibility mechanisms in the first place (and they of course all are!), then I would not expect to see the UPDATES tag used.

Keith

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: 06 September 2016 13:52
To: Drage, Keith (Nokia - GB); Joel M. Halpern; Ben Campbell
Cc: [email-masked]
Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

Dear all,

Ben's, Joel's and Keith's proposal is the most pragmatic solution on this email thread: the updatING RFC should explain the nature of the update, preferably in a place one can find quickly.

When I review a bis document, the first thing I look at (after reviewing the abstract) is the section generally titled "Summary of Changes from <OLD-RFC>".
I like it when this section is early in the document, as opposed to hidden in an appendix.
For UPDATES, we should follow the same convention, i.e. a new early section titled "Reasons for updating <UPDATED-RFC>".

This solution offers flexibility on the UPDATES meaning (which we need: 
I'm not keen on having a new set of keywords at this point), while being specific in the updatING RFC.

Regards, Benoit

>> should explain the nature of the update. Preferably in a place one 
>> can find quickly, such as the abstract. E.g...
>>
>>> currently consistent.  We use updates for two different cases, as 
>>> far as I can
>>> tell:
>>>
>>> reception.  The new document (RFC B) uses field X.  Obviously, if 
>>> you are implementing RFC B, you need to be told that the existing 
>>> text in this regard in RFC A is no longer correct.
>>>
>>> A reader presented with a tag saying "updated by" does not know 
>>> which of these two cases apply.
>>> trying to create another tag to distinguish them is likely to 
>>> further confuse the reader rather than helping.
>>>
>>> Yours,
>>> Joel
>>>
>>>> write down a definition, I think it should be along the lines of 
>>>> "If you see an "Updated by" label on an RFC, you need to also read 
>>>> (or be aware of) the updating document. The updating document 
>>>> should describe the nature of the update, preferably in the abstract."
>>>>
>>>> Ben.
>>>>
>>>>> If there is active disagreement on what UPDATES means, but there 
>>>>> is still desire to have metadata about this, then I propose that 
>>>>> we define *new* terms that *can* be agreed upon.
>>>>>
>>>>>      Thanks,
>>>>>      Paul
>>>>>
>>>>>>> I share your concern and agree there is a need to get the 
>>>>>>> meaning of these terms clearly defined
>>>>>> (When I started on the IESG that also irritated me and I tried 
>>>>>> but failed to write down a self-consistent and useful description 
>>>>>> of them all;-)
>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2016 12:42:11 -0400

> There have been a number of mentions on this thread of "extends". If the original RFC has been defined with appropriate extension and forward compatibility mechanisms in the first place (and they o…

I agree. But that leaves open what are *appropriate* extension and 
forward compatibility mechanisms, and how to use them.

In many of the cases I'm aware of where this comes up, the base document 
has a syntax defined in ABNF, and somewhere in there is a rule similar to:

	reserved-word = "foo" / "bar" / extension-word
         extension-word = token
	(other rules using reserved-word in a protocol)

Then there will be sections in the document specifying the specific 
semantics for reserved words "foo" and "bar", and also what to do for 
something matching extension-word but not otherwise matching a known 
alternative.

There may or may not also be an IANA registry where reserved-words are 
registered.

When there is no such registry, and sometimes even when there is, it has 
become common for a document defining an extension to the above to 
include something like:

	reserved-word = <as defined in RFCnnnn>
         reserved-word =/ "baz"

IMO, if the new document uses the =/ form to add a new alternative to a 
rule defined in RFCnnnn then this document ought to be considered to 
modify the ANBF, and so should be marked as Updates RFCnnnn.

A different way for RFCnnnn to accomplish the same thing is:

	reserved-word = token

with semantic rules specifying that values are valid is present in 
specified IANA registry, and that the registry will, for each valid 
value, identify a document that specifies how the value is to be 
interpreted.

The same document can then define and register an initial set of values.

Done *this* way then I agree that documents defining new values need not 
specify Updates RFCnnnn.

This is why I think the question of what Updates means is important.

	Thanks,
	Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Sep 2016 13:01:46 -0400

The simplest example I can see for an extension which updates is the 
case where

The base document says field X is reserved, must be set to 0 on 
transmission, and must be ignored on reception.

The addition redefines field X 9or some part of X) giving it meaning on 
transmission and reception.

It is important in that case to call out that fact that this is a change 
to the underlying specification.  Yes, it is a change that only applies 
if you implement the update.  But it is still a change to what is said 
in the base.
So marking the new document as updating the old one seems to me to be 
very useful and important.  Yes, we could bury that fact in the text. 
We can bury everything in the text.

THe secondary incompatible case is where we find out there is a small 
problem in the base spec.  Most of it is fine, but one part just turns 
out to be wrong.  That is not an errata, as the spec refelcts what the 
WG agreed.  So we can either republish the entire thing (a pain), or 
publish an update which changes the base.  This is a much less common 
case, but is important when it occurs.

Trying to create yet more metadata tags seems like asking for trouble.
WHich is why I favor using the tags we have, and making sure the 
documents which update are clear about the kind of change they are 
making and who it applies to.  I don't much care if this is in the 
abstract or the introduction.  But it needs to be early.  I do not think 
the early and simple explanation needs to go into all the details 
(changes paragraph 2 of section 3 and paragraph 4 of section 5...)

Yours,
Joel

On 9/21/16 12:42 PM, Paul Kyzivat wrote:
>> There have been a number of mentions on this thread of "extends". If
>> the original RFC has been defined with appropriate extension and
>> forward compatibility mechanisms in the first place (and they of
>> course all are!), then I would not expect to see the UPDATES tag used.
>
>> When I review a bis document, the first thing I look at (after
>> reviewing the abstract) is the section generally titled "Summary of
>> Changes from <OLD-RFC>".
>>> My original comment was slightly complimentary to this - that the
>>> UPDATE has to be very clear on how it modifies the original document,
>>> i.e. which elements using any RFC 2119 language are modified or
>>> rescinded.
>>>
>>> Keith
>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Sep 2016 17:16:41 +0000

I agree with Joel - we don’t need more granular/complex meta data. Just
guidance on usage of the “updates” tag.
Thanks,
Acee

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2016 15:48:37 -0400

> guidance on usage of the “updates” tag.

After all this discussion I am inclined to agree. But that doesn't 
resolve the problem that reasonable people disagree the cases where 
Updates should be used and those where it does not. So the guidance is 
very important.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 23 Sep 2016 00:47:04 +0000

I'd disagree with you on this example. To me this is one of the simplest extension mechanisms. While additional words normally give the keyword "Reserved" more semantic ("Reserved for future use"), this is usually taken as valid for extension, and as you have indicated, its use will not impact interoperability with older implementations (except where the new functionality is required). 

If the codepoint had been labelled "spare" and defined as always set to zero, then the argument might have been different.

Further, there should be nothing special about extension mechanisms. Good protocols explicitly define them in version 1.

Keith

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 21 September 2016 18:02
To: Paul Kyzivat; [email-masked]
Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

The simplest example I can see for an extension which updates is the case where

The base document says field X is reserved, must be set to 0 on transmission, and must be ignored on reception.

The addition redefines field X 9or some part of X) giving it meaning on transmission and reception.

It is important in that case to call out that fact that this is a change to the underlying specification.  Yes, it is a change that only applies if you implement the update.  But it is still a change to what is said in the base.
So marking the new document as updating the old one seems to me to be very useful and important.  Yes, we could bury that fact in the text. 
We can bury everything in the text.

THe secondary incompatible case is where we find out there is a small problem in the base spec.  Most of it is fine, but one part just turns out to be wrong.  That is not an errata, as the spec refelcts what the WG agreed.  So we can either republish the entire thing (a pain), or publish an update which changes the base.  This is a much less common case, but is important when it occurs.

Trying to create yet more metadata tags seems like asking for trouble.
WHich is why I favor using the tags we have, and making sure the documents which update are clear about the kind of change they are making and who it applies to.  I don't much care if this is in the abstract or the introduction.  But it needs to be early.  I do not think the early and simple explanation needs to go into all the details (changes paragraph 2 of section 3 and paragraph 4 of section 5...)

Yours,
Joel

On 9/21/16 12:42 PM, Paul Kyzivat wrote:
> In many of the cases I'm aware of where this comes up, the base 
> document has a syntax defined in ABNF, and somewhere in there is a rule similar to:
>
> When there is no such registry, and sometimes even when there is, it 
> has become common for a document defining an extension to the above to 
> include something like:
>
> IMO, if the new document uses the =/ form to add a new alternative to 
> a rule defined in RFCnnnn then this document ought to be considered to 
> Done *this* way then I agree that documents defining new values need 
> not specify Updates RFCnnnn.
>
>>> UPDATE has to be very clear on how it modifies the original 
>>> document, i.e. which elements using any RFC 2119 language are 
>>> modified or rescinded.
>>>
>>> Keith
>>>
>>>> I agree with both cases. That's why I suggested that the updatING 
>>>> RFC should explain the nature of the update. Preferably in a place 
>>>> one can find quickly, such as the abstract. E.g...
>>>>
>>>>    "This document updates RFC XXXX to better support turnip 
>>>> twaddling using the FOO protocol."  --which one could ignore if you 
>>>> didn't care bout that use case, vs...
>>>>
>>>>    "The FOO protocol as described in RFC XXXX will melt the 
>>>> Internet and send all your private data to the mob. This document 
>>>> updates that specification to fix critical bugs." -- which one 
>>>> probably shouldn't ignore.
>>>>
>>>>> not a good idea.  While we sometimes do this by obsoleting the 
>>>>> base document, when the change is small we often do not want to do that.
>>>>> Unfortunately, as far as I can tell, both are reasonable uses.  
>>>>> And trying to create another tag to distinguish them is likely to 
>>>>>> "If you see an "Updated by" label on an RFC, you need to also 
>>>>>> read (or be aware of) the updating document. The updating 
>>>>>> document should describe the nature of the update, preferably in 
>>>>>> the abstract."
>>>>>>
>>>>>> Ben.
>>>>>>
>>>>>>> If we cannot agree on a definition for UPDATES, then ISTM we 
>>>>>>> would be better off without having this as a formal piece of metadata.
>>>>>>>
>>>>>>>> but failed to write down a self-consistent and useful 
>>>>>>>> description of them all;-)
>>>>>>>>
>>>>>>>> So is it really true that there is "a need" here? Or is it 
>>>>>>>> maybe more that we pretty much all much prefer tidy situations?
>>>>>>>>
>>>>>>>> I also think it's quite unlikely that we spend productive 
>>>>>>>> cycles that arrive at a rough consensus that works.
>>>>>>>>
>>>>>>>> consensus of the IETF, I can't see it happening tbh. But if 
>>>>>>>> some folks want to give it a shot, you have my best wishes.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> S.
>>>>>>>>
>>>>>>
>>> .
>>>
>>
>>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Sep 2016 09:25:33 -0400

Keith,

> Further, there should be nothing special about extension mechanisms. Good protocols explicitly define them in version 1.

ISTM that you are arguing that Updates only applies in cases where there 
is a *revision* as contrasted with an *extension*. I earlier suggested 
that we distinguish these cases, but I was voted down in favor of having 
Updates cover both cases.

	Thanks,
	Paul

(Keith and I have a longstanding disagreement on this point)

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Sep 2016 13:40:34 +0000

Hi,

>>I'd disagree with you on this example. To me this is one of the simplest
>>extension mechanisms. While additional words normally give the keyword
>>"Reserved" more semantic ("Reserved for future use"), this is usually
>>taken as valid for extension, and as you have indicated, its use will
>>not impact interoperability with older implementations (except where the
>>new functionality is required).
>>
>> If the codepoint had been labelled "spare" and defined as always set to
>>zero, then the argument might have been different.
>>
>> Further, there should be nothing special about extension mechanisms.
>>Good protocols explicitly define them in version 1.
>

In my opinion, it depends on what we mean by ³extension².

For example, when we define a new SIP method, we do extend the SIP
protocol (IMO). But, we don¹t update the core specification (RFC 3261).

However, if a protocol does NOT define a mechanism for extending it, then
I guess any extension would have to be an update (or, in some cases, a
bis) of the core specification.

Regards,

Christer

>> It is important in that case to call out that fact that this is a
>>change to the underlying specification.  Yes, it is a change that only
>>applies if you implement the update.  But it is still a change to what
>>is said in the base.
>>>>> From: WGChairs [mailto:[email-masked]] On Behalf Of Joel
>>>>>M.
>>>>> Halpern