Subject: "Updates: RFC xxx" - what does it actually mean ?

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Aug 2016 15:22:24 -0400

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 ?

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: Dave Thaler <[email-masked]>
Date: Mon, 29 Aug 2016 19:27:44 +0000

1) No.
2) Not applicable.
3) I don't know. :)

> -----Original Message-----
> From: WGChairs [mailto:[email-masked]] On Behalf Of Flemming
> Andreasen
> Sent: Monday, August 29, 2016 12:22 PM
> To: [email-masked]
> Subject: "Updates: RFC xxx" - what does it actually mean ?
> 
> Greetings
> 
> 1) In order for me to be compliant with RFC X, MUST I now also be compliant
> with RFC Y ?
> 
> 2) If yes, what if RFC Y introduced a non-backwards compatible change to RFC
> X ?
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 29 Aug 2016 14:34:46 -0500

(no hats; this is all "in my opinion")

> 1) In order for me to be compliant with RFC X, MUST I now also be 

It depends on the update, e.g. whether the behavior in Y is optional or 
required. It's possible for Y to make a "required" update. It may or may 
not be a good idea.

We don't have an enforcement arm, so we can't go back and force all 
implementations of X to become compliant with Y. Whether that makes 
existing implementations of X become non-compliant is an exercise in 
angel-counting.

>
> 2) If yes, what if RFC Y introduced a non-backwards compatible change 
> to RFC X ?

Again, it depends. It's usually not a good idea, but there may be 
reasons to do it. If these are standard track RFCs, then doing so would 
require IETF consensus, just like any other standards track RFCs.

> 3) Is the answer to 1) documented somewhere ?

I don't think so.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Aug 2016 21:08:21 +0100

As with Ben, with no official or other hats:

>> 3) Is the answer to 1) documented somewhere ?

One of the reasons for that may be that the semantics
of "Updates:" is really protocol/WG dependent. That's
probably not a great situation, but is, I think, the
status quo.

I think I've seen updates with each of the following
semantics (or at least arguments for all of these
from sensible/knowledgeable folks):

a) this (Y) is an optional extension to X (where Y
updates X)

c) Y is useful to know about for readers of X

c) new implementations of X really really should do Y

d) implementations of X really really should do Y even
if they're not new (but we know some X implementations
won't/can't be updated so we're not obsoleting X)

There may be more possibilities.

I'd say the best thing to do is to follow existing
practice for whatever is the most relevant protocol X.
If existing practice isn't clear, or hasn't yet been
established, then pick your fav. semantic and try make
that clear in the text of Y.

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Aug 2016 16:20:33 -0400

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.

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

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Aug 2016 16:30:14 -0600

> 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 ?
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Aug 2016 12:02:46 +0300

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

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.

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.
-- 
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 11:04:22 +0000

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:

>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.
>
>>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 30 Aug 2016 09:44:35 -0400

HI,

On Mon, Aug 29, 2016 at 6:30 PM, Cullen Jennings <[email-masked]> wrote:

> 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.

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Aug 2016 10:14:35 -0400

On 8/30/16 9:44 AM, Donald Eastlake wrote:

> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Aug 2016 10:16:27 -0400

> that everybody needs to fix it, obsolete the old rfc, and make new

The trouble with that is it means the updating RFC must be a full bis, 
rather than simply specifying the changes.

	Thanks,
	Paul

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Aug 2016 15:45:36 +0100

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".

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

> 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 ?
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Aug 2016 11:07:14 -0700

So if we have an RFC Y that adds a new feature to RFC X but does not fix a bug in it or anything, what does it mean to say “Y updates X”? what does it mean to not say this? When do we use update and when do we not? 

> On Aug 30, 2016, at 6:44 AM, Donald Eastlake <[email-masked]> wrote:
> 
> HI,
> 
> On Mon, Aug 29, 2016 at 6:30 PM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Aug 29, 2016, at 1:22 PM, Flemming Andreasen <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Greetings
> >
> 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.
> 
> Thanks,
> Donald
>  [email-masked] <mailto:[email-masked]>
>

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 30 Aug 2016 14:19:52 -0400

This is is a job for SuperRFCEditor!  Quick, somebody shine the signal in the sky!

> I think that means we ought to factor UPDATES into EXTENDS and REVISES.

Are “EXTENDS” and “REVISES” terms that can appear in published RFCs?

RFC7322 defines two document header terms: Updates and Obsoletes.

The now-obsoleted RFC 2223 used to define those two terms.  RFC7322 does not, which is conspicuous by its absence.  I don’t know why it is no longer there.  Perhaps there is no longer a consensus of what those two terms mean?

The definition in RFC2223 used to be:

12.  Relation to other RFCs

   Sometimes an RFC adds information on a topic discussed in a previous
   RFC or completely replaces an earlier RFC.  There are two terms used
   for these cases respectively, Updates and Obsoletes.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

By that definition, I’d say there’s no such thing as an RFC that Updates another RFC and has a non-backward-compatible change.

But then there was some work on a bis of RFC2223 (up to 2004), which in the last never published version changed this to:

.11 Relation to other RFCs

      Sometimes an RFC adds information on a topic discussed in a
      previous RFC or completely replaces an earlier RFC.  Two terms are
      used for these cases: Updates and Obsoletes, respectively.

         Updates

            Specifies an earlier document whose contents are modified or
            augmented by the new document.  The new document cannot be
            used alone, it can only be used in conjunction with the
            earlier document.

         Obsoletes

            Specifies an earlier document that is replaced by the new
            document.  The new document can be used alone as a
            replacement for the obsoleted document.  The new document
            may contain revised information or all of the same
            information plus some new information, however extensive or
            brief that new information may be.

That seems to imply that Updates can be used when an RFC modifies, not just adds new info, to an earlier document, so I suppose the udpate could be non-backward-compatible.

Personally, myself, I think I’d have a hard time supporting a non-backward-compatible change getting published as an Update.  I’d think it would be better to say “Obsoletes”.  IMVHO, interoperability between Obsoleted and Obsoleting implementations would not be expected, but non-interoperability between Updated and Updating would not be OK.  And IMVHO, a non-backward-compatible change ought to be a version number change.  YMMV.

Nifty-keen that we are publishing documents when we don’t even have a clear idea of the terms of publication we use.

—Sandy

> On Aug 29, 2016, at 4:20 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> 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.
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Aug 2016 20:37:12 +0200

Of course, I don't have a definitive answer.

The recently published RFC 7959 was made to "update" RFC 7252, because
it is really useful for people who read RFC 7252 to also read RFC 7959.
Of course, you can implement RFC 7252 without reading RFC 7959, but then
your implementation is probably missing a piece of functionality that
your application may need.  (In this case, we made sure that reading the
abstract of RFC 7959 is helpful in finding out whether that is the case.)

There are about 742 RFCs that are marked "updates X" (~ 9.5 %), 712
"updated by".  Of the last 1000 published (about 40 months worth), about
161 (16.1 %, obviously) are marked "updates X".  We seem to increasingly
like publishing RFCs that update RFCs.

Grüße, Carsten

*) Amazingly, 20 are already marked "updated by", the most recent one
from September 2015.

Cullen Jennings wrote:
> 
> So if we have an RFC Y that adds a new feature to RFC X but does not fix
> a bug in it or anything, what does it mean to say “Y updates X”? what
> does it mean to not say this? When do we use update and when do we not? 
> 
> 
>> On Aug 30, 2016, at 6:44 AM, Donald Eastlake <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> HI,
>>
>>     > On Aug 29, 2016, at 1:22 PM, Flemming Andreasen
>>     <[email-masked] <mailto:[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.
>>     >
>>     "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.
>>
>>
>> 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.
>>
>> Thanks,
>> Donald

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 30 Aug 2016 18:55:21 +0000

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.

Regards,

Christer

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

>continue doing what was in 2026 and disregard 5378. I realize that 
>might be slightly different than the case at hand.
>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 19:06:05 +0000

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 ?

1)	No.
2)	Not applicable.

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,

Regards,

Christer

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 30 Aug 2016 19:53:31 +0000

The problem I see with your question is that I feel that the wrong question was asked.

If the code you write is compliant with RFC X, you are compliant with RFC X no matter what RFC Y says. End of story, full stop.

However, as a developer, I implement protocols, which are embodied in various RFCs. When I implement a protocol ABCD, I will develop it to some level of the RFCs. If you are implementing the protocol ABCD being espoused by RFC X, you certainly ought to pay attention to RFC Y if Y exists at the time you are implementing ABCD, because both X and Y form part of the protocol. When a new RFC Z comes out that updates RFC X, my code may or may not need to be updated – a lot depends on the type of change in RFC Z and whether the people paying for the protocol support want the code kept up-to-date with the latest version of the protocol.

	Tony Hansen

On 8/29/16, 3:22 PM, "WGChairs on behalf of Flemming Andreasen" <[email-masked] on behalf of [email-masked]> wrote:

    Greetings

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 30 Aug 2016 16:57:25 -0400

Thanks - at least this gives us something to look at as a starting point.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 30 Aug 2016 17:01:06 -0400

I share your concern and agree there is a need to get the meaning of 
these terms clearly defined (which is not to say I necessarily agree 
with your definitions below). Should that come from the IESG or the RFC 
Editor ?

Thanks

-- Flemming

On 8/30/16 10:45 AM, Adrian Farrel wrote:
> .

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 30 Aug 2016 14:16:01 -0700

+1

At 12:53 8/30/2016, HANSEN, TONY L wrote:

>If the code you write is compliant with RFC X, you are compliant
>with RFC X no matter what RFC Y says. End of story, full stop.
>
>However, as a developer, I implement protocols, which are embodied
>in various RFCs. When I implement a protocol ABCD, I will develop
>it to some level of the RFCs. If you are implementing the protocol
>ABCD being espoused by RFC X, you certainly ought to pay attention
>to RFC Y if Y exists at the time you are implementing ABCD,
>because both X and Y form part of the protocol. When a new RFC Z
>comes out that updates RFC X, my code may or may not need to be
>updated  a lot depends on the type of change in RFC Z and whether
>the people paying for the protocol support want the code kept
>up-to-date with the latest version of the protocol.
>        Tony Hansen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Aug 2016 22:44:07 +0100

Hiya,

On 30/08/16 22:01, Flemming Andreasen wrote:
> 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: Flemming Andreasen <[email-masked]>
Date: Tue, 30 Aug 2016 18:11:58 -0400

It would certainly make our lives easier. I asked the question 
originally because I have a situation in my WG where an individual is 
concerned with progressing a document that "Updates" another document. 
I'm not sure how to resolve the (opposing) views if I can't provide a 
consistent explanation let alone point to a definition somewhere that 
can clarify the meaning to the parties involved, as well as people 
referring to these RFCs subsequently.

Thanks

-- Flemming

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Aug 2016 23:25:09 +0100

Hiya,

On 30/08/16 23:11, Flemming Andreasen wrote:
> It would certainly make our lives easier.

Understood.

> I asked the question

Yes, that kind of situation is a pain.

I'd suggest two options:

- Follow Adrian's advice and say that this is something that
is just a moveable feast so it's best to not worry about it
until it gets to the IESG who'll land on one position or the
other. If some author or WG participant cares deeply about
this, then let them have their way if you can at all, in the
knowledge that things may change when the draft gets to the
IESG.

- Or, try follow my earlier suggestion of finding the best
precedent you can and then point at that and say that that's
what's been done for this WG/protocol previously and so is
good enough.

Maybe others will have better ideas though.

You could also point folks who care about this at this
thread [1] - even though this isn't an open-subscribe list
the archive is public. If a specific list for discussion of
the topic were desired, then I'd suggest pointing folks
(who're not WG chairs) at the rfc-interest list perhaps. [2]

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/wgchairs/current/msg14618.html
[2] https://www.rfc-editor.org/pipermail/rfc-interest/

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 30 Aug 2016 18:52:53 -0400

Stephen wrote:
...
> Maybe others will have better ideas though.

Not necessarily better, but another idea: Flag-day for "Updates:"

 - Prepare a draft with the definitions that folks can live with
*going forward* (recognizing that process will be iterative), and
explain that in the recent past, these terms did not have approved
definitions, but from approval forward these are the definitions
IETF will use.  And cite one or more RFC precedents from the past 
that follow the definitions as currently written/approved.

Agreed terms and definitions are the foundation of standards,
without them what we write and say will have a degree of 
ambiguity.

hope this helps,
Al

> From: WGChairs [mailto:[email-masked]] On Behalf Of Stephen
> Farrell
> Sent: Tuesday, August 30, 2016 6:25 PM
> To: Flemming Andreasen; [email-masked]; [email-masked]
> Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?
> 
> 
> Hiya,
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 30 Aug 2016 22:22:11 -0500

> folks want to give it a shot, you have my best wishes.

I tend to agree.

I noticed Keith Drage commented that the important thing is that the 
draft document what it means. I think it's perfectly reasonable to say 
"This document updates RFC XXXX to add an optional extension". if the 
situation warranted, it would also reasonable to say "This document 
updates RFC XXXX to make a critical fix to the FOO protocol; new and 
existing FOO implementations should implement this as soon as feasible."

I think the (current) IESG is going to be much more interested in in the 
practical nature of an update than whether said update fits some formal 
definition of the term.

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 05:38:58 +0000

Hi,

Note that this issue does not only affect us in IETF, or the people that implement our specs. It also affects other SDOs that reference our specifications.

For example, 3GPP has a concept of releases. When a release has been "frozen", it basically means that no new functionality is added. Only corrections to bugs that are considered essential are allowed. Any new functionality will go into the next release.

Now, let's say that, within release X, there is a normative reference to RFC Y.

Then, later, RFC Z updates RFC Y. Is RFC Z now automatically part of release X? Or, would 3GPP have to explicitly add a reference to RFC Z in release X? 

This information is not only important for the developers, but also for people writing test/conformance-specifications, sales people - and the people from different vendors arguing with each other about who is right and wrong when something doesn't interop :) Sure, a developer implementing RFC Y can claim compliance to RFC Y, but can he/she claim compliance to 3GPP release X?

You could of course claim that this is a decision 3GPP has to make. But, other SDOs may be in the same situation, and make a different conclusion than 3GPP, and that will sooner or later cause a mess. 

Therefore, I think it should be clear what "update" mean. If there is not a single solution, and we have to deal with it case by case, fine, but once the RFC is published it should be clear.

Regards,

Christer

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 31 August 2016 06:22
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [irsg] "Updates: RFC xxx" - what does it actually mean ?

On 30 Aug 2016, at 16:44, Stephen Farrell wrote:

> 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?
>
> 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.

I tend to agree.

I noticed Keith Drage commented that the important thing is that the draft document what it means. I think it's perfectly reasonable to say "This document updates RFC XXXX to add an optional extension". if the situation warranted, it would also reasonable to say "This document updates RFC XXXX to make a critical fix to the FOO protocol; new and existing FOO implementations should implement this as soon as feasible."

I think the (current) IESG is going to be much more interested in in the practical nature of an update than whether said update fits some formal definition of the term.

Ben.

---

From: [email-masked]
Date: Wed, 31 Aug 2016 09:35:28 +0200

> folks want to give it a shot, you have my best wishes.

I think this is a good point.
In 6man we have gone through a round of discussions with regards to changing the default IID generation in all the IPv6 over Foo documents. After learning from doing RFC2460bis we started off by insisting on the document being very explicit in what text in the originals it changes. Apart from making the new document hard to read, it also turned out it wasn't what we wanted to say. There was no consensus on the "patch" approach, in the end the WG wanted a much more 'implied' update. That makes writing the IPv6 over foo -bis documents harder, but we'll live with that.

I like that the current "Updates" has flexibility.

Cheers,
Ole

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 Aug 2016 06:36:13 -0600

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: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 16:11:35 +0200

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?

Mirja

> Am 31.08.2016 um 14:36 schrieb Cullen Jennings <[email-masked]>:
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Aug 2016 10:27:36 -0400

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 14:28:49 +0000

Hi,

>"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)?

Regards,

Christer

> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 14:53:15 +0000

+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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 31 Aug 2016 17:02:05 +0200

I don’t think that the IETF defines what ‚compliance‘ means. But I would say if you state complicate to one RFC, you only comply to this one and if you also comply to the updates, you should state that you comply to the other RFCs (as well). Otherwise it would be really confusing if you develop a production and a new RFC is published later on that updates the RFC that your implementation follows…

> Am 31.08.2016 um 16:28 schrieb Christer Holmberg <[email-masked]>:
> 
> Hi,
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 31 Aug 2016 10:14:14 -0500

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

>> (but not replaced) this one.  >Generally, only immediately succeeding 
>> 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?
>

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.

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

>> 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: "Ben Campbell" <[email-masked]>
Date: Wed, 31 Aug 2016 10:23:11 -0500

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:

> 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.
>
> still desire to have metadata about this, then I propose that we 
> define *new* terms that *can* be agreed upon.
>
> 	Thanks,
> 	Paul
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 15:45:10 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 31 Aug 2016 11:52:16 -0400

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:
>> IESG) to have a formal definition. I find that to be the most troubling.
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 31 Aug 2016 11:01:20 -0500

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:

> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 31 Aug 2016 12:06:57 -0400

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

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Wed, 31 Aug 2016 17:39:13 +0000

Yes, poorly worded questions lead to ambiguous answers. That’s not the fault of any RFC being marked as updating another RFC.

	Tony

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 18:21:31 +0000

Hi,

I am not sure whether it's a poorly worded questions. If even we can't tell what "update" means, how can we expect others to?

Regards,

Christer

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of HANSEN, TONY L
Sent: 31 August 2016 20:39
Cc: [email-masked]; RFC Editor <[email-masked]>
Subject: Re: "Updates: RFC xxx" - what does it actually mean ?

	Tony

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Wed, 31 Aug 2016 16:02:20 +0000

Christer,

What do you mean by “state compliance”? The IETF doesn’t deal with compliance. There is no direct relationship between an update to an RFC and compliance statements. Also, there may be a slight language difference going on here, between compliance statements and compliance requirements.

A compliance statement says how well an implementation complies to an RFC or protocol relative to a moment in time. It would be based on how well tests on the implementation comply to the MUSTs, SHOULDs, MUST NOTs, SHOULD NOTs, and MAYs found in the RFC specs in question.

A compliance requirement is about expectations for an implementation.

A compliance statement talking about how well the implementation complies to a particular RFC is unaffected by an update to the RFC. If an update to an RFC comes out, the compliance statement should be updated to include information on how well it complies to that update. But there’s no a priori relationship.

A compliance requirement saying simply “you need to be compliant with RFC X” expecting it to implicitly include updates is poorly written. A better compliance requirement would say “you need to be compliant with RFC X as updated by RFC Y and Z”.

	Tony Hansen

On 8/31/16, 10:28 AM, "WGChairs on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 19:01:37 +0000

Ok, I take a step back.

If a specification Y (IETF or other SDO) normatively references RFC X, which has been updated by RFC Y, does that mean that the updates in RFC Y are also implicitly referenced?

Regards,

Christer

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of HANSEN, TONY L
Sent: 31 August 2016 19:02
Cc: [email-masked]; RFC Editor <[email-masked]>
Subject: Re: "Updates: RFC xxx" - what does it actually mean ?

Christer,

	Tony Hansen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 31 Aug 2016 15:16:24 -0400

Christer, as far as I can tell, with the marginal exception of errata, 
nothing changes an RFC.  So if RFC X references RFC Y, and RFC Z updates 
RFC Y, no, that does not update RFC X.  It does mean that anyone 
starting at RFC X will get the information that there is additional 
information they should know.  If we are (as we try to be) consistent 
about including teh description of the relationship in the abstract, one 
can easily determine if the updating RFC (Z) is relevant when you start 
at X.  But the reference from X to Y is always to Z.

Note that even when Z obsoletes Y, that does not mean that the reference 
from X to Y now points to Z.  It does mean that someone trying to 
understand X ought to consider Z instead, but the reference is still to 
Y.  And no, we do not normally go update existing RFCs that references 
an obsoleted one.

Yours,
Joel

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 31 Aug 2016 15:19:09 -0400

Hi Christer,

...
> 
> Ok, I take a step back.
> 
> If a specification Y (IETF or other SDO) normatively references RFC X,
> which has been updated by RFC Y, does that mean that the updates in RFC
> Y are also implicitly referenced?
[ACM] 

I think the answer has to be no. At the time "spec Y" was written, 
it referenced a specific version of RFC X, with a date, and 
specific text. The update in RFC Y might break the referencing spec.
That's not a problem for any spec developers (predicting the future with
accuracy).

Some SDOs include an introductory statement at the beginning of the 
Reference Section, indicating that up-to-date versions of the 
references should be consulted, or something like that.
But the reference refers to exactly one body of text.

Al

> What do you mean by “state compliance”? The IETF doesn’t deal with
> compliance. There is no direct relationship between an update to an RFC
> and compliance statements. Also, there may be a slight language
> difference going on here, between compliance statements and compliance
> requirements.
> 
> A compliance statement says how well an implementation complies to an
> RFC or protocol relative to a moment in time. It would be based on how
> well tests on the implementation comply to the MUSTs, SHOULDs, MUST
> NOTs, SHOULD NOTs, and MAYs found in the RFC specs in question.
> 
> A compliance statement talking about how well the implementation
> complies to a particular RFC is unaffected by an update to the RFC. If
> an update to an RFC comes out, the compliance statement should be
> updated to include information on how well it complies to that update.
> But there’s no a priori relationship.
> 
> A compliance requirement saying simply “you need to be compliant with
> RFC X” expecting it to implicitly include updates is poorly written. A
> better compliance requirement would say “you need to be compliant with
> RFC X as updated by RFC Y and Z”.
> 
> 	Tony Hansen
> 
> On 8/31/16, 10:28 AM, "WGChairs on behalf of Christer Holmberg"
> <[email-masked] on behalf of [email-masked]>
> wrote:
> 
>     What if I state compliance with the original document? Does that
> mean I am also compliant with the update(s)?
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Aug 2016 19:57:10 +0000

Hi,

> Christer, as far as I can tell, with the marginal exception of errata, nothing changes an RFC.  So if RFC X references 
> RFC Y, and RFC Z updates RFC Y, no, that does not update RFC X.  

If that's the case, I think it should be formally written down somewhere.

> It does mean that anyone starting at RFC X will get the information that there is additional information
> they should know.  If we are (as we try to be) consistent about including teh description of the relationship
> in the abstract, one can easily determine if the updating RFC (Z) is relevant when you start at X.  But the reference from X to Y is always to Z.

Sure. When people start to code things, they normally figure these things out. I think the issue is more related to already existing standards and implementations.

> Note that even when Z obsoletes Y, that does not mean that the reference from X to Y now points to Z.

Agree. In 3GPP we actually had a work item on whether we were going to replace an obsoleted RFC or not, because it was not done automatically.

Regards,

Christer