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...'.