Skip to main content

Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
RFC 4361

Yes

(Margaret Cullen)

No Objection

(Alex Zinin)
(Allison Mankin)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Mark Townsley)
(Scott Hollenbeck)

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

Margaret Cullen Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
(was Discuss) No Objection
No Objection (2005-05-12) Unknown
Mmm... I see citations in the abstract. My understanding is that
those are not allowed. Easy to fix, just use perenthesis instead
of square brackets.
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
(was Discuss) No Objection
No Objection (2005-05-13) Unknown
I expected to find some words in the Applicability section stating what happens when a client following this spec meets a server that doesn't, or vice versa. Actually, in the Requirements section the new server/old client case is very explicit on page 4. The new client/old server case is hard to disentangle from the page 4/5 text. A very simple sentence can resolve that for the rapid reader. (I'm not concerned about implementers, but rather about operations people planning client or server upgrades; they need to know it's OK to mix and match.)
David Kessens Former IESG member
(was Discuss) No Objection
No Objection (2005-05-12) Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2005-05-09) Unknown
  Section 2.4 says:
  >
  > Like the client identifier format recommended by RFC2131, this
  > suffers from the problems previously described in (2) and (3).
  >
  Section numbers are needed to refer to the previous problems.
Sam Hartman Former IESG member
No Objection
No Objection (2005-05-08) Unknown
I didn't find this document particularly clear it seemed harder to
follow than it should be.  I think that's probably because it is a set
of diffs to other behavior and has too many references to stand on its
own.  However I did eventually follow it and I don't think anything I
found should block publication at this stage.
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2005-05-10) Unknown
The document's IANA considerations says:

This document deprecates all 'client
   identifier' type codes other than 255, and thus there is no need
   for the IANA to track additional possible values for the type field
   of the 'client identifier' option.

I got a bit confused about whether any values registered in this:
http://www.iana.org/assignments/bootp-dhcp-parameters

are deprecated, or this only deprecates further registration.  A
clarification may be in order.