IANA Considerations for the IPv4 and IPv6 Router Alert Options
draft-manner-router-alert-iana-03

Note: This ballot was opened for revision 03 and is now closed.

Lars Eggert Yes

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/

(Jari Arkko; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

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 steering group member) No Objection

(Pasi Eronen; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection

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