Special Use IPv4 Addresses
RFC 5735

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

(Jari Arkko) Yes

(Ron Bonica) Yes

(Russ Housley) Yes

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-08-06 for -)
No email
send info
In the last paragraph of section 3, for clarity:

OLD:

   The one exception to this is the "limited broadcast" destination 
   address 255.255.255.255.  As described in [RFC0919] and [RFC0922], 
   packets with this destination address are not forwarded at IP layer. 

NEW:

   The one exception to the designation of 240.0.0.0/4 as reserver
   is the "limited broadcast" destination 
   address 255.255.255.255.  As described in [RFC0919] and [RFC0922], 
   packets with this destination address are not forwarded at IP layer.

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2009-08-11)
No email
send info
Section 3., paragraph 7:
>    documentation.  As described in [TBD-REF-IANA-IPV4-EXAMPLES],

  Missing Reference: 'TBD-REF-IANA-IPV4-EXAMPLES' is mentioned on line
  180, but not defined


Section 9.2., paragraph 10:
>    [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
>               Names", BCP 32, RFC 2606, June 1999.

  Unused Reference: 'RFC2606' is defined on line 324, but no explicit
  reference was found in the text


Section 9.2., paragraph 16:
>    [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
>               April 2008.

  Unused Reference: 'RFC5156' is defined on line 345, but no explicit
  reference was found in the text

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2009-08-11 for -)
No email
send info
Lars' DISCUSS is a superset of mine, so I've cleared.

(Tim Polk) No Objection

Comment (2009-08-12 for -)
No email
send info
I support Adrian's discuss issue regarding  the use of "do not" and "cannot".

I wonder if it could be resolved by the following change:
OLD
    addresses within this block do not appear on the public Internet.  
NEW
    addresses within this block do not legitimately appear on the public Internet.  

For me, the word "legitimately" clarifies that it can happen, but that it is either
a mistake or an attack.

This change, or some other like it, needs to occur in five places in section 3.

(Dan Romascanu) No Objection

Comment (2009-08-11 for -)
No email
send info
In Section 7 - 'if you expect (for instance) that all packets from a
   private address space such as the 10.0.0.0/8 block or the link local
   block 169.254.0.0/16 originate within your subnet, all routers at the
   border of your network should filter such packets that originate from
   outside your network.'

I believe the 'should' in this phrase needs to be capitalized 'SHOULD', which would also be consistent with the 'SHOULD NOT' in the following paragraph o fthe same section.

(Robert Sparks) No Objection