Subject: [dhcwg] bcmc status and issues

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

As was discussed in the wg meeting, a lot has changed in the bcmc
draft since it passed wglc, and there are several outstanding
issues. Here is my take on the status and the remaining issues.

The two drafts draft-ietf-dhc-bcmcv4-option-00.txt and
draft-ietf-dhc-bcmcv6-option-00.txt passed wglc in February.

They were replaced by a common draft
draft-ietf-dhc-bcmc-options-00.txt at end of March. Later in
May, June and August we got rev 01, 02 and 03 resp. See
http://tools.ietf.org/wg/dhc/draft-ietf-dhc-bcmc-options/ for
diffs.

draft-ietf-dhc-bcmc-options-01.txt through IETF LC in June.

Thomas Narten posted his review comments of 01 to DHC list
June 16th. Version 02 was made to address those.

Elwyn Davies reviewed 01 and 02 June/July and had a number
of issues. I'm sending that in a separate mail. There is
also an additional mail I will forward from Elwyn after
talking to author this last IETF.

I'm also posting a mail from Kuntal Chowdhury where he
lists the issues and resolutions in 03.

Below are the main outstanding issues / discussion points I'm
aware of. See also the i-d tracker. In addition Ralph and I
have some minor issues (I think just typos and minor textual
improvements), but the below issues are what I think we need
to discuss at this point.

I1 FQDNs

   Should FQDNs be allowed and is it ok to have multiple? If
   FQDNs are allowed, is it okay using two different option
   codes as proposed?

I2 Clarifications regarding MAYs/SHOULDs

   From mail from Brian Carpenter:

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

Stig

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Sep 2005 15:20:50 -0400

FWIW, I've been fairly heavily involved in the changes leading to
-02. I had a number of review comments on -01 that got put into -02.

-03 is in response to the IESG comments.

Modulo the issues that were raised on the -02 draft during IESG
review, I think this document is ready to go. (I'll comment on those
issues separately.)

Indeed, 3GPP2 needed this some time ago, so it would really be good to
get closure and move on.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 20 Sep 2005 15:59:37 -0400

Stig posted e-mail to the dhcwg mailing list a few days ago with some
outstanding issues:

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05371.html

He also posted a status summary from Kuntal:

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05370.html

I also have a specific comment about one of Kuntal's comment:

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

There is, in fact, the equivalent of the DHCPv6 ORO is the DHCPv4
"Parameter Request List" (code 55).

- Ralph