[dhcwg] draft-ietf-dhc-concat-01.txt

Given that draft-aboba-dhc-domsearch-06.txt needs this document, I
went ahead and had a look at it. Here are my comments.

Thomas

Major issue:

The document goes to great lengths to NOT make existing
clients/servers out of spec with this ID. This seems misguided. Most
RFCs define new behavior. That existing implementations don't follow
the RFC is not a problem. Indeed, the goal is to make sure all future
implementations (or updates to existing implementations) adhere to the
new spec. But the current document includes language that seems to
suggest existing implementations are already compliant, hence they
need not be updated. In that case, what is the point of doing this?

I cite a number of wording issues below, that have to do with this
issue. I.e., the document should make it clear what the desired
wording should be, rather than trying to just encourage the behavior
while still (from a requirements perspective) saying it's not really
required.

Detailed comments:

The document should say in the introduction that it updates RFC XXX
(the base DHCP spec).

     We specify here an ordering that can be used by DHCP protocol
s/an ordering that can be/the ordering that must be/

or "is to be". I.e, this document is defining what is to be
done. Saying "can be" makes it sound like an option.

     bytes.  DHCP protocol agents MAY use the ordering described here
     to encode existing options if such options exceed 255 bytes in
     length.  The main purpose of this specification, however, is to
     provide a specification that new DHCP option drafts can
     reference.

I think the MAY above is wrong. The purpose of this spec is to define
what the right thing to do is here. Most RFCs define new behavior that
existing deployments don't support. That is not a problem.

I am also confused that the purpose is only for new options. This
should clarify/fix ambiguities in previous specs, where it is not
sufficently well defined what clients and servers do. Presumably,
there are already resultant interoperability problems due to these
ambiguities.

>	allowing the client to rendesvous with DHCP servers, and so

spelling

>      In this document, the key words "MAY", "MUST, "MUST NOT",
>      "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
>      interpreted as described in [3].

I think "optional" and "recommended" should be capitalized above; the
lower case versions are not defined in 2119.

>      space in another output buffer for the rest.  DHCP protocol
>      agents encoding an option in this case MAY use the algorithm
>      specified here.

MAY->MUST

>      The rationale for making this optional is that existing
>      implementations have not been subject to a requirement to encode
>      or decode options in this way, and it is not our intention to
>      potentially cause existing implementations to be in violation of
>      this specification.

I understand the desire, but I strongly disagree with it. What is the
harm in making existing implementations non-conforming to this spec?
There are lots of specs that implementations don't conform to. The
goal here is to get everyone to do the Right Thing.

>      This behaviour only applies in cases where this specification is
>      applicable, as previously defined in the Applicability section.

A bit repetitive. The entire document is optional, so anything in it
applies only if an implementation is attempting to conform to
it. 

>      DHCP options can be stored in the DHCP packet in three seperate
>      portions of the packet.   These are the optional parameters
>      field, the sname field, and the file field, as described in [1].
>      This complicates the description of the option splitting
>      mechanism because there are three seperate buffers into which
>      split options may be stored.

Here you are using slightly different terminology than in the
definition of "option overload" at the beginning of the document. It
would be better to be consistent. Indeed, can't this text just be
merged with the earlier definition? I think this would clarify the
document, as the applicability section talks about the three buffers
without having provided all the context (i.e, the description that
comes here).

>      Options MUST NOT be stored in the aggregate option buffer in such
>      in such a way that they cross either boundary between the three
>      fields in the aggregate buffer.

Is this MUST NOT new language, or is this already a requirement from
the base DHCP spec? (I would assume the latter.) If this requirement
comes from elsewhere, it would be better to say something like:

      Options must not be stored in the aggregate option buffer ... as
      described in [RFC XXX].

also, s/stored/placed/ ??

>      Encoding agents MAY split options as described in this
>      specification.   Encoding agents supporting options that require
>      this MUST split options as described here, if it is necessary to
>      do so in order to encode the entire contents of the option.

Seems redundant, and MAY doesn't seem what is needed.

>     Options MAY be split on any octet boundary.  No split portion of

Use of MAY here seems wrong. The definition of MAY in 2119 says:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

What other choice is there except to split on an octet boundary?
Better to say something like "Options can only be split on ..."

>      The split portions of the option MUST be stored in the aggregate
>      option buffer in sequential order - the first split portion MUST
>      be stored first in the aggregate option buffer, then the second
>      portion, and so on.

The above language seems to suggest that all of the BOOTP buffers must
be used. Is an implementation required to do this? I.e., is this
defining a new requirement? Can't an implementation leave (say) sname
empty but use other fields? (I really don't know, so this is really a
question.)

>      When a decoding agent is scanning an incoming DHCP packet's
>      option buffer and finds two or more options with the same option
>      code, it MAY consider them to be a split option as described
>      here.  Decoding agents that support options that require the

MAY->MUST

Question: is there any existing DHCP option that can appear more than
once, where the concatenating the two options results in different
behavior than having the option appear twice? (I would assume not.)

>      behaviour.   The decoding agent MUST ensure that when the
>      option's value is used, any alignment issues that are particular
>      to the machine architecture on which the decoding agent is
>      running are accounted for - there is no requirement that the
>      encoding agent align the options in any particular way.

This above MUST language seems to be about an implementation issue
that wouldn't normally be a protocol issue. This doesn't seem like it
should be a *required* part of the spec. It would be fine to give
advice to implementors to not do something dumb here.

>      Consider an option, option 224, with a value of "isc.org.".
>      Normally, this would be encoded as a single option, as follows:

I think it would be better to use a real example (224 is out of
private space). Or, add text saying that the contents of the option
doesn't matter, since the operation of splitting an concatenating
options takes place assuming the contents of the option value are
opaque.

> Security Considerations
> 
>      DHCP currently provides no authentication or security mechanisms.
>      Potential exposures to attack are discussed in section 7 of the DHCP
>      protocol specification [1]. The Classless Static Routes option can
>      be used to misdirect network traffic by providing incorrect IP
>      addresses for routers.

The purpose of a security considerations section is to discuss issues
related to the topic of the document itself.  I think it would be more
appropriate to say, that this document raises no new issues that are
not already present in DHCP (assuming this is actually correct!) and
then site the relevant docs as you do.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg