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

Elwyn Davies <elwynd@dial.pipex.com> Fri, 05 February 2010 15:05 UTC

Message-ID: <4B6C33D1.90905@dial.pipex.com>
Date: Fri, 05 Feb 2010 15:05:53 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: General Area Reviwing Team <gen-art@ietf.org>
Subject: Gen-art review of draft-ietf-dhc-dhcpv4-vendor-message-01
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dhc-dhcpv4-vendor-message.all@tools.ietf.org, IETF Discussion Mailing List <ietf@ietf.org>
Precedence: list

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

Gen-art review of draft-ietf-dhc-dhcpv4-vendor-me… Elwyn Davies