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

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mikael Abrahamsson

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 <[hidden email]>
To: [hidden email], [hidden email], [hidden email],
     [hidden email], [hidden email], [hidden email],
     [hidden email]
Cc: [hidden email], [hidden email], [hidden email]
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 <[hidden email]>

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Richardson-11

Mikael Abrahamsson <[hidden email]> wrote:
    > FYI. I decided to raise an errata against RFC6275 that seems to update
    > 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 <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

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


On 8/10/17 1:07 PM, Michael Richardson wrote:

> Mikael Abrahamsson <[hidden email]> wrote:
>      > FYI. I decided to raise an errata against RFC6275 that seems to update
>      > 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 <[hidden email]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Toerless Eckert-2
In reply to this post by Michael Richardson-11
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.

On Thu, Aug 10, 2017 at 02:07:19PM -0400, Michael Richardson wrote:

>
> Mikael Abrahamsson <[hidden email]> wrote:
>     > FYI. I decided to raise an errata against RFC6275 that seems to update
>     > 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 <[hidden email]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>



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


--
---
[hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Toerless Eckert-2
In reply to this post by Robert Sparks

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
>
>
> On 8/10/17 1:07 PM, Michael Richardson wrote:
> >Mikael Abrahamsson <[hidden email]> wrote:
> >     > FYI. I decided to raise an errata against RFC6275 that seems to update
> >     > 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 <[hidden email]>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> >
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [hidden email]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
---
[hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Brian E Carpenter-2
In reply to this post by Robert Sparks
On 11/08/2017 06:38, Robert Sparks wrote:
> This is a question for the IESG (it's more a question of policy than it
> is tool capability).

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

>
> 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
>
>
> On 8/10/17 1:07 PM, Michael Richardson wrote:
>> Mikael Abrahamsson <[hidden email]> wrote:
>>      > FYI. I decided to raise an errata against RFC6275 that seems to update
>>      > 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 <[hidden email]>, Sandelman Software Works
>>   -= IPv6 IoT consulting =-
>>
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [hidden email]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Suresh Krishnan-2
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 <[hidden email]> wrote:

On 11/08/2017 06:38, Robert Sparks wrote:
This is a question for the IESG (it's more a question of policy than it 
is tool capability).

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


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


On 8/10/17 1:07 PM, Michael Richardson wrote:
Mikael Abrahamsson <[hidden email]> wrote:
FYI. I decided to raise an errata against RFC6275 that seems to update
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 <[hidden email]>, Sandelman Software Works
 -= IPv6 IoT consulting =-




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


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


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Mikael Abrahamsson
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: [hidden email]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Brian E Carpenter-2
> 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,

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

On 11/08/2017 17:50, Mikael Abrahamsson wrote:

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Michael Richardson-11

Brian E Carpenter <[hidden email]> wrote:
    >> 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,

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

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.

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




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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

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

--
Mikael Abrahamsson    email: [hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Ole Troan-2
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 <[hidden email]> wrote:
>
> 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.
>
> --
> Mikael Abrahamsson    email: [hidden email]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [hidden email]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Mikael Abrahamsson
On Tue, 15 Aug 2017, Ole Troan wrote:

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

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?

--
Mikael Abrahamsson    email: [hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Mikael Abrahamsson
On Tue, 15 Aug 2017, Mikael Abrahamsson wrote:

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

Gah, I meant "in-use".

--
Mikael Abrahamsson    email: [hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Mikael Abrahamsson
In reply to this post by Mikael Abrahamsson
On Tue, 15 Aug 2017, Mikael Abrahamsson wrote:

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

--
Mikael Abrahamsson    email: [hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Ole Troan-2
In reply to this post by Mikael Abrahamsson
Mikael,

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

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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Brian E Carpenter-2
On 15/08/2017 23:04, Ole Troan wrote:

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

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Ole Troan-2
Brian,

[...]

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

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

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

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

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

--
Mikael Abrahamsson    email: [hidden email]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[hidden email]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC 4861 missing updated-by

Ole Troan-2
Mikael,

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

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

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

signature.asc (859 bytes) Download Attachment
123
Loading...