Subject: [dhcwg] Further comments from Elwyn

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

Here are some further comments from Elwyn after talking to author at
last wg meeting.

Stig

----- Forwarded message from [email-masked] -----
Date: Thu,  4 Aug 2005 11:13:55 +0100
From: [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.
- 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.
- 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).
- 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.
- If only one option is to be used, then 4.5 and 4.6 need to be revised to
remove text about the alternatives.

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

[...]
----- 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 15:51:27 -0400

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

That is consistent with my understanding, indeed, that is the general
reason for using DHC to provide clients with DNS names...

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

I'm not entirely convinced that support for more than one DNS name is
needed, but I am not willing to block the document on this point. To
some degree, if the customers of this work want it, let them have
it. They seem to say so (and I pushed on this issue when I reviewed
the -01 document).

I'll also note that there is precendent in other RFCs for this.
E.g., in the case of SIP, see RFC 3263 & 3361.

Finally, when I raised the general issue about multiple DNS SRV names
to DNS folk, I couldn't get anyone very excited about arguing it
shouldn't be done.

So, at this point, I think its time to move on w.r.t. this topic.

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

That is my understanding.

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

I tend to agree. In -02, the algorithm was "use them in order, and
only use the next one if the SRV algorithm for the previous name
fails". That is clear in terms of what to implement. However, I
understand that this probably doesn't mesh well with an operator
advertising multiple services who hopes the client intelligently picks
one. Unfortunately, the wording in -03 leaves the client algorithm
pretty much unspecified.

> remove text about the alternatives.

I see no reason not to use separate options, per above.

Thomas