Special Use IPv4 Addresses
draft-vegoda-cotton-rfc5735bis-03
Discuss
Yes
(Russ Housley)
No Objection
(Robert Sparks)
(Wesley Eddy)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Barry Leiba Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2012-08-29)
Unknown
At the risk of having this be a "piling-on" DISCUSS, I'll use DISCUSS rather than NO OBJECTION in order to make a concrete suggestion. Basically, this is supporting Brian's and Pete's DISCUSS positions. Currently, this document specifies a bunch of address ranges, which includes 192.0.0.0/24. The "IANA IPv4 Special Purpose Address Registry" ( http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml ) sub-allocates that 192.0.0.0/24 block. I suggest that this document do the following: - Add a new registry to the "Internet Protocol version 4 (IPv4) Address Space" group. Call it "IANA Special Use IPv4 Address Blocks". - Make the allocation policy for the new registry be "IETF Review or IESG Approval." - Make the new registry have two sections, "Summary Table" and "Details". - Populate the "Summary Table" section with the contents of Section 3 of this document. - Populate the "Details" section with the contents of Section 2 of this document. - Change one paragraph in the "Details" section as follows: OLD 192.0.0.0/24 - This block is reserved for IETF protocol assignments. At the time of writing this document, there are no current assignments. Allocation policy for future assignments is given in [RFC5736]. NEW 192.0.0.0/24 - This block is reserved for IETF protocol assignments. Current assignments are in the "IPv4 Special Purpose Address Registry". Allocation policy for future assignments is given in [RFC5736]. [Note that this last bit is a DISCUSS-level error in this document anyway.]
Brian Haberman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2012-08-23)
Unknown
Thank you for a very concise and easy to read document. I only have two points that I think warrant some discussion... 1. The corresponding RFC for the IPv6 space is RFC 5156. It contains a specific discussion of ::/0, the default route. It would be good to have a definitive statement for IPv4's default route 0.0.0.0/0. 2. Is there a reason why this draft does not specify that these addresses should appear in the IANA Special Purpose Address Registry? It would seem that we need to ensure that the registry reflects the special purpose addresses allocated within IPv4, and it currently does not.
Pete Resnick Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2012-08-28)
Unknown
I wish to support and amplify Brian's DISCUSS point #2: Why are the contents of this document necessary at all? Why is not all of this information in the !Pv4 Special Use Registry and this document simply populates that registry? I would think that the idea of a such a registry is so that we don't have to republish documents like this every so often.
Russ Housley Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-08-29)
Unknown
I think enough people have made the point and when their Discusses have been addressed I will not have any further issues.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2012-08-17)
Unknown
Two things: - It would be good to add a sentence in the intro why it this draft is updating RFC 6441, simply ensuring that the reader refers back to RFC 6441. - Why has the reoccuring sentence "RFC, addresses within this block do not legitimately appear the" lost the 'on'? The update sentence does not parse well, at least not for me.
Ralph Droms Former IESG member
No Objection
No Objection
(2012-08-28)
Unknown
I agree with the Discuss position suggesting this document should be populating an IANA registry. I'll allow Brian and Pete to resolve the issue.
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2012-08-29)
Unknown
Supporting Brian's DISCUSS
Sean Turner Former IESG member
No Objection
No Objection
(2012-08-27)
Unknown
So this might be style thing, but since this document is obsoleting another document which obsoleted another document would it be better to retain Appendix A from RFC 5375 and just add an Appendix B which lists the differences between 5375 and this draft? That way the trail of changes is kept?
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-08-27)
Unknown
- typo: assignmnets - the word "on" has disappeared from the description of 172.16/12 and of 192.168/16 - the word "to" has appeared in the description of 192.88.99/24
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-08-28)
Unknown
I would make this a Discuss, but I am sure that Pete will ably prosecute the point. I do not understand why we are publishing an evolving set of RFCs to fulfill the function of a code-point registry.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown