Skip to main content

Special-Purpose IP Address Registries
RFC 6890

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

                            
Benoît Claise Former IESG member
Yes
Yes (2013-01-09 for -05)
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)
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)

                            
Robert Sparks Former IESG member
Yes
Yes (for -05)

                            
Sean Turner Former IESG member
Yes
Yes (for -05)

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05)

                            
Russ Housley Former IESG member
No Objection
No Objection (for -05)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -05)

                            
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2013-01-10 for -05)
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)

                            
Brian Haberman Former IESG member
Recuse
Recuse (for -04)

                            
Ron Bonica Former IESG member
Recuse
Recuse (for -04)