Special-Purpose IP Address Registries
draft-bonica-special-purpose-07
Yes
(Barry Leiba)
(Ralph Droms)
(Robert Sparks)
(Sean Turner)
No Objection
(Gonzalo Camarillo)
(Martin Stiemerling)
(Russ Housley)
(Stephen Farrell)
(Wesley Eddy)
Recuse
(Brian Haberman)
(Ron Bonica)
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-01-09 for -05)
Unknown
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 IESG member
Yes
Yes
(for -05)
Unknown
Benoît Claise Former IESG member
Yes
Yes
(2013-01-09 for -05)
Unknown
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 IESG member
Yes
Yes
(2013-01-08 for -05)
Unknown
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 IESG member
Yes
Yes
(for -03)
Unknown
Robert Sparks Former IESG member
Yes
Yes
(for -05)
Unknown
Sean Turner Former IESG member
Yes
Yes
(for -05)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2013-01-10 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
Recuse
Recuse
(for -04)
Unknown
Ron Bonica Former IESG member
Recuse
Recuse
(for -04)
Unknown