IANA Considerations for the IPv4 and IPv6 Router Alert Options
draft-manner-router-alert-iana-03
Yes
(Jari Arkko)
No Objection
(Chris Newman)
(Cullen Jennings)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 03 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Lars Eggert Former IESG member
Yes
Yes
(2008-08-11)
Unknown
This document is still phrased as if it were a proposal, rather than the RFC that changes IANA procedures. Below are some suggested changes to fix that. Section 1., paragraph 4: > This document proposes updates to the IANA registry for managing IPv4 > and IPv6 Router Alert Option Values, and proposes to remove one s/proposes updates to/updates/ s/proposes to remove/removes/ Section 3., paragraph 1: > This section contains the proposed new procedures for managing IPv4 s/proposed// Section 3., paragraph 3: > This should not change, as there has been seen little s/This should not change/This document does not change this/ s/has been seen/is/ Section 3.2., paragraph 1: > The registry for IPv6 Router Alert Option Values should continue to s/should continue/continues/ Section 3.2., paragraph 2: > In addition, the following value should be removed from the IANA s/should be removed/are removed/ Section 3.2., paragraph 5: > The following IPv6 RAO values should be made available for s/should be made/are made/
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2008-08-12)
Unknown
Although a full alignment for values in the IPv4 and IPv6 registries is no longer possible because of the initial allocations, would not it be useful to make a recommendation for alligned allocation from now on? This would mean to mark as 'not in use' values 33, 34, 35 in the IPv4 registry and to recommend that values 36-65502 and these in the experimental space are allocated similarly.
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-08-12)
Unknown
While I have no problem with the security considerations as stated (and in fact believe the reference to problems from conflicts or lack of support for experimental code points to be valuable), I was wondering if there had been a response to Robert Elz's comments (from 7/10/08, submitted to ietf@ietf.org).