The DHCPv4 Relay Agent Identifier Sub-Option
draft-ietf-dhc-relay-id-suboption-13
Yes
(Ralph Droms)
No Objection
(Barry Leiba)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)
Note: This ballot was opened for revision 11 and is now closed.
Ralph Droms Former IESG member
Yes
Yes
(for -11)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-01-06 for -11)
Unknown
I have no objection to the publication of this document as an RFC, but I have some thoughts about ID uniqueness that I hope you will consider. These thoughts amount to support for Stewart's Discuss. --- I think you could enhance your document by discussing the uniqueness of the identifier more. While it is fine to require the operator to ensure uniqueness, I think some people may have fat fingers. That means that you should add a discussion of what happens if two relay agents show up with the same ID: can agents or servers detect it and report it? what might go wrong? I also wondered what the scope of an "administrative domain" really is? Furthermore, I wondered why we need yet another unique identifier. Can't the relay agent re-use an existing identifier or set of identifiers that are already guarateed to be unique-or-detectably-non-unique? Lastly, there seems to be an understated requirement for configuration of the ID. You give the reasoning as allowing substitution (which is a fine reason), but it seems to me that the stronge reason is ensuring uniqueness. --- Your document should refer to itself (e.g. in the Abstract) as a document or memo. An RFC that refers to itself as a draft would be confusing.
Barry Leiba Former IESG member
No Objection
No Objection
(for -11)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2013-01-09 for -11)
Unknown
I support Stewart's DISCUSS regarding the uniqueness. Note: http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ updates the ENTITY-MIB RFC4133 with a ready-only UUID OID - entPhysicalUUID. This might be handy for the uniqueness discussion. In terms of draft status, the write-up has just been submitted. Regards, Benoit;
Brian Haberman Former IESG member
No Objection
No Objection
(2013-01-03 for -11)
Unknown
I would suggest the following substitution in the Introduction: s/Relay Agent Identifier suboption/Relay Agent Identifier (Relay-Id) suboption/
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -11)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -11)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -11)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2013-01-07 for -11)
Unknown
I support both Stewart's and Stephen's discuss positions.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-01-15 for -12)
Unknown
Thanks for handling my discuss and comments, I've cleared. S.
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2013-02-22)
Unknown
With the new text this is much improved and than you for the work. I would however suggest that you do an RFC2119 scrub on the new text. For example "Administrators should take special care to ensure that relay-ids configured in their relay agents are not duplicated." That really should be "Administrators MUST.... Similarly in the Factory Floor case "In deployment scenarios like this one, administrators must use some dependable technique to ensure that such misconfigurations do not occur." That surely needs to be "MUST use"
Wesley Eddy Former IESG member
No Objection
No Objection
(for -11)
Unknown