Re: [dhcwg] draft-ietf-dhc-csr-05.txt

[Ted Lemon <[e-mail]>]

> NIT: The term "classed" (as in classed routing) isn't the common one,
> I think. "classful" is more common.

Classful is not a common english word, so I'm reluctant to use it in
an RFC, even if it's common in the vernacular of network
administrators.  I could change it to "class-based", but I think
"classed" conveys the meaning, plus it's a real word, so my
inclination is to keep it.  I can't see how this can create confusion
- the relevant RFCs are referenced, and a brief definition of the term
is given.

> Is the term "broadcast domain" the common terminology? I.e, in IPv6,
> one would say "multiple subnets on the same link". In IPv4, one might
> say "multiple subnets on the same physical network" or something else,
> I think. What terminology do other RFCs use (I'm pretty sure this is
> described somewhere)? It would be better to be consistent.

I like the term "link", but as you say, it's not in common usage for
IPv4.   Physical network has the problem that it's not very
descriptive - what precisely is a physical network?

I've added the following definition:

      "link"

      	   Any set of all network attachment points that will recieve
	   a link-layer broadcast sent on any one of the attachment
	   points.  This term is used in DHCP because in some cases
	   more than one IP subnet may be configured on a link.  DHCP
	   uses a local-network (all-ones) broadcast, which is not
	   subnet-specific, and will therefore reach all nodes
	   connected to the link, regardless of the IP subnet or
	   subnets on which they are configured.

	   A "link" is sometimes referred to as a broadcast domain or
	   physical network segment.

...and I've adjusted the cases where the term "broadcast domain" is
used to use "link" instead.

> Presumably they already ignore the option per existing RFCs? I.e, it
> seems odd to make it a requirement of *this* spec to specify behavior
> on an implementation that "does not support" the option...

I just copied that.   It makes a certain amount of sense to say it -
some implementations of DHCP clients log errors if they receive
unknown options.   Obviously this draft is not the place to fix that
problem, but I don't think this wording causes any problems.

> seems like MUST is too strong, and SHOULD would suffice. I.e, it might
> be that a client understands the option, but doesn't actually want the
> DHCP server to return such an option because it will ignore it or
> something.

The wording here has been changed per Stuart Cheshire's request.   His
concern was that the current wording meant his client had to stop
supporting the Static Routes option (which was my intention).   So
this is no longer recommended.

> Why this SHOULD? I.e., if it is not a MUST, the server can't count on
> this being the case, so what is the benefit?

True.   Stuart pointed this out as well.   It is now a MUST:

   The Classless Static Routes option code MUST appear in the
   parameter request list prior to both the Router option code and the
   Static Routes option code, if present.

> My personal preference would be to allow extra the bits. It's not that
> uncommon to provide a host address and a netmask to indicate a subnet
> number. I.e., it's work to figure out which bits should be chopped off
> and to actually set them to zero.

Okay, I've changed the wording to read as follows:

   After deriving a subnet number and subnet mask from each
   destination descriptor, the DHCP client MUST set any bits in the
   subnet number that are zero in the subnet mask to zero.  For
   example, if the server sends a route with a destination of
   129.210.177.132 (hexadecimal 81D4B184) and a subnet mask of
   255.255.255.128 (hexadecimal FFFFFF80), the client will install a
   route with a destination of 129.210.177.128 (hexadecimal
   81D4B180).

> This text could use a bit of tweaking. Note that whether an
> implementation supports reassembly isn't relevant.

I've reworded it a bit (partially at Stuart's request):

   Because a full routing table can be quite large, the standard 576
   octet maximum size for a DHCP message may be too short to contain
   some legitimate Classless Static Route options.  Because of this,
   clients implementing the Classless Static Route option SHOULD send
   a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP
   stack is capable of reassembling fragmented IP datagrams.  In this
   case, the client SHOULD set the value of this option to at least
   the MTU of the interface that the client is configuring.   The
   client MAY set the value of this option higher, up to the size of
   the largest UDP packet it is prepared to accept. (Note that the
   value specified in the Maximum DHCP Message Size option is the
   total maximum packet size, including IP and UDP headers.)

> Seems like MAY should be SHOULD. There is no reason to include it in
> this case. Right?

Okay.   I'd already changed the wording somewhat at Stuart's request -
this represents a somewhat larger change, which Stuart may wish to
contest:

   When a DHCP client requests the Classless Static Routes option and
   also requests either or both of the Router option and the Static
   Routes option, and the DHCP server is sending Classless Static
   Routes options to that client, the server SHOULD NOT include the
   Router or Static Routes options.

> Needs an IANA considerations section so that IANA knows to assign a
> code point.

Okay:

IANA Considerations

   This DHCP option will require the allocation of an option code in
   the list DHCP option codes that the IANA maintains.

Thanks for all the comments!


			       _MelloN_

_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg