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 steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) (was Discuss) No Objection

No Objection (2005-05-12)
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 steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) (was Discuss) No Objection

No Objection (2005-05-13)
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 steering group member) (was Discuss) No Objection

No Objection (2005-05-12)

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2005-05-09)
  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 steering group member) No Objection

No Objection (2005-05-08)
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 steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2005-05-10)
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.