Subject: [dhcwg] bcmc status mail from Kuntal Chowdhury

From: Stig Venaas <[email-masked]>
Date: Mon, 12 Sep 2005 21:12:02 +0200

----- Forwarded message from "Chowdhury, Kuntal" <[email-masked]> -----
Subject: RE: New Version Notification - draft-ietf-dhc-bcmc-options-03.txt
Date: Fri, 9 Sep 2005 17:53:12 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
[...]

Here is the list of the open comments and the responses summarized from
the email threads:

DISCUSSES AND COMMENTS:
======================
Brian Carpenter:

Discuss [2005-07-07]:
Extracts from Gen-ART review by Elwyn Davies:
----------------------------------------------------------------------

Comment #1:
==========
"...
Summary for version -02:
This document is certainly not ready for publication.  Indeed it may
(still) be fundamentally flawed:

Two questions need to be answered regarding the new version:
- My question to v01, as to whether this is fundamentally flawed,
remains on thetable (Does it need multiple domain names or can it just
use multiple SRV records for the one wireless access domain.
- in which case do we really need DHCP(v6) options at all?).. the
authors need to explain why multiple domain names are needed because I
couldn't tell from the BCSMS document and the wording seems to imply one
domain would be enough.
"

Response:
---------
Multiple domain names should be allowed. If the operator supports only
one domain, the option will contain only a domain name. In the future
there will be cases where the operator has one or more
partners/resellers (Mobile Virtual Network Operators (MVNO) model) for
broadcast and multicast service. In that case, the operator (access
service provider) should be able to use the same DHCP option to send
multiple of those domain names (MVNOs). There is no need to restrict the
option to contain only one domain name. If there is only one domain name
supported by the access service provider, it will contain one domain
name, otherwise it may contain a list of domains to support resellers
and partner network operators.

Subsequent Comment:
-------------------
> I just had a long chat with one of the authors outside the DHC wg
meeting.
> 
> It appears that the situation is as follows (please correct me if I am
> wrong):
> - A mobile has no other way of finding out the domain name of the
> place(s) where broadcast servers can be found and hence may well need 
> a DHCP/DHCPv6 option to find the domain name to locate its server(s).
> - It is not clear to me even after the discussion whether more than 
> one domain name is needed - the 3GPP2 architecture allows the server 
> to be either in the visited domain or the home domain (although the 
> wording in the BCMCS document refers to the access network in a way 
> that I would interpret as the access network that the mobile is using 
> at that moment).  This seems to imply to me that the network operator 
> has a choice to offer one or the other but the mobile has to take what

> it is given.  WHETHER OR NOT THIS IS THE CASE (BOTH) DOCUMENTS NEED TO

> BE IMPROVED to explain what is going on.

Response:
---------
I don't get it. What is the problem if more than one domain name is
allowed in the option? If the operator has no partnership such as MVNO,
there will be one domain name returned. If the operator supports MVNOs
(BTW most of the 3G wireless operators in North America do) they will
provision different domain names for its own BCMCS service and for that
of the MVNOs e.g. operator.com; mvno1.com, mvno2.com etc. Based on the
user's preference (setting) in the BCMCS client, it may choose to use
one of the domain names to fetch the appropriate BCMCS controller
address. If no preferred domain name is found in the list, the client
may use a default setting e.g. use the first one in the list. BTW, the
client setting should be controlled by the user; this document should
not mandate any particular behavior, IMHO.

Change made: None. 
-----------

Comment #2:
===========
"
- As a result of the update, 2 DHCP code points are needed: Is there
enough DHCP option space available for this request to get 2 code
points, rather than the one which was RFC3361 got?
"
Response:
---------
I think there is enough codes available. At least that was my
understanding.

Change made: None. 
-----------

Comment #3:
==========
"
Detailed review for v02:

The editorial state of the document (apart from s5) is much improved
after Margaret Wasserman's review.  The majority of my comments are
substantive...

Abstract/s1/s2: These sections imply that the options have wider
application than the main focus which is 3GPP2. Whilst it is true that
3GPP is also considering broadcast services, I can find no evidence that
either 3GPP or OMA are actively considering the use of DHCP options as
part of their configuration process.  Maybe the implications of wider
applicability need to be toned down a little.
"

Response:
--------
Not sure what needs to be toned down here. The purpose of the text in
the abstract is to educate the reader that the broadcast and multicast
services are being standardized in some of the SDOs such as 3GPP, OMA
and 3GPP2. This is a true statement. There is no hint or mention in the
draft that all these SDOs embraced DHCP as the way to configure the
mobile devices at this time.

Change made: None. 
-----------

Comment #4:
===========
"
s4.1: The example at the end of 4.1 is now differently broken: the
length byte for the second 'example' component is at the end of the
structure rather than between the 0 for the end of the first domain name
and the 'e' for the start of example.
"

Response: the example was beaten to death even though it is a ditto copy
from RFC 3361. There is a note added to the RFC editor to fix it as
well.
"
Change made: 
-----------

-02 version:

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' | 'o'| 'm'|  0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   | 3  | 'n'| 'e'| 't'|  0 |  7 |
   +----+----+----+----+----+----+

-03 version:

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' |'o'| 'm'|  0 |  7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   |'e' |  3 | 'n'| 'e'| 't'|  0 |
   +----+----+----+----+----+----+

Comment #5:
===========
"
s4.1/4.2:  ' Use of multiple domain names is not meant to replace the
SRV records, but rather to allow a single DHCP/DHCPv6 server to indicate
the broadcast controllers in the access provider's network.'   This
sentence has
been adapted from a similar sentence in RFC3319 and RFC3361 - 'Use of
multiple domain names is not meant to replace NAPTR and SRV records, but
rather to allow a single DHCP server to indicate outbound proxy servers
operated by multiple providers.'  I am unclear about why multiple domain
names would be needed for '*the* access provider's network'.  This needs
better explanation - and if it can't be provided then maybe this work is
not needed at all: multiple SRV records would provide all that is needed
perhaps.
"

Response:
---------
The need for multiple domain names has been explained before.

Change made: None. 
-----------

Comment #6:
===========
"
s4.5/4.6: Now that there are two separate options for IPv4, all the
stuff in
4.5 and 4.6 which just talks about v6 needs to be duplicated for v4.
"

Response:
---------
Nope...DHCPv4 and DHCPv6 protocols do not work in the same fashion.
There is no such thing as ORO in DHCPv4. Besides, s4.6 talks about IPv4
options.

Change made: None. 
-----------

Comment #7:
===========
"
s4.6: A reference to s3.1 or RFC1035 might also help regarding encoding
of domain names and comparisons.
"

Response:
--------
RFC1035 is referenced in s4.6. Is there anything more that is absolutely
necessary?

Change made: None. 
-----------

Comment #8:
===========
"
s5: At least: s/applies/apply/, s/spec/specification/, s/in-transist/in
transit/, s/&/and/ Personally I would redraft this section:
This document does not introduce any new security concerns beyond those
specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315]
specifications.  In the absence of message integrity protection for
these options,  an attacker could modify the option values to frustrate
or divert requests for broadcast service.
"

Response:
---------
OK...I will adopt this suggested rewrite.

Change made:
-----------

-02 version:

5. Security Considerations
   The security considerations in the base DHCP spec [RFC2131] applies.
   An attacker may change information of the BCMCS 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
   & Multicast service may be diverted to a rogue BCMCS controller.

-03 version:

5. Security Considerations
   This document does not introduce any new security concerns beyond
   those specified in the basic DHCP [RFC2131] and DHCPv6 [RFC3315]
   specifications.  In the absence of message integrity protection for
   these options, an attacker could modify the option values to
   frustrate or divert requests for broadcast service.

----------------------------------------------------------------------
David Kessens:

Discuss [2005-07-07]:
I received the following comments from the Ops directorate by Pekka
Savola that needs to be addressed:

Comment #9:
===========
"
substantial
-----------

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' | 'o'| 'm'|  0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   | 3  | 'n'| 'e'| 't'|  0 |  7 |
   +----+----+----+----+----+----+

==> is the example encoding correct?  Based on the description, I
thought it should have been:

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' | 'o'| 'm'|  0 | 7  |' e'| 'x'| 'a'| 'm'| 'p'| 'l'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   |'e' | 3  | 'n'| 'e'| 't'|  0 |
   +----+----+----+----+----+----+

...
"

Response:
---------
The example will be updated as noted in "Note to RFC Editor". I will fix
it in -03 version.

Change made: 
-----------

-02 version:

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' | 'o'| 'm'|  0 | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   | 3  | 'n'| 'e'| 't'|  0 |  7 |
   +----+----+----+----+----+----+

-03 version:

   +----+----+----+----+----+----+----+----+----+----+----+
   |TBD1| 26 | 7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'| 'e'|  3 |
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+----+----+----+----+----+
   |'c' |'o'| 'm'|  0 |  7  | 'e'| 'x'| 'a'| 'm'| 'p'| 'l'|
   +----+----+----+----+----+----+----+----+----+----+----+
   +----+----+----+----+----+----+
   |'e' |  3 | 'n'| 'e'| 't'|  0 |
   +----+----+----+----+----+----+

Comment #10:
============
"
   If the length of the domain list exceeds the maximum permissible
   length within a single option (254 octets), then the domain list MUST
   be represented in the DHCPv4 message as specified in [RFC3396] .

==> is this really needed?  Is there really a perceived usage case where
the list would be longer than that?  This seems to be just inviting a
case which is not implemented or tested, and will break when used.  I'd
suggest forbidding the long options for simplicity unless there exists
an appropriate usage case for them..
"

Response:
---------
This draft is very similar to RFC3361 from every perspective. The
sentence in question is there in that RFC as well. Please note that
BCMCS service is not deployed as of now. How the service will be
deployed and how it will turn out to be in future are anybody's guess.
So, I would like to keep as much flexibility in the options as possible.

Change made: None. 
-----------

Comment #11:
============
"
   If a client receives both the BCMCS Controller Domain Name List and
   IPv6 Address options, it SHOULD use the Domain Name List option.  In
   this case, the client MAY use the BCMCS Controller IPv6 Address
   option only if the servers in the BCMCS Controller Domain Name List
   can not be resolved or reached.
==> is it clear which level of normativeness you mean with the use of
'MAY' in this context?  Did you mean, "In this case, the client MUST NOT
use the ... unless the servers in ..." ?  Using MUST NOT or SHOULD NOT
seems clearer, because 'MAY' in this context can be interpreted
differently.
"

Response:
---------
I see your point. I will use "SHOULD NOT use..." in -03 version.

Change made:
------------

-02 version:

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

-03 version:

   If a client receives both the BCMCS Controller Domain Name List and
   IPv6 Address options, it SHOULD use the Domain Name List option.  In
   this case, the client SHOULD NOT use the BCMCS Controller IPv6
   Address option unless the servers in the BCMCS Controller Domain Name
   List can not be resolved or reached.

Comment #12:
===========
"
6.  IANA Considerations
[...]
  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

==> (these would probably be removed by the RFC-editor, but..) I think
it's inappropriate to include this kind of URLs in an RFC.  I'd suggest
removing these two paragraphs; I'd hope that IANA can find the right
registries without this guidance :) "

Response:
---------
Well...these two were added upon suggestion by one of the reviewers. I
will remove these as you suggest and hope for the better.

Change made:
------------

-02 version: 

   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

-03 version:

These two lines are deleted.

Comment #13:
===========
"
Comment [2005-07-07]:
I received the folloing comments from the Ops directorate by Pekka
Savola:

   BCMCS Control Server Domain Name List: Identical content as in
   Section 4.1

... while 4.1 had:

   The general format of the BCMCS Controller Domain list option for
   DHCPv4 is as follows:

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

==> it seems obvious but I guess one could take the "Identical content"
statement literally and include also the Code and Len bytes to the
domain name list part?  Shouldn't be an issue for those with brains
turned on. Not sure if this could use a wording tweak or not.
"

Response:
---------
How about "BCMCS Control Server Domain Name List: Identical content as
in Section 4.1 (except the Code and Len fields)."?

Change made:
------------

-02 version:

   BCMCS Control Server Domain Name List: Identical content as in
   Section 4.1

-03 version:

   BCMCS Control Server Domain Name List: Identical content as in
   Section 4.1 (except the Code and Len fields).

Comment #14:
============
"
     |                                                               |
     |    BCMCS Control server-1 address (IPv6 address)          |

==> the right spacing before '|' should be fixed

"

Response:
---------
Fixed.

Change made:
------------

-02 version:

    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_A    |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |    BCMCS Control server-1 address (IPv6 address)          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |    BCMCS Control server-2 address (IPv6 address)          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-03 version:

      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_A    |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |    BCMCS Control server-1 address (IPv6 address)              |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |    BCMCS Control server-2 address (IPv6 address)              |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Comment #15:
============
"
   An attacker may change information of the BCMCS Controller in packets
   that are in-tranist from DHCP server to the MN, if integrity

==> s/tranist/transit/

"

Response:
---------
This section is re-written based on Elwyn Davies's comment.

Change made: None. 
-----------

Bert Wijnen:

Comment [2005-07-06]:
------------------------------------------------------------------------
-

Comment #16:
============
"
Needs a normative reference and a citation (in sect 3) to RFC2119 "

Response:
---------
Added.

Change made:

-02 version:

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. (pending publication)",
              December 2004.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

-03 version:

   [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. (pending publication)",
              December 2004.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

Some Additional Comments from Elwyn Davies on -3 version:
------------------------------------------------------------------------

Comment #17:
============
"
> - The operators in 3GPP2 claim there is a need for both FQDN and 
> address options.  There was pushback in the meeting about this but the

> authors claim that this has been previously discussed in the wg and 
> the dual approach agreed.
>   The wg chairs need to rule on this one.
"

Response:
---------
I don't understand what the problem here is. The draft had both the FQDN
and the address options since day one. Several people reviewed it and
nobody had any issue with that. The two options are there for obvious
reason. We want to give the operators provisioning flexibility.

Change made: None
------------

Comment #18:
============
"
> - If multiple domain names/addresses can be offered, the logic for 
> determining which one of them the client should select needs to be 
> specified in such a way that it can be implemented algorithmically and

> deterministically - as Brian writes below and others commented in the 
> meeting, the new wording in v3 is unsatisfactory.  The v2 wording was 
> better and acceptable to me (it reflects the corresponding sip 
> wording).
"

Response:
---------
The client should be able to choose the preferred domain based on the
user's setting. There are tons of clients out there that do operate
exactly this way, e.g. the wi-fi clients allow the user to set the
preferred SSID or network type. We can certainly add a sentence if it
helps.

Change made: TBD.
------------

Comment #19:
============
"
> - If two DHCP options are used:
>   - If extension codes are used, then the new options will only work
with
>     servers that support extension codes.
>   - The text in 4.5 and 4.6 has to be upgraded to explain how to
decide whether
>     to send address or FQDN replies for DHCP in the same way as it is
explained
>     for DHCPv6 currently.
"

Response:
---------
Hmmm...I think I did explain this to you before. In DHCP, there is no
ORO. Therefore, the only thing the server can use to decide whether to
send one or the other or both the options is to use its provisioned
policy.

Change made: None
------------

Comment #20:
============
"
> The -03 draft says:
> 
>     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 can try
any
>     or ALL of the domain names to construct the SRV lookups.  The list
of
>     domain names MAY conatin the domain name of the access provider
and
>     it's partner networks that also offer broadcast and multicast
>     service.
> 
> This is not algorithmic. It does not say when it is appropriate to 
> exercise either of the MAYs and does not say when it is justified to 
> ignore the SHOULD. But an implementor needs these explanations to know

> what to code or configure. This is especially important for the SHOULD
> - do I write code to try all of the names, all but three, or only the
fifth one?
"

Response:
---------
Ideally, the implementer should write sw code in such a way that allows
the user to set his/her preference if more than one domain names are
received. If I am the user I would expect my client to let me set my
preference: 
1st preference:  foo1.com
2nd preference:  foo2.com
If no match found...try all starting from the first one. I can add this
example if it helps.

Change made: TBD.
------------

Comment #21:
============
"
> > [Nits: two typos (conatin and it's) in the last sentence. "ALL" is
> > capitalised for no obvious reason.]
"

Response:
----------
OK, I will fix them.

Change made: TBD.
------------

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, September 09, 2005 9:01 AM
> To: [email-masked]
> Cc: Stig Venaas; Chowdhury, Kuntal; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: New Version Notification -
draft-ietf-dhc-bcmc-options-03.txt
> 
> Any progress on this discussion? I'm still holding a discuss
> until I hear back.
> 
>     Brian
> 
> 
> 
> Brian E Carpenter wrote:
> > Please do take it to the list, but don't forget the comment
> > I made - the key thing when a document contains options and
> > SHOULDs and MAYs is that it should then also contain enough
> > information for the implementer (writing code or defining
> > configuration) to decide what to actually *do* with each option:
> >
> > 1: when is it OK to ignore a SHOULD?
> > 2: when is it useful to implement a MAY?
> > 3: how to choose when more than one data element is present?
> >    ("local policy" is a fine answer)
> >
> > I think it's because these three things aren't clear that we
> > are having this conversation.
> >
> >    Brian
> >
> > Stig Venaas wrote:
> >
> >> I suggest we take the discussion to the dhc wg list. We should get
> input
> >> from the wg on this.
> >>
> >> Elwyn, can you post your issues to the list?
> >>
> >> Kuntal, once Elwyn has done that, could you then post this
response?
> >>
> >> IMO what you write below clarifies a lot and it would help to have
> >> some text like this in the draft.
> >>
> >> Stig
> >>
> >> On Sat, Aug 06, 2005 at 05:48:40PM -0400, Chowdhury, Kuntal wrote:
> >>
> >>> Please see inline [KC]>....
> >>>
> >>> Thanks,
> >>> Kuntal
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>>> Sent: Thursday, August 04, 2005 5:14 AM
> >>>> To: Brian E Carpenter
> >>>> Cc: Elwyn Davies; [email-masked]; [email-masked];
> >>>> [email-masked]; [email-masked]; Chowdhury,
Kuntal;
> >>>> [email-masked]; [email-masked]
> >>>> Subject: Re: New Version Notification -
> >>>
> >>>
> >>> draft-ietf-dhc-bcmc-options-03.txt
> >>>
> >>>> I just had a long chat with one of the authors outside the DHC wg
> >>>
> >>>
> >>> meeting.
> >>>
> >>>> It appears that the situation is as follows (please correct me if
I
> am
> >>>> wrong):
> >>>> - A mobile has no other way of finding out the domain name of the
> >>>
> >>>
> >>> place(s)
> >>>
> >>>> where
> >>>> broadcast servers can be found and hence may well need a
DHCP/DHCPv6
> >>>> option to
> >>>> find the domain name to locate its server(s).
> >>>> - It is not clear to me even after the discussion whether more
than
> >>>
> >>>
> >>> one
> >>>
> >>>> domain
> >>>> name is needed - the 3GPP2 architecture allows the server to be
> either
> >>>
> >>>
> >>> in
> >>>
> >>>> the
> >>>> visited domain or the home domain (although the wording in the
BCMCS
> >>>> document
> >>>> refers to the access network in a way that I would interpret as
the
> >>>
> >>>
> >>> access
> >>>
> >>>> network that the mobile is using at that moment).  This seems to
> imply
> >>>
> >>>
> >>> to
> >>>
> >>>> me
> >>>> that the network operator has a choice to offer one or the other
but
> >>>
> >>>
> >>> the
> >>>
> >>>> mobile
> >>>> has to take what it is given.  WHETHER OR NOT THIS IS THE CASE
(BOTH)
> >>>> DOCUMENTS
> >>>> NEED TO BE IMPROVED to explain what is going on.
> >>>
> >>>
> >>> [KC>] I don't get it. What is the problem if more than one domain
name
> >>> is allowed in the option? If the operator has no partnership such
as
> >>> MVNO, there will be one domain name returned. If the operator
supports
> >>> MVNOs (BTW most of the 3G wireless operators in North America do)
they
> >>> will provision different domain names for its own BCMCS service
and
> for
> >>> that of the MVNOs e.g. operator.com; mvno1.com, mvno2.com etc.
Based
> on
> >>> the user's preference (setting) in the BCMCS client, it may choose
to
> >>> use one of the domain names to fetch the appropriate BCMCS
controller
> >>> address. If no preferred domain name is found in the list, the
client
> >>> may use a default setting e.g. use the first one in the list. BTW,
the
> >>> client setting should be controlled by the user; this document
should
> >>> not mandate any particular behavior, IMHO.
> >>>
> >>>
> >>>> - Thus it may be the case that this option is needed but it is
still
> a
> >>>> matter of
> >>>> discussion whether it should offer one or several domain options.
> >>>> - The operators in 3GPP2 claim there is a need for both FQDN and
> >>>
> >>>
> >>> address
> >>>
> >>>> options.  There was pushback in the meeting about this but the
> authors
> >>>> claim
> >>>> that this has been previously discussed in the wg and the dual
> >>>
> >>>
> >>> approach
> >>>
> >>>> agreed.
> >>>>  The wg chairs need to rule on this one.
> >>>
> >>>
> >>> [KC>] Again, I don't understand what the problem here is. The
draft
> had
> >>> both the FQDN and the address options since day one. Several
people
> >>> reviewed it and nobody had any issue with that. The two options
are
> >>> there for obvious reason. We want to give the operators
provisioning
> >>> flexibility.
> >>>
> >>>> - The authors believe that they have been told that there is no
> longer
> >>>
> >>>
> >>> a
> >>>
> >>>> shortage of DHCP options (due to the extension mechanism) so that
> >>>> requesting two
> >>>> options is not a problem.
> >>>>
> >>>> Once all this has been sorted out, the rest of the document needs
to
> >>>> reflect the
> >>>> decisions made:
> >>>> - If multiple domain names/addresses can be offered, the logic
for
> >>>> determining
> >>>> which one of them the client should select needs to be specified
in
> >>>
> >>>
> >>> such a
> >>>
> >>>> way
> >>>> that it can be implemented algorithmically and deterministically
- as
> >>>> Brian
> >>>> writes below and others commented in the meeting, the new wording
in
> >>>
> >>>
> >>> v3
> >>>
> >>>> is
> >>>> unsatisfactory.  The v2 wording was better and acceptable to me
(it
> >>>> reflects the
> >>>> corresponding sip wording).
> >>>
> >>>
> >>> [KC>] The client should be able to choose the preferred domain
based
> on
> >>> the user's setting. There are tons of clients out there that do
> operate
> >>> exactly this way, e.g. the wi-fi clients allow the user to set the
> >>> preferred SSID or network type. We can certainly add a sentence if
it
> >>> helps.
> >>>
> >>>
> >>>> - If two DHCP options are used:
> >>>>  - If extension codes are used, then the new options will only
work
> >>>
> >>>
> >>> with
> >>>
> >>>>    servers that support extension codes.
> >>>>  - The text in 4.5 and 4.6 has to be upgraded to explain how to
> >>>
> >>>
> >>> decide
> >>>
> >>>> whether
> >>>>    to send address or FQDN replies for DHCP in the same way as it
is
> >>>> explained
> >>>>    for DHCPv6 currently.
> >>>
> >>>
> >>> [KC>] Hmmm...I think I did explain this to you before. In DHCP,
there
> is
> >>> no ORO. Therefore, the only thing the server can use to decide
whether
> >>> to send one or the other or both the options is to use its
provisioned
> >>> policy.
> >>>
> >>>> - If only one option is to be used, then 4.5 and 4.6 need to be
> >>>
> >>>
> >>> revised to
> >>>
> >>>> remove text about the alternatives.
> >>>>
> >>>
> >>> [KC>] Both the options should be used.
> >>>
> >>>
> >>>> The authors are going to talkj to the wg chairs and other
commenters
> >>>
> >>>
> >>> after
> >>>
> >>>> the
> >>>> meeting and try to get this sorted out post haste.
> >>>>
> >>>> Regards,
> >>>> Elwyn
> >>>> Quoting Brian E Carpenter <[email-masked]>:
> >>>>
> >>>>
> >>>>> (WG chairs - please forward this to the WG if appropriate.)
> >>>>>
> >>>>> Elwyn,
> >>>>>
> >>>>> Does this version resolve your main review comments? I don't
> >>>>> seem to have been copied on any discussion since my DISCUSS
> >>>>> was registered.
> >>>>>
> >>>>> Elwyn said:
> >>>>>
> >>>>>
> >>>>>> - My question to v01, as to whether this is fundamentally
flawed,
> >>>>
> >>>>
> >>>> remains
> >>>>
> >>>>> on the
> >>>>>
> >>>>>> table (Does it need multiple domain names or can it just use
> >>>
> >>>
> >>> multiple
> >>>
> >>>>>> SRV records for the one wireless access domain - in which case
do
> >>>
> >>>
> >>> we
> >>>
> >>>>>> really need DHCP(v6) options at all?).. the authors need to
> >>>
> >>>
> >>> explain
> >>>
> >>>> why
> >>>>
> >>>>>> multiple domain names are needed because I couldn't tell from
the
> >>>>
> >>>>
> >>>> BCSMS
> >>>>
> >>>>>> document and the wording seems to imply one domain would be
> >>>
> >>>
> >>> enough.
> >>>
> >>>>>
> >>>>> The -03 draft says:
> >>>>>
> >>>>>    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 can
> >>>
> >>>
> >>> try
> >>>
> >>>> any
> >>>>
> >>>>>    or ALL of the domain names to construct the SRV lookups.  The
> >>>
> >>>
> >>> list
> >>>
> >>>> of
> >>>>
> >>>>>    domain names MAY conatin the domain name of the access
provider
> >>>
> >>>
> >>> and
> >>>
> >>>>>    it's partner networks that also offer broadcast and multicast
> >>>>>    service.
> >>>>>
> >>>>> This is not algorithmic. It does not say when it is appropriate
to
> >>>>
> >>>>
> >>>> exercise
> >>>>
> >>>>> either of the MAYs and does not say when it is justified to
ignore
> >>>>> the SHOULD. But an implementor needs these explanations to know
what
> >>>
> >>>
> >>> to
> >>>
> >>>>> code or configure. This is especially important for the SHOULD -
do
> >>>
> >>>
> >>> I
> >>>
> >>>> write
> >>>>
> >>>>> code to try all of the names, all but three, or only the fifth
one?
> >>>>>
> >>>
> >>> [KC>] Ideally, the implementer should write sw code in such a way
that
> >>> allows the user to set his/her preference if more than one domain
> names
> >>> are received. If I am the user I would expect my client to let me
set
> my
> >>> preference: 1st preference:  foo1.com 2nd preference:  foo2.com
> >>> If no match found...try all starting from the first one. I can add
> this
> >>> example if it helps.
> >>>
> >>>
> >>>
> >>>>> [Nits: two typos (conatin and it's) in the last sentence. "ALL"
is
> >>>>> capitalised for no obvious reason.]
> >>>>> [KC>] OK, I will fix them.
> >>>
> >>>
> >>>
> >>>>> Elwyn's second major comment:
> >>>>>
> >>>>>
> >>>>>> - As a result of the update, 2 DHCP code points are needed: Is
> >>>
> >>>
> >>> there
> >>>
> >>>>> > enough DHCP option space available for this request to get 2
code
> >>>>> > points, rather than the one which was RFC3361 got?
> >>>>>
> >>>
> >>> [KC>] This was already discussed and agreed, AFAIK.
> >>>
> >>>
> >>>>> Was this answered during the discussion of Elwyn's review?
> >>>>>
> >>>>>    Brian
> >>>>>
> >>>>> ID Tracker wrote:
> >>>>>
> >>>>>> New version (-03) has been submitted for
> >>>>>
> >>>>>
> >>>>> draft-ietf-dhc-bcmc-options-03.txt.
> >>>>>
> >>>
http://www.ietf.org/internet-drafts/draft-ietf-dhc-bcmc-options-03.txt
> >>>
> >>>>>
> >>>>
> >>>> --
> >>>
> >>>
> >>>
> >>> "This email message and any attachments are confidential
information
> >>> of Starent Networks, Corp. The information transmitted may not be
> >>> used to create or change any contractual obligations of Starent
> >>> Networks, Corp.  Any review, retransmission, dissemination or
other
> >>> use of, or taking of any action in reliance upon this e-mail and
its
> >>> attachments by persons or entities other than the intended
recipient
> >>> is prohibited. If you are not the intended recipient, please
notify
> >>> the sender immediately -- by replying to this message or by
sending
> >>> an email to [email-masked] -- and destroy all
copies
> >>> of this message and any attachments without reading or disclosing
> >>> their contents. Thank you."
> >>
> >>
> >>
> >

----- End forwarded message -----

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Sep 2005 16:00:42 -0400

More on multiple DNS names in the option:

> allowed in the option?

The basic issue is that SRV is intended to do away with the need for
"multiple names". I.e., one SRV name returns you a list of servers you
can try contacting. So you don't need multiple names.

Allowing multiple SRV names raises the question of which name do you
pick? What algorithm should the client use when selecting a server to
try and contact?  You can't "merge" the two names and let the client
try them both. That doesn't really make sense in the SRV context. And
if the client isn't implementing an algorithm with predictable
behavior when multiple names are provided, an operator probably won't
be happy with the results of advertising multiple DNS names. Hence,
the details really do matter!

What it sounds like is wanted is a way for the server to advertise
multiple names, and an intelligent client that has some other
knowledge that helps it pick the service it wants. But the document
says nothing about that. Also, if the client is preconfigured with
"prefered BCMC servers" it should use, that sort of (though not
entirely) begs the question of why a DHC option is needed in the first
place. I.e., just try looking up the SRV record for the
"preconfigured" service. What more is needed? :-)

> If the operator has no partnership such as MVNO,
> address.

This is the missing info. The current  document say nothing about this
being either possible or the intended usage. I'd feel better if
something about the above went into the document.

> If no preferred domain name is found in the list, the client

Thomas