Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-bcmcv4-option-00.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 09 Feb 2005 15:53:55 -0500

This message announces a WG last call on "DHCPv4 Options for Broadcast
and Multicast Control Servers" <draft-ietf-dhc-bcmcv4-option-00.txt>.
The last call will conclude at 1700EST on 2005-02-25.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Silence does not represent
positive support.  If there is no discussion, the document will not be
advanced to the IESG.

"DHCPv4 Options for Broadcast and Multicast Control Servers" defines
new options for Broadcast and Multicast Service controller discovery
in an IP network.  Broadcast service is being developed for 3G
wireless networks.  Users of the service interact with a controller in
the network to derive informations that are required to receive
broadcast service.  Dynamic Host Configuration Protocol can be used to
configure the controller IPv4 addresses or fully qualified domain
names in the user's devices.  This document defines the related
options and option codes..  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-bcmcv4-option-00.txt

- Ralph Droms 

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

---

From: Parviz Yegani <[email-masked]>
Date: Wed, 09 Feb 2005 16:14:22 -0800

At 03:53 PM 2/9/2005 -0500, Ralph Droms wrote:
>support for the document can be assessed.

Yes, the draft should be promoted to an RFC status as the proposed
options in this draft are used in the BCMCS specification currently
being standardized in various 3G standards bodies.

-Parviz

>Silence does not represent

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Feb 2005 11:08:23 -0800

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.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 10 Feb 2005 14:49:21 -0500

>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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Thursday, February 10, 2005 2:08 PM
> To: Ralph Droms
> Cc: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call on 
> draft-ietf-dhc-bcmcv{4,6}-option-??.txt
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Feb 2005 12:22:49 -0800

> 3. Encode the address as standard reverse DNS names 

Hm, actually I'm a big believer in just sending IP addresses.   Now 
that you mention it, is there some overarching concern that makes it 
better to send FQDNs in some cases and IP addresses in others?   We 
tend to try to stuff a lot of information into a DHCP packet, v4 or v6, 
so in general unless there's a strong reason to send a domain name, I'd 
suggest just sending the IP address.

This would simplify the client implementation quite substantially, 
since the implementor in IPv6 no longer has to deal with the 
possibility that the server might send both options, and no longer has 
to deal in the case of IPv4 with the possibility that the server might 
send an IP address or an FQDN.

---

From: Parviz Yegani <[email-masked]>
Date: Fri, 11 Feb 2005 09:44:54 -0800

Hello, Ted,

Thanks for the comments. Please see inline...

At 11:08 AM 2/10/2005 -0800, Ted Lemon wrote:
>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.
>

I don't think it's the first time we're defining protocol 
options/extensions for IPv4 & IPv6 in separate drafts. For example, options 
used for SIP servers are defined in separate RFCs 3319/3361. Why this 
should be any different?

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

No problem, we'll fix it.

>extremely unspecific - I would suggest making them more like the ones in 
>the bcmcv4 draft if the two drafts can't just be merged.

Fine. We'll add more details to align the two drafts.

>these drafts separately.   I'd definitely be somewhat happier if they were 
>combined.

We'd prefer not to merge them but we'll send an update with changes you 
suggested.

Thanks,
Parviz

---

From: Parviz Yegani <[email-masked]>
Date: Fri, 11 Feb 2005 10:10:29 -0800

Hi Bernie,

Thanks for your detailed comments. Please see my comments below...

>the options and related processing are essentially the same.

Please see my reply to Ed in my previous posting to this list.

>devices using this option might be limited in terms of the size of the code

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.

>Also, the current example in the DHCPv4 draft is wrong in several respects:

Thanks again,
Parviz

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 11 Feb 2005 13:45:10 -0500

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

> On Behalf Of Parviz Yegani
> Sent: Friday, February 11, 2005 1:10 PM
> To: Bernie Volz
> Cc: [email-masked]; [email-masked]; 'Ted 
> Lemon'; [email-masked]; 'Ralph Droms'
> Subject: RE: [dhcwg] dhc WG last call 
> ondraft-ietf-dhc-bcmcv{4,6}-option-??.txt
> 
> 
> Hi Bernie,
> 
> >Yes, great recommendation. I've always liked this concept, 
> especially 
> >when the options and related processing are essentially the same.
> 
> >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 
> >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).
> >
> >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.
> >
> >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
> >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
> >
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Ted Lemon
> > > 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.
> > >
> > > clients should support compression, which I think is right since 
> > > it's consistent with how the domain-name-search-list 
> option works, 
> > > but then
> > > extremely unspecific - I would suggest making them more like the 
> > > ones in the bcmcv4 draft if the two drafts can't just be merged.
> > >

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Feb 2005 11:23:55 -0800

> But, it is your choice as to how you want to proceed (neither approach 

I will point out that any suggestion for improvement that we make, the 
IESG is likely to suggest as well, unless our suggestion isn't at all 
sensible.   When the IESG makes suggestions during the final review 
process for a draft, it can delay the advancement of a draft.   So it 
is not necessarily most expedient to avoid the work of combining the 
two drafts if your goal is quick advancement.

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 14 Feb 2005 08:44:33 -0800

I support advancing the draft after addressing the issues 
listed below.

--Barr

General matters:

(Ralph) this is an example of an option that is being 
proposed for both DHCPv4 and DHCPv6.  Would it be good 
editorial policy to request that editors of option drafts in 
general follow the convention:

--use "DHCP" when something applies, without modification, 
to both DHCPv4 and DHCPv6, else
--use either "DHCPv4" or "DHCPv6" as appropriate?

Spelling and/or grammatical errors:

"Abstract:

"This document defines new options for Broadcast and 
Multicast Service controller discovery in an IP network. 
Broadcast service is being developed for 3G wireless 
networks.  Users of the service interact with a controller 
in the network to derive informations"

---"informations" should be "information"

"that are required to receive broadcast service.  Dynamic 
Host Configuration Protocol can be used to configure the 
controller"

---"controller" should be "controller's"

"IPv4 addresses or fully qualified domain names in the 
user's devices.  This document defines the related options 
and option codes."

"1.  Motivation

"Dynamic Host Configuration Protocol [RFC2131] can be used 
to configure various non-IP address type of parameters."

---change "various non-IP address type of parameters" to 
"various parameters"

"These parameters are required for normal operation of 
various services that are offered over an IP network.

"Broadcast and multicast service (BCMCS) is one such service 
that is currently being standardized in various mobile 
wireless standard bodies such as 3GPP, 3GPP2 and OMA.  A 
description of the BCMCS, for example, in 3GPP2 can be found 
in [BCMCS]."

---define the acronyms "3GPP," "3GPP2," and "OMA"

"DHCP is being used in 3GPP2, for example, to assist with 
the discovery of the BCMCS Controller in a mobile operators"

---change "operators" to "operator's"

"IP network.  The BCMCS includes a controller component that 
is responsible for managing the service via interaction with 
the users and other network entities."

"As described in [BCMCS], the users of the service are 
required to know the IPv4 address of the controller entity 
so that they can download all the necessary information"

---change "all the necessary information" to "all necessary 
information"

"about a desired broadcast program.  In a roaming 
environment static configuration of the controller IPv4 address"

---change "controller" to "controller's"

"becomes unrealistic.  Therefore, DHCP is considered to be a 
method to dynamically configure the controller IPv4 address 
or the fully qualified domain name of the controller in the 
3G wireless networks."

"In order to allow the users to discover the broadcast 
controllers, the clients request for appropriate option 
codes from the DHCP servers using Parameter Request List 
option."

---reword the sentence: "In order to allow the users to 
discover the broadcast controllers, the clients request 
options from DHCP servers using the Parameter Request List 
option (option number 55)."

"4.  Broadcast Service Controller Options

"This section defines the configuration option for the 
controller of Broadcast Service."

---change "configuration option for the controller of 
Broadcast Service" to "configuration option for the 
broadcast service controller."

"The Configuration Option contains the IPv4 address or the 
fully qualified domain names of the broadcast service 
controller."

---change "Configuration Option" to "configuration option"

functionality:

"4.  Broadcast Service Controller Options

"The option MAY contain multiple domain names, but these 
domain names SHOULD be used to construct SRV lookups as 
specified in [BCMCS], rather than querying for different A 
records.  The client MUST try the records in the order 
listed, applying the mechanism described in [BCMCS] for each 
entry."

---I think the client "SHOULD" try the records in the order 
listed, rather than "MUST"

"5.  Security Considerations"

(Ralph) Should it be the editorial policy of the DHC to ask 
that I-D editors not only state the risks that they imagine 
if their draft is accepted, but also offer proposed solutions?

---

From: Barr Hibbs <[email-masked]>
Date: Mon, 14 Feb 2005 09:15:44 -0800

> authors can speak to this point.
...if I understand you correctly, Ted, you're suggesting one 
  *draft* to cover two *options*, one for DHCPv4 and the 
other for DHCPv6.

That's a very good suggestion, and I will definitely support 
this as a general editorial policy when parallel (or 
identical) options are being proposed for both v4 and v6.

--Barr