Special-Purpose IP Address Registries
RFC 6890
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
I support the publication of this document, but I have two small issues
that may just be questions of my understanding, or might need a tweak to
the text.
---
The name of the registry field "Reserved" is likely to cause some
confusion since the word has special meaning in most registries. Can I
suggest "Special" or similar?
---
If the value of "Fowradable" is FALSE, can the value of "Reserved" be
TRUE? From the text description of "Reserved" it would appear not, but
from Table 1 it would appear so. The issue comes from the text that says
This value is "TRUE" if
the RFC that created the special-purpose address block requires
all compliant IP implementations to behave in a special way when
forwarding packets either to or from addresses contained by the
address block.
You can't behave in a special way when forwarding packet if you are not
allowed to forward packets.
(Barry Leiba; former steering group member) Yes
(Benoît Claise; former steering group member) Yes
One correction though. "IETF Review [RFC 5226]" is the proper wording, which should be added OLD: IANA will update the aforementioned registries as requested in the "IANA Considerations" section of an IETF reviewed document. The "IANA Considerations" section must include all of the information specified in Section 2.1 of this document. NEW New assignments in the registries require IETF Review [RFC 5226]. IANA will update the aforementioned registries as requested in the "IANA Considerations" section of the IETF reviewed document. The "IANA Considerations" section must include all of the information specified in Section 2.1 of this document. Editorial: OLD o RFC - The RFC though which the special-purpose address block was requested NEW o RFC - The RFC through which the special-purpose address block was requested
(Pete Resnick; former steering group member) Yes
The question of whether this should obsolete (instead of update) 5736 was not yet addressed. Given that I am agnostic on this issue, I'll leave my ballot as "Yes", but I think someone should make an explicit call on this. (Ralph?)
(Ralph Droms; former steering group member) Yes
(Robert Sparks; former steering group member) Yes
(Sean Turner; former steering group member) Yes
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
It was agreed on the IESG call that footnote would be added to table 4 to deal with the following issue: The purpose of this discuss is to discuss whether we need to note in this RFC that - contra to the notes in table 4 - 127/8 addresses are used as addresses for some types of packets in tunnels (precisely because they are addresses that cannot legitimately exist outside a host and the packets are automatically killed if they escape from the tunnel and into the wild).
(Wesley Eddy; former steering group member) No Objection
(Brian Haberman; former steering group member) Recuse
(Ron Bonica; former steering group member) Recuse