The DHCPv4 Relay Agent Identifier Sub-Option
RFC 6925

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

(Ralph Droms; former steering group member) Yes

Yes ( for -11)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (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.

(Barry Leiba; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (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;

(Brian Haberman; former steering group member) No Objection

No Objection (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/

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Sean Turner; former steering group member) No Objection

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

(Stephen Farrell; former steering group member) (was Discuss) No Objection

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

S.

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (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"

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -11)
No email
send info