ietf
[Top] [All Lists]

Gen-art review of draft-ietf-dhc-dhcpv4-vendor-message-01

2010-02-05 09:07:23
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-dhcpv4-vendor-message-01.txt
Reviewer: Elwyn Davies
Review Date: 5 February 2010
IETF LC End Date: 17 February 2010
IESG Telechat date: (if known) -

Summary: Almost ready. I note that (AFAICS) the existing DHCPv4 standards do not specify the behaviour of clients and servers receiving message types that they do not understand. Several new message types have been defined since RFCs 2131 and 2132 were published. These standards and this document tacitly assume that reception of these new message types by existing clients or servers will not cause damage (relays should just forward them without problem).

Major issues:
None

Minor issues:

s3, para 3: This paragraph contains weasel words about 'good networking practices' that 'MUST be used'. This is untestable as it stands. Is this anything more than dealing with non-replies, not flooding the network with repeats and not hanging up if the partner never does answer? Also, as observed above, servers or clients that do not (yet) implement this capability do not have a defined behaviour when receiving this new type of message. There is a tacit assumption that they will be silently dropped without causing any problems.

s7 and s4, next to last para: s4 specifies RFC 3396 as 'MUST support' This makes RFC 3396 a normative reference, not informative. Arguably the last para of s4 makes RFC 3925 normative as well.

Nits/editorial comments:
s4, top of page 5: 'Option codes 0 and 255 have no pre-defined interpretation or format': This comment (duplicated from RFC 3925) is confusing to the uninitiated reader. If I understand correctly, this is intended to contrast with the 'basic' options in DHCPv4 where options 0 and 255 are 'special' - i.e. no length code. I suggest adding at the beginning of the sentence: 'Unlike option codes in DHCPv4 [RFC2131], option codes 0...'.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Gen-art review of draft-ietf-dhc-dhcpv4-vendor-message-01, Elwyn Davies <=