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

From: Margaret Wasserman <[email-masked]>
Date: Fri, 15 Apr 2005 08:13:22 -0400

Hi All,

I have completed my AD Review of draft-ietf-dhc-bcmc-options-00.txt. 
I have several questions on this document, and there are several 
issues that will need to be resolved before the document is ready for 
review by the IESG.

I'll be on vacation for the next week (April 16th-24th), so I won't 
respond over the next several days.  But, perhaps the WG can reach 
some agreement on how to address the issues that I have listed below.

IMO, this document did not received adequate review by the WG before 
submission, and I would really appreciate it some members of this WG 
could review the document and see if there are other issues that I 
failed to catch.

Thanks,
Margaret

---

General Comments:

The editorial level of this document is not very high.  There are
several places where there are tense conflicts and/or strange wording.
I've marked some of them below, but not all of them.  It might be good
to have someone take a quick editing pass at this document while you
are making changes to address my other comments below.  That would
likely speed up other parts of the process.

Ralph and Stig, this document seems to violate the I-D guidelines in
several places (lines over 80 characters, use of non-example domain
names).  Could you please do a nits check and send the violations to
the authors.  I've marked the violations that I notice, but I may not
have caught all of them.  It would be good if the next version
complies with the I-D guidelines.  See:

http://www.ietf.org/ietf/1id-guidelines.html

Some of the issues I've marked below may be the result of a quick
merger of the IPv4 document and the IPv6 document.  There are places
where the document says IPv4-specific or IPv6-specific things where it
isn't clear to me why the text would not apply to the other version.
Also, there is duplication of text in some places.

Specific Comments (marked with >>):

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

>>  You need to expand the 3G acronym and make it clearer to which 3G
    networks you are referring.  Maybe "third generation (3G) cellular
    telephone networks" ?

    with a controller in the network to derive informations that are

>>  s/informations that are/information that is

>>  Does the user (a human being) really interact with the server?
    Or is the interaction handled automatically by the MN or MT
    device?

    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.

>>  I think that you mean that DHCPv4 or DHCPv6 may be used to configure
>>  a user's device to access a particular broadcast controller.  However
>>  the sentence is ambiguous, as it could also mean that DHCP is used
>>  to configure the IPv4 address of the broadcast controller _and_ to
>>  configure the broadcast controller's domain name on the user's
>>  device.
>>
>>  Why just an IPv4 address or domain name?  What about an IPv6 address?

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

>>  s/this memo is an effort to define/this memo defines

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

>>  s/mobile operators/mobile operator's

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

>>  Does the BCMCS really interact with the users?  Or with the mobile
>>  terminal, for instance?  We have several documents in the IETF
>>  context that describe the 3GPP architecture, and it might make sense
>>  to use more precise terminology from that architecture here.  If
>>  the terminology differs between 3GPP and 3GPP2, then a terminology
>>  section might be called for in this draft, so that more precise
>>  terms can be used.

    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.  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.  The motivation for
    this document is to define the necessary options and option codes.

>>  s/The motivation for this document is to define/This document defines/

    The user interacts with the Controller to request for
    broadcast/multicast program information from the network (e.g.,

>>  s/to request for/to request

    scheduled time, multicast IP address, port numbers).  The User may
    also be authenticated by the Controller while downloading the
    relevant program security related information (such as encryption
    key).  These interactions happen via HTTP and XML.  There may be more
    than one controller in the network.  The user should discover the
    appropriate controller to request the relevant program information.
    For details of Broadcast and Multicast Service operation in 3GPP2,
    see [BCMCS].

>>  What do you mean by "the user should discover the appropriate
>>  controller to request the relevant program information"?  Does
>>  the actual user (a human being) get a list of broadcast controllers
>>  to choose from?  How would he/she be expected to make that choice?

4.  Broadcast Service Controller Options

    This section defines the configuration option for the controller of
    Broadcast Service.  The Configuration Option contains the IPv4
    address or of the IPv4 address or the fully qualified domain names of
    the broadcast service controller.

>>  "the IPv4 address or of the IPv4 address" ??

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

    Since the domain names are supposed to be different domains,
    compression will likely have little effect, however.

>>  Why make it a MUST to support something that will have little effect?

    The DHCP option for this encoding has the following format:

            Code  Len   FQDN(s) of Broadcast Controller
          +-----+-----+-----+-----+-----+-----+-----+--
          | TBD |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
          +-----+-----+-----+-----+-----+-----+-----+--

    An example case when two controller domain names e.g.
    bcmc1.carrier1.com, bcmc2.carrier1.com are returned without 
compression will be:

>>  Please eliminate lines over 80 characters long.

>>  You also need to use the correct example domain names (i.e. example.com)
    in examples.  See RFC 2606.  Use of other domain names as examples
    is not allowed in RFCs.

4.3  Broadcast Service Controller IPv4 Address Option

    If the 'enc' byte has a value of 1, the encoding byte is followed by
    a list of IPv4 addresses indicating broadcast controller IPv4
    addresses.

>>  What is the 'enc' byte?  And is this a DHCPv4 or DHCPv6 option?

    The controllers MUST be listed in order of preference.
    Its minimum length is 5, and the length MUST be a multiple of 4 plus
    one.  The DHCP option for this encoding has the following format:

>>  Why would the minimum length by 5?  Why would the length be a
    multiple of 4 plus one?  Are you talking about the value of
    "len" or the overall length of the option?  I may be somewhat
    confused, but I think that "len" will be a multiple of four
    and that the overall length will be a multiple of four plus
    two.

4.4  Broadcast Service Controller IPv6 Address Option

    This DHCPv6 option MUST carry one or more 128-bit IPv6 address(es) of
    the Broadcast Service Controller in a operators network.

>>  Apparently there is an option for IPv6 addresses, so why isn't it
    mentioned in the abstract and introduction?

5.  Consideration for Client Operation for DHCPv6

    A client MAY request either or both of the Broadcast Service
    Controller Domain Name List and the IPv6 Address options in the
    Options Request Option (ORO) as described in [RFC3315].

    If a client receives both the Broadcast Service Controller Domain
    Name List and IPv6 Address options, it SHOULD use the Domain Name
    List option.  In this case, the client MAY use the Broadcast Service
    Controller IPv6 Address option only if, no server in the Broadcast
    Service Controller Domain Name List can be resolved or reached.

>>  s/only if, no/only if no/

>>  This wording is strange WRT the RFC 2119 language.  If you should
    do something, it is odd to say that you MAY do something else
    "only if" some other condition...  Are you trying to say that
    the client MUST use the Domain List Option unless no server in
    the Brodcast Service Controller Domain Name list can be resolve
    or reached?  Or are you trying to leave open the possibility that
    the client might decide to use the IP addresses instead of the
    domain names in some other case?

>>  Is there a reason why this is only a consideration for DHCPv6
    clients?

6.  Consideration for Server Operation

[..]

    Client sends in ORO     Domain Name List        IPv6 Address List
    __________________________________________________________________

    Neither option          SHOULD                  MAY
    Domain Name List        MUST                    MAY
    IPv6 Address            MAY                     MUST
    Both options            SHOULD                  MAY

>>  Is this intended only to be considerations for DHCPv6 servers?
    What do DHCPv4 servers do in these cases?  Is it really the case
    that DHCPv6 servers SHOULD send the Domain Name List option when it
    isn't requested by the client?  Why?

7.  Security Considerations

    The security considerations in the base DHCP specs [RFC2131] and
    [RFC3315] apply.  An attacker may change information of the Broadcast
    Service Controller in packets that are in-tranist from DHCP server to
    the MN, if integrity protection is not in place.  In that event, the
    user of the Broadcast service may be diverted to a rogue broadcast
    service 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.

>>  So what is required to prevent this?  Is implementation of specific
    security features a MUST for this specification?  Or is it presumed
    to be safe to use this option in networks with certain properties?

8.  IANA Considerations

    The option code for Broadcast Service Controller options MUST be
    assigned by IANA.

>>  I think that there are four option codes that need to be assigned,
    and you should be specific about what they are.  You also need to
    specify the registries in which they should be assigned.

10  Normative References

    [BCMCS]    3GPP2, www.3gpp2.org, "X.S0022, Broadcast and Multicast
               Service in  cdma2000 Wireless IP Network.", February 2005.

>>  I can't find this document.  Both X.S0021 and X.S0023 are listed on
    the web site, but not X.S0022.  Where do I find it?

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