Subject: [dhcwg] Review of draft-ietf-dhc-bcmc-options-01.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 16 Jun 2005 16:31:35 -0400

I've completed a review of the above document. I don't think any of my
issues are particularly controversial, but I a new revision is
definitely needed.

I understand in chatting with Ralph/Margaret, that she is about to
start the IETF LC on the document. So these should be treated as LC
comments and will needed to be addressed before the document gets sent
to the full IESG. I would suggest we target getting this on the IESG
agenda of the July 7 call. In order to do that, we'll need a revised
version no later than about ten days from now. Can we do that? 

Substantive issues:

>    If the 'enc' byte has a value of 0, the encoding byte is followed by
>    a sequence of labels, encoded according to Section 3.1 of RFC 1035
>    [RFC1035].

What is the 'enc' used for? For the options defined, it will always be
0 for the domain name list, or 1 for the address. But sense those also
have differnt DHC option numbers, the fields are duplicate (and
useless). Just get rid of the 'enc' field entirely?

(Actually, Ralph convinced me that this field is no longer needed and
that is why the example encoding didn't make sense to me... So I
assume that all references to 'enc' need to be removed)

>    server using Parameter Request List option.  The DHCP servers need to
>    return the corresponding configuration options that carry either
>    broadcast and multicast service controller's IP address or fully
>    qualified domain name based on configuration.  This document defines
>    the necessary options and option codes.

I don't understand the above about "broadcast or multicast service
controller's IP address". This suggests there are two kinds of
servers, yet the option only defines one type. Are there really two
kinds of servers, and if so, does the option not need to communicate
this information?

>    Clients MAY support compression according to the encoding in Section
>    4.1.4 of "Domain Names - Implementation And Specification [RFC1035].

No. Clients either MUST support compression, or compression MUST NOT
be used at all. You won't get interoperability otherwise. I.e., server
can't send a compressed option if it has to guess whether the client
supports it...

>    An example case when two controller domain names e.g.
>    bcmc1.example.com, bcmc2.example.com are returned will be:
> 
>        +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>        |TBD|38 | 5 |'b'|'c'|'m'|'c'|'1'| 8 |'e'|'x'|'a'|'m'|'p'|'l'|'e'|
>        +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

where does the "5" in the third octet come from? shouldn't that be a
0? (example is OK if 'enc' field  is removed...)

Editorial:

>    In order to allow the MNs to discover the broadcast controllers, the
>    DHCP clients request for appropriate option codes from the DHCP

s/for/the/
>    server using Parameter Request List option.  The DHCP servers need to

>    4.  Broadcast Service Controller Options . . . . . . . . . . . . .  6
>      4.1   Broadcast Service Controller Domain Name list  . . . . . .  6

s/list/list for DHCPv4/

>      4.2   Broadcast Service Controller Domain Name List Option
>            for DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . .  7
>      4.3   Broadcast Service Controller IPv4 address option . . . . .  8

s/option/option for DHCPv4/

>      4.4   Broadcast Service Controller IPv6 Address Option . . . . .  8

s/Option/Option for DHCPv6/

>      4.5   Consideration for Client Operation . . . . . . . . . . . .  9
>      4.6   Consideration for Server Operation . . . . . . . . . . . .  9

>    While DHCP offers necessary mechanisms for device configuration, it
>    lacks the information elements required to configure a mobile device
>    to support BCMCS. This memo defines the extensions needed for DHCP
>    to provide necessary configuration information to a mobile device in
>    a BCMCS network.

Better:

   While DHCP already defines many options for device configuration,
   no option exists for configuring a mobile device to use BCMCS.
   This memo defines extensions for both DHCPv4 and DHCPv6 so that
   DHCP can be used to provide necessary configuration information to
   a mobile device about BCMCS controllers.

>    DHCP is being used in 3GPP2, for example, to assist with the
>    discovery of the BCMCS Controller in a mobile operator's IP network.

This document defines options for both DHCPv4 and DHCPv6. Given that,
I think it would be more clear if all usages of "DHCP" were changed to
say "DHCPv4" explicitely.

>    In order to allow the MNs to discover the broadcast controllers, the
>    DHCP clients request for appropriate option codes from the DHCP
>    server using Parameter Request List option.  The DHCP servers need to

Better:

   In order to allow the MNs to discover the broadcast controllers,
   the MNs request the appropriate option codes from the DHCP server
   using Parameter Request List option.  The DHCP servers need to

> These interactions may happen via HTTP and XML.

I assume that this would be better written as:

These interactions may happen via HTTP and XML as defined in [BCMCS].

> 4.1  Broadcast Service Controller Domain Name list
> 
>    If the 'enc' byte has a value of 0, the encoding byte is followed by
>    a sequence of labels, encoded according to Section 3.1 of RFC 1035
>    [RFC1035].

It would really help to have the format shown here before talking
about the fields... E.g., move:

>    The DHCP option for this encoding has the following format:
> 
> 
>            Code  Len   enc   FQDN(s) of Broadcast Controller
>          +-----+-----+-----+-----+-----+-----+-----+-----+--
>          | TBD |  n  |  0  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
>          +-----+-----+-----+-----+-----+-----+-----+-----+--

up, to produce something like:

4.1  Broadcast Service Controller Domain Name list

   The general format of the Broadcast Controller Domain list option
   is as follows:

           Code  Len   enc   Broadcast Control Domain Name List
         +-----+-----+-----+-----+-----+-----+-----+-----+--
         | TBD1|  n  |  0  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+--

   If the 'enc' byte has a value of 0, the encoding byte is followed
   by a sequence of FQDN labels, encoded according to Section 3.1 of
   RFC 1035 [RFC1035].

[also, note use of TBD1, rather than generic TBD.]

> 4.2  Broadcast Service Controller Domain Name List Option for DHCPv6

This section repeats text that is copied verbatim from 4.1. I think it
would be better to omit the duplicate text and compress the section to
something like the following:

4.2  Broadcast Service Controller Domain Name List Option for DHCPv6

   The semantics and content of the DHCPv6 encoding of this option is
   exactly the same as the encoding described in the previous section,
   other than necessary differences between the way options are
   encoded in DHCPv4 and DHCPv6.

   Specifically, the DHCPv6 option for Boradcast Service Controller
   Domain Names has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OPTION_BCMCS_SERVER_D    |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Broadcast Control Domain Name List                   |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code: OPTION_BCMCS_SERVER_D (TBD2).

   option-length: Length of the 'Broadcast Control Server Domain Name
   List' field in octets; variable.

   Broadcast Control Domain Name List: Identical content as Section 4.1.

> 4.4  Broadcast Service Controller IPv6 Address Option

rearrage the option picture to put it before the description of the
"option-code" field.

>    controller.  In the absence of a mutual authentication procedure
>    between MN and the Broadcast controller, the MN may receive wrong or
>    fraudulent information about Broadcast Service.

does BCMCS provide such an authentication procedure?

Proposed rewording of IANA Considerations:

   The following option codes for Broadcast Service Controller option
   must be assigned by IANA:

   1.  The Broadcast Service Controller Domain Name list (section 4.1)
       has been assigned a value of TBD1 from the DHCPv4 option space.

   2.  The Broadcast Service Controller Domain Name list (section 4.2)
       has been assigned a value of TBD2 from the DHCPv6 option
       space, and a name of OPTION_BCMCS_SERVER_D. 

   3.  The Broadcast Service Controller IPv4 address option (section
       4.3) has been assigned a value of TBD3 from the DHCPv4 option
       space. 

   4.  The Broadcast Service Controller IPv6 address option (section
       4.4) has been assigned a value of TBD4 from the DHCPv6 option
       space, and a name of OPTION_BCMCS_SERVER_A.

   The DHCP options should be registered in
   http://www.iana.org/assignments/bootp-dhcp-extensions

   The DHCPv6 options should be registered in
   http://www.iana.org/assignments/dhcpv6-parameters

> 8.  Normative References
> 
>    [BCMCS]    3GPP2, www.3gpp2.org,
>               ftp://ftp.3gpp2.org/TSGX/Projects/X.P0022 2ndV&V.zip,
>               "X.S0022, Broadcast and Multicast Service in cdma2000
>               Wireless IP Network. (work in progress)", December 2004.

Is this still a "work in progress"?

Thomas

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 16 Jun 2005 17:39:24 -0400

Thomas,

Thanks for the comments. We will work on these issues right away.

-Kuntal

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: Thursday, June 16, 2005 3:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Chowdhury, Kuntal
> Subject: Review of draft-ietf-dhc-bcmc-options-01.txt
> 
> 
> . . . . .  8