Subject: RFC 4861 missing updated-by (was: [Editorial Errata Reported] RFC6275 (5083) (fwd))

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Aug 2017 09:49:46 +0200 (CEST)

FYI. I decided to raise an errata against RFC6275 that seems to update 
RFC4861 without this being noted anywhere in either document.

I am still unsure if I also need to raise an errata against RFC4861, but I 
think this single errata would take care of both documents gaining 
updates/updated-by references?

---------- Forwarded message ----------
Date: Thu, 10 Aug 2017 00:29:23 -0700 (PDT)
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC6275 (5083)

The following errata report has been submitted for RFC6275,
"Mobility Support in IPv6".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5083

--------------------------------------
Type: Editorial
Reported by: Mikael Abrahamsson <[email-masked]>

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----
Section 7.2 of RFC6275 introduces a new flag, called the R bit. This seems to update RFC 4861 section 4.6.2. However, there is no mention in RFC6275 or in RFC4861 that this happened.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6275 (draft-ietf-mext-rfc3775bis-13)
--------------------------------------
Title               : Mobility Support in IPv6
Publication Date    : July 2011
Author(s)           : C. Perkins, Ed., D. Johnson, J. Arkko
Category            : PROPOSED STANDARD
Source              : Mobility EXTensions for IPv6
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Aug 2017 14:07:19 -0400

> RFC4861 without this being noted anywhere in either document.

Are we able to update the metadata on RFC4861 in response to this errata?
I realize we can't re-issue 6275.

Since the Updates is to make sure that readers of 4861 know about new things,
the metadata 4861->6275 (which shows up in the tools page and datatracker for
the old documents) is really the important direction.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Aug 2017 13:38:44 -0500

This is a question for the IESG (it's more a question of policy than it 
is tool capability).

I'm pretty sure the question's been asked before (and the discussion led 
to a "no, if you want to fix this, do it with an RFC").

RjS

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 10 Aug 2017 20:39:43 +0200

My https://www.rfc-editor.org/errata_search.php?eid=5080
also only describes that 6164 updates 4861, seems like the
same thing. I am expecting that the metadata update will be
done for both documents. Otherwise there is too much bureaucracy.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 10 Aug 2017 20:42:33 +0200

Hmm... the way i understood it, this is just missing metadata
linking the two documents. But of course i have no experience
with current practices whether metadata will be fixed or not.

Metadata is a lot more like what i think metadata is if it can
be updated sedparately from the doc. Otherwise its a lot more like data ;-P

On Thu, Aug 10, 2017 at 01:38:44PM -0500, Robert Sparks wrote:
> This is a question for the IESG (it's more a question of policy than
> it is tool capability).
> 
> I'm pretty sure the question's been asked before (and the discussion
> led to a "no, if you want to fix this, do it with an RFC").
> 
> RjS
> 
> 

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Aug 2017 08:06:08 +1200

> This is a question for the IESG (it's more a question of policy than it 

I would say it's a question for the RFC Editor, who would ask for advice
from the IESG since these are IETF stream documents. (It's the RFC Editor
who maintains the metatdata for RFCs.)

    Brian

> .

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 10 Aug 2017 22:52:36 -0400

Hi all,
  I had a short chat with Mikael about this during the Prague IETF. One of the major issues I have encountered is that we do not, as a community, have a common understanding of what the “Updates:” tag means (or even what it is supposed to mean). Until that gets resolved, there will be no clear indication on when to mark a document as updated and when not to. As for this Erratum, I will hold onto it until we have a better idea on how to proceed. As an example another document in this category is RFC4191 that I personally think should update RFC2461/RFC4861 because of changing the RA flag bits. Similarly, should RFC4389 update RFC4861 for the same reason as well?

Thanks
Suresh

> On Aug 10, 2017, at 4:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 11 Aug 2017 07:50:39 +0200 (CEST)

On Thu, 10 Aug 2017, Suresh Krishnan wrote:

>  I had a short chat with Mikael about this during the Prague IETF. One 
> of the major issues I have encountered is that we do not, as a 
> community, have a common understanding of what the “Updates:” tag means 
> (or even what it is supposed to mean). Until that gets resolved, there 
> will be no clear indication on when to mark a document as updated and 
> when not to. As for this Erratum, I will hold onto it until we have a 
> better idea on how to proceed. As an example another document in this 
> category is RFC4191 that I personally think should update 
> RFC2461/RFC4861 because of changing the RA flag bits. Similarly, should 
> RFC4389 update RFC4861 for the same reason as well?

THanks for this. First time this was brought up was in november last year, 
when me and Erik Kline were notified that our proposed PIO-X bit was 
overlapping with the R bit.

https://www.ietf.org/mail-archive/web/ipv6/current/msg25491.html

I then raised this with the authors of 6275 without getting any meaningful 
response, I have raised it with multiple ADs as well.

I find that the current situation is very dangerous, and it needs to be 
resolved. I don't much care if we fix it by having an IANA registry for 
all fields in everything, or if we fix the updated-by references, or if we 
have "please also read"-reference, or if we just log erratum against RFCs 
that seem to have no updated-by but have more recent documents that change 
bits in them.

SOMETHING needs to happen. I wasn't told that there were things happening, 
that's why I wanted to "force the issue" by issuing an errata.

And by writing the above text, I realise that I agree with that 4861 
probably need to have some kind of "errata" against it as well, becuase 
the important part is that readers of 4861 finds 6275, not the other way 
around.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Aug 2017 08:33:50 +1200

> probably need to have some kind of "errata" against it as well, 

That's why the RFC Editor needs to update the metadata for both RFCs.

The error is the missing "updates", and that is an error in 6275.

The consequence of validating that error is a change to the metadata
for both RFCs.

There is no error in 4861. There is a gap in its metadata.

(Same situation for https://www.rfc-editor.org/errata_search.php?eid=5080)

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Aug 2017 14:03:48 -0400

> The consequence of validating that error is a change to the metadata

Exactly!!

I think that the IESG should be able to create new forward references without
publishing new documents.   It should be a relatively cheap operation.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 13 Aug 2017 07:55:57 +0200 (CEST)

On Sat, 12 Aug 2017, Michael Richardson wrote:

> I think that the IESG should be able to create new forward references 
> without publishing new documents.  It should be a relatively cheap 
> operation.

Agreed. Potentially it could be done with a 2 week last call announcement 
so that if anyone disagrees, their voice can be heard.

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Aug 2017 11:11:02 +0200

I don't think adding a new flag in a "Reserved" field qualifies as updating an RFC.
That's what we have IANA registries for.

/ot

> On 13 Aug 2017, at 07:55, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> I think that the IESG should be able to create new forward references without publishing new documents.  It should be a relatively cheap operation.
> 
> Agreed. Potentially it could be done with a 2 week last call announcement so that if anyone disagrees, their voice can be heard.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 12:41:27 +0200 (CEST)

> That's what we have IANA registries for.

So where is the IANA registry for the bit fields that RFC4861 
standardises?

Or so say it another way:

If I want to use a new bit field that for instance RFC4861 specifies, how 
am I going to find what other RFCs has touched this, if there is no IANA 
registry (as far as I know there isn't, I can't find one).

Someone (IETF leadership) has to put their foot down and say one of two 
things (or something completely different):

1. If you move reserved bits to in-sure, you update the original RFC that 
defined these bits as reserved. Metadata is added to the original RFC so 
this can be found.

2. There must be IANA registries for all bit fields, and if you change 
reserved bits to in-use, this must be reflected in the IANA registry.

The way we do things now by not having IANA registries and not updating 
RFCs when changing reserved bits to in-use is extremely prone to mistakes. 
We missed this completely when we wrote PIO-X and it was caught because 
someone happened to notice it and who was into MIPv6.

Or what am I missing?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 12:53:38 +0200 (CEST)

> 1. If you move reserved bits to in-sure, you update the original RFC that

Gah, I meant "in-use".

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 13:02:39 +0200 (CEST)

> reserved bits to in-use, this must be reflected in the IANA registry.

The closest thing I can find:

https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

3	Prefix Information	[RFC4861]

If RFC6275 was listed there, then at least there would be a better chance 
of finding it. So is that the errata that should have been filed instead, 
that 6275 didn't send an IANA request to add it to the above item, and 
that this should now be sent?

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Aug 2017 13:04:23 +0200

Mikael,

> So where is the IANA registry for the bit fields that RFC4861 standardises?
> 
> If I want to use a new bit field that for instance RFC4861 specifies, how am I going to find what other RFCs has touched this, if there is no IANA registry (as far as I know there isn't, I can't find one).
> 
> Someone (IETF leadership) has to put their foot down and say one of two things (or something completely different):
> 
> 1. If you move reserved bits to in-sure, you update the original RFC that defined these bits as reserved. Metadata is added to the original RFC so this can be found.
> 
> 2. There must be IANA registries for all bit fields, and if you change reserved bits to in-use, this must be reflected in the IANA registry.
> 
> The way we do things now by not having IANA registries and not updating RFCs when changing reserved bits to in-use is extremely prone to mistakes. We missed this completely when we wrote PIO-X and it was caught because someone happened to notice it and who was into MIPv6.
> 
> Or what am I missing?

As far as I can see you are correct.

The resolution I would prefer in this case would be that you wrote a draft instructing IANA to create the new PIO flags registry.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Aug 2017 08:53:14 +1200

> The resolution I would prefer in this case would be that you wrote a draft instructing IANA to create the new PIO flags registry.

Good idea. But Mikael does have a point: changing a "reserved" field (which is typically
also specified as MBZ) to an assigned status is a substantive change to the RFC that
reserved it.

I wish we'd noted that in https://tools.ietf.org/html/rfc6709#section-4.2

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Aug 2017 23:13:23 +0200

Brian,

[...]

> also specified as MBZ) to an assigned status is a substantive change to the RFC that

A reserved field is there for forward extensibility...
How can using that extensibility (which as you state is specified as MBZ specifically to be forward compatible) be a substantive change to the RFC that reserved it??

> I wish we'd noted that in https://tools.ietf.org/html/rfc6709#section-4.2

Thanks for the pointer. That section looked good to me.

Best regards,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 23:33:09 +0200 (CEST)

On Tue, 15 Aug 2017, Ole Troan wrote:

> How can using that extensibility (which as you state is specified as MBZ 
> specifically to be forward compatible) be a substantive change to the 
> RFC that reserved it??

Because the reserved bits are no longer reserved if another RFC now says 
they're used for something.

So for this I-D you wanted me to write. Is the request to IANA to go over 
4861 and create registries for all bit fields? What other RFCs should we 
include in this request?

Because if someone (I don't know who, IETF leadership?) has decided that 
"taking" bits is not an substantitive change to an RFC and that there 
should be no metadata updates when reserved bits are "taken", then the 
IANA registry is crucial for all bit fields, not just the PIO bits I was 
talking about here.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 00:22:22 +0200

Mikael,

> Because the reserved bits are no longer reserved if another RFC now says they're used for something.
> 
> So for this I-D you wanted me to write. Is the request to IANA to go over 4861 and create registries for all bit fields? What other RFCs should we include in this request?
> 
> Because if someone (I don't know who, IETF leadership?) has decided that "taking" bits is not an substantitive change to an RFC and that there should be no metadata updates when reserved bits are "taken", then the IANA registry is crucial for all bit fields, not just the PIO bits I was talking about here.

with regards to change. I think the point here is that an implementor of 4861 doesn't need to know about 6275 to implement 4861.

/ot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Aug 2017 18:27:18 -0400

I agree that an implementor of 4861 does not, technically, need to know 
about 6275.

The more interesting problem, in the absence of a registry or updated-by 
flag, is how someone proposing to use one of the reserved bits in 4861 
is supposed to know which bits are available?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Aug 2017 10:56:18 +1200

> is supposed to know which bits are available?

And how does a person *maintaining* an existing implementation of 4861
know that something has changed, so their code might be out of date?

This is quite similar to one problem we tried to deal with in RFC 7045.
How do product maintainers know that a new extension header has been
standardised? In some ideal world, one could sign up to get a warning
whenever something changes in specified IANA registries.

This problem is much wider than IPv6, of course.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Aug 2017 09:56:07 +1000

In message <[email-masked]>, Brian E Carpenter 
> whenever something changes in specified IANA registries.

Well we just poll the registries we are worried about daily and if
there is a change we generate a email message.  There are not a lot
of companies in the world that look at these registries.

>  specifically to be forward compatible) be a substantive change to the RFC th
> at reserved it??
> >>>
>  4861 and create registries for all bit fields? What other RFCs should we inc
> lude in this request?
> >>>
> "taking" bits is not an substantitive change to an RFC and that there should 
> be no metadata updates when reserved bits are "taken", then the IANA registry
>  is crucial for all bit fields, not just the PIO bits I was talking about her
> e.
> >>
> >> with regards to change. I think the point here is that an implementor of 4
> 861 doesn't need to know about 6275 to implement 4861.
> >>
> >> /ot
> >>
> >>
> >>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 15 Aug 2017 22:00:22 -0400

Hi Mikael,
  I understand and agree with your point and I made the same point about 11 years ago regarding RA flags :-)

https://www.ietf.org/mail-archive/web/ipv6/current/msg06561.html  

Quoting from there 

"In a slightly related note, I feel that any document which is assigned one of these flags MUST be indicated as updating the ND specification (RFC2461/RFC2461bis). If this is not done it is highly likely people would assume that those bits are unallocated. e.g. RFC3775, RFC4191 and RFC4389 use these flag bits but do not update RFC2461. So a new draft author may wrongly assume the bit to be available for use. I saw a presentation in the 16ng meeting where the authors were trying to reuse the MIPv6 Home agent bit for their proposal.”

To be very frank, we have usually identified these issues whenever people wanted to extend these fields, and (thankfully) have not run into an actual conflict. I do think this is a problem that is wider in scope than 6man and we need to solve it in a systematic manner. I think the first step would be to have a common understanding of what an Update: is supposed to signify and get community consensus on that so that we can apply these rules in a consistent manner. I have now volunteered to help out on a document in this space.

Thanks
Suresh

> On Aug 15, 2017, at 5:33 PM, Mikael Abrahamsson <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 07:23:36 +0200 (CEST)

On Wed, 16 Aug 2017, Ole Troan wrote:

> with regards to change. I think the point here is that an implementor of 
> 4861 doesn't need to know about 6275 to implement 4861.

But is this really a valid reason? Wouldn't it potentially be better for 
an 4861 implementation to at least be aware of the R flag, potentially? Is 
the implementor better kept in the dark about this, than to have to spend 
a minute to see if some aspect of RFC6275 might apply to it?

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 10:35:32 +0200

Brian,

> know that something has changed, so their code might be out of date?

That's the point. The 4861 implementation is not out of date. Not by 6275 nor by PIO-X.
If a 4861 implementation was required to change then an update would have been appropriate.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 10:40:17 +0200

Mikael,

> But is this really a valid reason? Wouldn't it potentially be better for an 4861 implementation to at least be aware of the R flag, potentially? Is the implementor better kept in the dark about this, than to have to spend a minute to see if some aspect of RFC6275 might apply to it?

If an 4861 implementation is not affected by the other specification (6275) then I think using update is wrong.
(I don't think you should make too many assumptions about the level of darkness that implementors live in...)

Cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 10:48:07 +0200 (CEST)

On Wed, 16 Aug 2017, Ole Troan wrote:

>
> If an 4861 implementation is not affected by the other specification 
> (6275) then I think using update is wrong. (I don't think you should 
> make too many assumptions about the level of darkness that implementors 
> live in...)

I still think there should be some kind of forward reference to the 
document that has assigned or changed bits. If we can't use updated-by, 
then we need to invent some other kind of reference.

The way things are right now, things will be missed and there will be 
multiple uses of the same information. I'm surprised this hasn't happened 
more often. I especially think the risk will increase as more of the 
people who have been here a long time goes into retirement and their 
first-hand knowledge isn't available anymore.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 10:51:31 +0200

Mikael,

>> If an 4861 implementation is not affected by the other specification (6275) then I think using update is wrong. (I don't think you should make too many assumptions about the level of darkness that implementors live in...)
> 
> I still think there should be some kind of forward reference to the document that has assigned or changed bits. If we can't use updated-by, then we need to invent some other kind of reference.

I don't think that works.
Think of RFC3315 as an example. Should it have a forward reference to every DHCP option?

> The way things are right now, things will be missed and there will be multiple uses of the same information. I'm surprised this hasn't happened more often. I especially think the risk will increase as more of the people who have been here a long time goes into retirement and their first-hand knowledge isn't available anymore.

That's what an IANA registry is for.

Don't assume implementors are idiots. The reason why they don't do what you want are typically not because of lack of intelligence or reading skills. ;-)

Best regards,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 11:18:29 +0200

Hi Ole,

> Think of RFC3315 as an example. Should it have a forward reference to every DHCP option?

I think there is a difference here between adding new options (where there is a clear expectation of new options being developed and the original RFC pointing to the registry) and using a reserved bit-field (which changes the meaning of an existing bit from "doesn't mean anything (yet)" to "means X").

> That's what an IANA registry is for.

For options: yes. For bit fields: an IANA registry is not where I would look for possible changes to each and every field.

> Don't assume implementors are idiots. The reason why they don't do what you want are typically not because of lack of intelligence or reading skills. ;-)

As an implementor I have been confused about the meaning of bits with only Google to help in finding what it means. My personal preference would be to have an updated-by references for such changes. I agree that this isn't feasible for option codes and things like that because of the possibly huge number of options, but for updates to fields I think it is the right place.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 11:31:35 +0200 (CEST)

On Wed, 16 Aug 2017, Ole Troan wrote:

> Don't assume implementors are idiots. The reason why they don't do what 
> you want are typically not because of lack of intelligence or reading 
> skills. ;-)

I've never assumed implementors are idiots. It seems to me that you're the 
one treating them as idiots, in that they can't handle an updated-by 
reference.

My problem is that from a document writer perspective, me and Erik sat 
there and was looking for a reserved bit field to put a flag. We looked at 
4861, saw no relevant updated-by documents, and chose one of the reserved 
bits.

I still don't see what we could have done better as a document writer. Yet 
here we are, 10 months after I initially brought this up, and the IANA 
registry still doesn't list 6275 for the PIO option, we still have no 
updated-by references or anything.

This is going nowhere really slowly.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 11:29:01 +0200

Hi,

Sorry for replying to myself.

> As an implementor I have been confused about the meaning of bits with only Google to help in finding what it means. My personal preference would be to have an updated-by references for such changes…

After some more thought I came up with the following "definition": defining a new option is just using the field for what it was designed for, so that doesn't update the meaning of anything in the original RFC. The field was specified to contain an option code, and still does. Using a bit that was previously reserved changes the meaning of that bit and therefore does update the original RFC.

Does that make sense?

Cheers,
Sander

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Aug 2017 12:52:28 +0200

>After some more thought I came up with the following "definition": =
>defining a new option is just using the field for what it was designed =
>for, so that doesn't update the meaning of anything in the original RFC. =
>The field was specified to contain an option code, and still does. Using =
>a bit that was previously reserved changes the meaning of that bit and =
>therefore does update the original RFC.
>
>Does that make sense?

The obviously bad thing is to allocate a bit in an RFC and not telling anyone
about that beyond publishing the RFC.

So there seem two ways around that:
1) the RFC that allocates the bit explictly updates the RFC that introduced the
field. Of course this requires the rfc editor to accuratly track this.
2) the RFC that introduces the field opens an IANA registry for the field.

When reading RFCs, those two seem roughly equivalent. If you read an RFC and
it is updated by a few other RFC, you need to quickly skim those to see if
they are relevant. If an RFC introduces an IANA registry then a quick check
at IANA is in order.

Of course it doesn't make sense to open lots of IANA registries on the off
chance that some future RFC will need to allocate a bit. Likewise, it doesn't
make sense to have an RFC that is updated by dozens of other RFCs just to
allocate some bits. 

Given the relatively high overhead of publishing an RFC that introduces an IANA
registry for RFC 4861, it may make sense to just mark RFC 4861 as updated.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 12:59:49 +0200

Sander,

> After some more thought I came up with the following "definition": defining a new option is just using the field for what it was designed for, so that doesn't update the meaning of anything in the…

I don't think that is necessary for MBZ fields.

Reserved       This field is unused.  It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

/ot

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 13:12:33 +0200

Hi,

> Reserved       This field is unused.  It MUST be initialized to zero by the sender and MUST be ignored by the receiver.

That confirms the "updated-by" is necessary. With the definition of the new flags that "MUST" is overruled, and implementations are allowed to put a non-zero value in it :)

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 13:40:22 +0200

Sander,

> That confirms the "updated-by" is necessary. With the definition of the new flags that "MUST" is overruled, and implementations are allowed to put a non-zero value in it :)

Quite the contrary. ;-)

/ot

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 13:48:21 +0200

Hi,

>> That confirms the "updated-by" is necessary. With the definition of the new flags that "MUST" is overruled, and implementations are allowed to put a non-zero value in it :)

Sorry, but I strongly disagree.

Look for example at https://tools.ietf.org/html/rfc4861#section-4.2. It explicitly states:

>       Reserved       A 6-bit unused field.  It MUST be initialized to
>                      zero by the sender and MUST be ignored by the
>                      receiver.

This text is simply not accurate anymore after https://tools.ietf.org/html/rfc6275#section-7.1, which explicitly is titled "Modified Router Advertisement Message Format":

>    Home Agent (H)
> 
>       The Home Agent (H) bit is set in a Router Advertisement to
>       indicate that the router sending this Router Advertisement is also
>       functioning as a Mobile IPv6 home agent on this link.
> 
>    Reserved
> 
>       Reduced from a 6-bit field to a 5-bit field to account for the
>       addition of the above bit.

If that isn't an update to rfc4861 then I don't know what would be...

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Aug 2017 13:51:31 +0200

> If that isn't an update to rfc4861 then I don't know what would be...

An update to 4861 would be something that would affect the implementor of 4861 and changes that could be incorporated if 4861 would be updated. that's not at all 6275. 6275 can be completely ignored from a 4861 perspective, unless you chose to implement 6275.

/ot

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 14:00:07 +0200

Hi Philip,

> Op 16 aug. 2017, om 12:52 heeft Philip Homburg <[email-masked]> het volgende geschreven:
> 

Perfect, as long as it's clear where to find such information in the original RFC. If the author wrote explicit text on where to document changes (IANA registry) then that should be used. If no explicit place has been defined then all changes should be considered updates to the original RFC so that implementors can find them.

> make sense to have an RFC that is updated by dozens of other RFCs just to

Agree. In the worst case the author of the original RFC didn't anticipate the large number of bit/codepoint/etc allocations, and a new RFC can update the original and introduce an IANA registry.

> registry for RFC 4861, it may make sense to just mark RFC 4861 as updated.

I think this would be the appropriate choice in this case. Other cases might warrant a different choice though. I can see Ole's point for certain cases, just not this specific one :)

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Wed, 16 Aug 2017 14:04:17 +0200

Hi Ole,

> Op 16 aug. 2017, om 13:51 heeft Ole Troan <[email-masked]> het volgende geschreven:
> 

6275 overrides text in 4861, it's as simple as that. If you only consider an implementor to be someone who wants to write a minimal implementation then you are correct. If you include all other implementations like protocol analysers, security devices etc then it *is* important to know that "those bits MUST be zero" isn't completely true anymore.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 14:08:51 +0200 (CEST)

On Wed, 16 Aug 2017, Ole Troan wrote:

> An update to 4861 would be something that would affect the implementor 
> of 4861 and changes that could be incorporated if 4861 would be updated. 
> that's not at all 6275. 6275 can be completely ignored from a 4861 
> perspective, unless you chose to implement 6275.

Then we need new meta tags.

Either there needs to be a "bitfield-updated-by" metatag to handle this 
usecase, or there needs to be an 
"IANA-registry-now-for-bitfields-mentioned-in-this-RFC" metatag, or both.

Having no mention what so ever that reserved bits are no longer reserved 
is just... I don't know, I just can't graps why you think it's ok for 4861 
to have no mention what so ever that some reserved bits are no longer 
reserved and that the MUST for them to be ZERO no longer applies.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 08:33:17 -0400

Ole Troan <[email-masked]> wrote:
    > How can using that extensibility (which as you state is specified as
    > MBZ specifically to be forward compatible) be a substantive change to
    > the RFC that reserved it??

The point is that it deserves an "Updates".
Someone reason 4861 should be directed to read the update so that they see
why the reserved bits might not be zero anymore.  It might be functionality
that they actually want to implement.  Or not.

("MBZ" is the wrong sense, because it "security" devices get it wrong.
Must send as zero and ignore upon receipt is the functionality that we want.
I wish that our compliance testing suites actually checked that these
reserved fields are ignored properly)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 08:35:53 -0400

Mikael Abrahamsson <[email-masked]> wrote:
    >> If an 4861 implementation is not affected by the other specification (6275)
    >> then I think using update is wrong. (I don't think you should make too many
    >> assumptions about the level of darkness that implementors live in...)

    > I still think there should be some kind of forward reference to the document
    > that has assigned or changed bits. If we can't use updated-by, then we need
    > to invent some other kind of reference.

+1.
I don't care how we cause the forward references to be created, but they need
to be created.  Updates: is appropriate.  6275 may not FORCE an 4861
implementation to change, but a 4861 implementation might WANT to change.

---

From: Timothy Winters <[email-masked]>
Date: Wed, 16 Aug 2017 08:43:06 -0400

> reserved fields are ignored properly)

I looked thru the IPv6 Ready Logo Test Specification for this, we test this
for NAs and NSs but not RSs/RAs.   I've filed a bug to update the Test
Specification to check this in the next release.

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 14:48:27 +0200 (CEST)

On Wed, 16 Aug 2017, Timothy Winters wrote:

> I looked thru the IPv6 Ready Logo Test Specification for this, we test 
> this for NAs and NSs but not RSs/RAs.  I've filed a bug to update the 
> Test Specification to check this in the next release.

Great takeaway from this discussion. I have personally run into problems 
with an implementation that did not ignore MBZ bits but instead required 
them to be 0. Since the sender of the packet had a bug and didn't zero 
them, this caused things not to work.

The sender of the packet which didn't zero the bits immediately understood 
what the problem was and offered to correct things, however the vendor of 
the device that didn't ignore the bits took a lot longer to convince that 
they were doing something wrong.

This was OSPFv3 and it had a 24 bit field in there with the remaining 8 
bits being MBZ and ignored. The vendor put this into a 32 bit field and 
compared meaning that when the other end messed up their zeroing the 
reserved bits, the compare failed. I'd imagine this is not too uncommon 
problem.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Aug 2017 23:21:13 +1000

> reserved bits, the compare failed. I'd imagine this is not too uncommon 

It's not just the protocol implementers that get this wrong.  Firewall
vendors also get this wrong by blocking packets with reserved bits
set.  It then takes years longer to deploy extensions that use the
reserved bits.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Aug 2017 15:30:11 +0200 (CEST)

On Wed, 16 Aug 2017, Mark Andrews wrote:

> vendors also get this wrong by blocking packets with reserved bits set. 
> It then takes years longer to deploy extensions that use the reserved 
> bits.

Absolutely. PIX killed ECN for many years.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Aug 2017 15:31:26 +0200

We have a long tradition of misidentifying bits in packets that really are extension points.

“Reserved” is only marginally better than “MBZ” (which turns untrue with the next extension using them); both signal to the implementer “I don’t have to think about these fields”.

To avoid those misconceptions coming up with the readers of specs, in box notation, I like to mark those bits available as extension points with an underscore (see Figure 5 of RFC 7400):

https://tools.ietf.org/html/rfc7400#section-3.3

This does make people wonder, and maybe readers then go ahead and read what is actually said about these bits.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 13:26:20 -0400

> Think of RFC3315 as an example. Should it have a forward reference to

Yes.  Having worked on rfc3315bis, that would have been a great thing to
have. Did we need to merge them all into 3315bis?  No, but we did need to
look at them to see if they used some feature.  Maybe we could have removed
some unused feature from 3315 because it was never used.

    > you want are typically not because of lack of intelligence or reading

Implementors generally work for idiots called "Product Marketing"

---

From: David Farmer <[email-masked]>
Date: Wed, 16 Aug 2017 13:02:39 -0500

On Wed, Aug 16, 2017 at 6:51 AM, Ole Troan <[email-masked]> wrote:

> An update to 4861 would be something that would affect the implementor of
> 4861 and changes that could be incorporated if 4861 would be updated.

Since RFC4861, or it's predecessors, didn't create a registry for the flags
in question, it (RFC4861) is the primary and best source for the definition
of those flags. If and only if, the authors of RFC4861 had created a
registry for the flags would such a registry become the primary source
instead.  Since RFC4861 is the primary source, the subsequent creation of
such a registry would need to at least be update to RFC4861 as well.
Finally, RFCs and their metadata, serve more than just implementers, they
may be the primary intended audience, but there are many secondary
audiences, operators, developers of other (future) standards, students,
etc...  A change in these flags may or may not be relevant to an
implementer of RFC4861, but it could be of critical importance to these
other audiences, and as the primary source for the meaning of those flags,
it seems quite appropriate for any and all changes in the meaning of those
flags to be an update to RFC4861.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Aug 2017 08:33:39 +1200

> they were doing something wrong.

Sorry to repeat myself, but that's exactly the point we made in
https://tools.ietf.org/html/rfc6709#section-4.2
In other words, it's a quite general problem, and an excellent area
for test suites to exercise.

And IMNSHO it clearly shows why we need an "updates" for such cases, as
well as an IANA registry. Implementers make mistakes, and we should use
every tool we have to make this less likely.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 17:38:01 -0400

> So where is the IANA registry for the bit fields that RFC4861

Right. So either way, 4861 has errata.
Either it's missing a registry, or it's missing a forward reference :-)

    > 1. If you move reserved bits to in-use, you update the original RFC that
    > defined these bits as reserved. Metadata is added to the original RFC
    > so this can be found.

    > reserved bits to in-use, this must be reflected in the IANA registry.

I suggest the following policy, and maybe I'm signing up to write a BCP here.

a) Reserved, (Send as zero, do not examine on receive) fields are simply
   noted as they are now.

b) The first document to do anything with that Reserved area, if it's creating
   new bits, or putting some new field there, Updates the original document,
   and creates the IANA Registry.

c) Additional documents cite the Registry rather that Updates.

Ole, could you get on board with that?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Aug 2017 23:49:58 +0200

> a) Reserved, (Send as zero, do not examine on receive)

If you think that is what “Reserved” means, more power to you, but a rather common understanding of “Reserved” is “We may define those bits later”, with the implied conclusion that a receiving implementation simply gives up and croaks when finding a reserved bit set.

So don’t use the term “reserved” without qualification (or, better, not at all).

> fields are simply

Having these “could be used later for extension points” bits in a protocol is fine, even without a registry, because you cannot define the registry if you don’t know what the structure of these bits is going to be.

>   and creates the IANA Registry.

Well, any document that starts eating bits for extension points needs to do that.
The registry created for the first document that comes up may not be the right one for the second document.

(The bug here was that 4861 should have foreseen that these bits were going to be allocated.
So here, the first document would indeed simply repair that defect.
But that is not true in the general case where you have scattered random unused bits in your packet.)

> c) Additional documents cite the Registry rather that Updates.

Right.  Once you have the right structure for the registries.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 22:34:58 -0400

> If you think that is what “Reserved” means, more power to you, but a
    > rather common understanding of “Reserved” is “We may define those bits
    > later”, with the implied conclusion that a receiving implementation
    > simply gives up and croaks when finding a reserved bit set.

says exactly that.

    > Having these “could be used later for extension points” bits in a
    > protocol is fine, even without a registry, because you cannot define
    > the registry if you don’t know what the structure of these bits is
    > going to be.

Exactly.

    > Well, any document that starts eating bits for extension points needs

yes, but in this case, it didn't.