The DHCPv4 Relay Agent Identifier Sub-Option
draft-ietf-dhc-relay-id-suboption-13

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

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-02-22)
No email
send info
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"

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-01-09 for -11)
No email
send info
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;

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2013-01-06 for -11)
No email
send info
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.

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-01-15 for -12)
No email
send info
Thanks for handling my discuss and comments, I've cleared.

S.

(Brian Haberman) No Objection

Comment (2013-01-03 for -11)
No email
send info
I would suggest the following substitution in the Introduction:

s/Relay Agent Identifier suboption/Relay Agent Identifier (Relay-Id) suboption/

(Russ Housley) No Objection

Barry Leiba No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-01-07 for -11)
No email
send info
I support both Stewart's and Stephen's discuss positions.