IP Version 6 Addressing Architecture
draft-ietf-ipv6-addr-arch-v4-04
Yes
(Margaret Cullen)
(Sam Hartman)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(Brian Carpenter)
(David Kessens)
(Jon Peterson)
(Mark Townsley)
Abstain
Recuse
Note: This ballot was opened for revision 04 and is now closed.
Margaret Cullen Former IESG member
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2005-05-11)
Unknown
Please remove the reference ([IPV6]) from the Abstract. In section 2.5: s/pervious paragraphs/previous paragraphs/
Scott Hollenbeck Former IESG member
Abstain
Abstain
(2005-05-10)
Unknown
Maybe I'm just confused, but there seem to be some changes in RFC 3513 and this draft that can't have been addressed in the interop report, which was written for RFC 2373. For example, Section 2.7 of 2373 says: scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 1 node-local scope 2 link-local scope 3 (unassigned) 4 (unassigned) Section 2.7 of this draft says: scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 1 interface-local scope 2 link-local scope 3 reserved 4 admin-local scope ... and "admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration." I don't understand how value 4 can go from being unassigned to having a specific meaning and a configuration requirement without there being an implementation impact that would need to be described in an updated interop report. Howevere, given that the IESG has approved 3513 in the past I'll just note this observation and abstain.
Ted Hardie Former IESG member
Recuse
Recuse
(2005-05-10)
Unknown
I was serving on the IAB when this document: http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html was issued. I believe that this makes it appropriate for me to recuse here.