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

[Parviz Yegani <[e-mail]>]

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