RE: [dhcwg] dhc WG last call ondraft-ietf-dhc-bcmcv{4, 6}-option-??.txt

["Bernie Volz" <[e-mail]>]

The example you gave in the response to Ted is the SIP RFCs. Those aren't a
good example because the work on these started way before DHCPv6 was an RFC.
There was a very good reason to separate them because the DHCPv4 work would
likely not have been approved as DHCPv6 wasn't stable yet (no RFC 3315).

I think if we look at the historical perspective, there are very few option
drafts that could have been combined DHCPv4 and DHCPv6 options because the
DHCPv4 work would have been held up unnecessarily. And, some of the ones
that MIGHT now be combinable, were started long before RFC 3315 existed.

For example, we could ask why not merge the DHCPv4 and DHCPv6 Client FQDN
drafts that I'm working on and this could indeed be done. But, there is less
benefit here as the processing is different in many ways and the combined
draft would likely only be 25% less words (excluding the IETF boilerplate
material).

Your options are fairly simple configuration parameters that don't have
complex logic and processing associated with them. In each case it is simply
that a client includes the option(s) in the list of options (Parameter List
or ORO) it requests from the server and the server returns the option if
configured.

But, it is your choice as to how you want to proceed (neither approach is
wrong).

- Bernie

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Parviz Yegani
> Sent: Friday, February 11, 2005 1:10 PM
> To: Bernie Volz
> Cc: [e-mail]; [e-mail]; 'Ted 
> Lemon'; [e-mail]; 'Ralph Droms'
> Subject: RE: [dhcwg] dhc WG last call 
> ondraft-ietf-dhc-bcmcv{4,6}-option-??.txt
> 
> 
> Hi Bernie,
> 
> Thanks for your detailed comments. Please see my comments below...
> 
> At 02:49 PM 2/10/2005 -0500, Bernie Volz wrote:
> > >Why not just have one draft?
> >
> >Yes, great recommendation. I've always liked this concept, 
> especially 
> >when the options and related processing are essentially the same.
> 
> Please see my reply to Ed in my previous posting to this list.
> 
> 
> > > Regarding the bcmcv4 draft, the enc byte needs to go.
> >
> >Agreed. But, you don't indicate how the two forms of data are to be 
> >represented. Having the ability to specify address is 
> important if the 
> >devices using this option might be limited in terms of the 
> size of the 
> >code they can support.
> 
> We want to specify addresses, therefore, option 2 below is 
> not acceptable since carriers want that flexibility. We'll 
> update the draft to align it with the bcmcv6 draft and fix 
> the errors you pointed out. We might be okay to drop 
> compression. Will let the group know.
> 
> 
> >There are three possibilities:
> >1. Define two options as is done for DHCPv6.
> >2. Drop the ability to specify addresses. I can't see that 
> this would 
> >be a significant issue for users of this option. 3. Encode 
> the address 
> >as standard reverse DNS names (d.c.b.a.in-addr.arpa).
> >
> >Also, the current example in the DHCPv4 draft is wrong in several 
> >respects:
> >
> >        
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >        |TBD|38 | 5 |'b'|'c'|'m'|'c'|'1'| 8 
> |'c'|'a'|'r'|'r'|'i'|'e'|'r'|
> >        
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >        
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >        |'1'| 3 |'c'|'o'|'m'| 5 |'b'|'c'|'m'|'c'|'2'| 8 
> |'c'|'a'|'r'|'r'|
> >        
> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >        +---+---+---+---+---+---+---+---+
> >        |'i'|'e'|'r'|'1'| 3 |'c'|'o'|'m'|
> >        +---+---+---+---+---+---+---+---+
> >
> >1. The enc byte is not present (this is good since we'd like 
> to ditch 
> >it anyway).
> >
> >2. The domain names are encoded incorrectly. The domain name shown 
> >above would be: bcmc1.carrier1.com.bcmc2.carrier1.com. Not the two 
> >names as intended.
> >
> > >From RFC 1035, section 3.1:
> >
> >     Domain names in messages are expressed in terms of a 
> sequence of labels.
> >     Each label is represented as a one octet length field 
> followed by that
> >     number of octets.  Since every domain name ends with 
> the null label of
> >     the root, a domain name is terminated by a length byte 
> of zero.  The
> >     high order two bits of every length octet must be zero, and the
> >     remaining six bits of the length field limit the label 
> to 63 octets or
> >     less.
> >
> >So, the null labels are missing from the two domain names. 
> Of course, 
> >if compression is used, you'll have to follow the rules in section 
> >4.1.4 of RFC 1035.
> >
> >And, if compression is supported, don't we need to say that the 
> >compression is relative to the start of the OPTION data 
> rather than to 
> >the packet itself
> >- as is the case for DNS:
> >
> >     The OFFSET field specifies an offset from
> >     the start of the message (i.e., the first octet of the 
> ID field in the
> >     domain header).  A zero offset specifies the first byte 
> of the ID field,
> >     etc.
> >
> >I'm also a bit concerned with allowing compression, especially for 
> >DHCPv6, as section 8 of RFC 3315 explicitly PROHIBITS compression.
> >
> >
> >There problems need to be corrected before I'd recommend 
> advancing the 
> >work.
> 
> Thanks again,
> Parviz
> 
> 
> 
> >- Bernie
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On 
> > > Behalf Of Ted Lemon
> > > Sent: Thursday, February 10, 2005 2:08 PM
> > > To: Ralph Droms
> > > Cc: [e-mail]
> > > Subject: Re: [dhcwg] dhc WG last call on 
> > > draft-ietf-dhc-bcmcv{4,6}-option-??.txt
> > >
> > >
> > > I have a couple of comments.   First, given the process we've been
> > > going through to free up option codes, I don't think there's a 
> > > strong argument for making these drafts depend on the new 
> > > vendor-specific option encoding, by which I basically 
> mean I don't 
> > > care about this issue, and I don't think the wg needs to 
> care about 
> > > it.
> > >
> > > My main concern about these two drafts is that they are 
> two drafts.
> > > Why not just have one draft?   There's so much common text
> > > between them
> > > that it seems bogus.   In saying this, I realize that I 
> may well have
> > > argued the other way earlier - I don't remember the 
> history of these
> > > drafts very well.   So this isn't a big deal, but I am 
> curious if the
> > > authors can speak to this point.
> > >
> > > Regarding the bcmcv4 draft, the enc byte needs to go.   I
> > > don't see any
> > > reason for this added complexity.  Also, the draft specifies that 
> > > clients should support compression, which I think is right since 
> > > it's consistent with how the domain-name-search-list 
> option works, 
> > > but then
> > > the example that's given isn't compressed.   So this should
> > > be fixed -
> > > the example should be compressed.
> > >
> > > The text in the bcmcv6 draft is less specific, and the 
> examples are 
> > > extremely unspecific - I would suggest making them more like the 
> > > ones in the bcmcv4 draft if the two drafts can't just be merged.
> > >
> > > If the changes I've suggested can be made, I'd be in favor of 
> > > advancing
> > > these drafts separately.   I'd definitely be somewhat 
> happier if they
> > > were combined.
> > >
> > > _______________________________________________
> > > dhcwg mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/dhcwg
> > >
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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