Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB
draft-ietf-dhc-server-mib-10
Discuss
Yes
(Margaret Cullen)
No Objection
(Alex Zinin)
(David Kessens)
(Jon Peterson)
(Ned Freed)
(Ted Hardie)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Bert Wijnen Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-04-06)
Unknown
Extensive MIB Doctor comments have been posted to the DHC WG mailing list. These need to be addressed or answered first.
Bill Fenner Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-02-18)
Unknown
I think there's a size mismatch between the display-hint and the size:
Dhcpv4PhysicalAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d,1d,1x:1x:1x:1x:1x:1x"
SYNTAX OCTET STRING (SIZE(18))
Is this supposed to be 8, or 8..18, or something else?
dhcpv4ServerClientPhysicalAddress is a Dhcpv4PhysicalAddress, but says "This object MAY be empty if the address has not been previously served." The SYNTAX of Dhcpv4PhysicalAddress does not permit it to be empty; should the size be 0|8 or 0|8..18 or something else?
In the DESCRIPTION of dhcpv4ServerSystemObjectID, it uses a sample enterprise ID of 4242, which is assigned to the Clorox Company. I don't know if this is significant.
Russ Housley Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2005-06-16)
Unknown
The Abstract says: > > This memo defines an experimental portion of the Management > Information Base (MIB) ... > However, this document is on the agenda for Standards-Track. I am also picking up Steve Bellovin's DISCUSS comment. Steve said: Dhcpv4ServerClientEntry strikes me as very sensitive, especially from a privacy perspective.
Steven Bellovin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-02-17)
Unknown
Dhcpv4ServerClientEntry strikes me as very sensitive, especially from a privacy perspective.
Margaret Cullen Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-04-01)
Unknown
Comments from Lucy Lynch, GEN-ART reviewer, available at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dhc-server-mib-10-lynch.txt Comments from Spencer Dawkins, GEN-ART reviewer, available at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dhc-server-mib-10-dawkins.txt
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
(2004-03-12)
Unknown
Section 5 might need to be removed/replaced now that the new BCP 79 IPR stuff has recently been published.
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Record
No Record
(2004-02-19)
Unknown
Looks like the DHC/bootp content was carefully reviewed. It's a good thing that none of the objects are writeable. One editorial comment, under the object dhcpv4ClientServerAllowedProtocol, this phrase:
A type of bootp-or-dhcp (4) can be
offered to any type of client.
makes the object sound like a client-notifying object. It should be re-written so it has parallel structure to 1, 2, and 3.