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

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

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

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

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.


- 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