Skip to main content

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