Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
RFC 3993

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

(Harald Alvestrand) No Objection

Comment (2004-08-19 for -)
No email
send info
Reviewed by Mark Allman, Gen-ART

(Steven Bellovin) No Objection

Comment (2004-03-11 for -)
No email
send info
I'm not sure if this should be a DISCUSS or not...  Are there any theft of service issues if a malicious party generates this option?  I suspect that Section 4 should add some text saying that subscriberid-generating relay hosts SHOULD (or MUST) delete this option if it appears in an incoming request.

(Margaret Cullen) (was Discuss, Yes) No Objection

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-03-12 for -)
No email
send info
Section 3.1 describes the suboption format with fields described in byte increments.  While most "power of two"-bit hardware architectures today use 8-bit bytes, it is far safer to describe values in quantities of octets if 8-bit fields are being used because there are some older hardware architectures that use non-8-bit bytes.

(Russ Housley) No Objection

Comment (2004-08-17 for -)
No email
send info
  In section 6: s/IPSEC/IPsec/

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2004-08-19 for -)
No email
send info
An AAA-doctor reviewed this and has a question:

  This document looks good. One question: There seems to be a
  growing number of identifiers (client-id etc) for users in
  the DHCP space. Is there some rule set to determine which of
  the attributes and in which order are used when, say,
  determining if the same or different IP address should be
  handed to the client? For instance, if the client-id has
  changed but the subscriber ID stays the same, what do you
  do? Or is this all left to policy?

Do we have an answer?