[dhcwg] draft-chowdhury-dhc-bcmcv[46]-option-01.txt

Ralph Droms <rdroms@cisco.com> Fri, 21 January 2005 21:50 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26091 for <dhcwg-web-archive@ietf.org>; Fri, 21 Jan 2005 16:50:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6w4-000301-0M for dhcwg-web-archive@ietf.org; Fri, 21 Jan 2005 17:07:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6Hz-0000uK-Tj; Fri, 21 Jan 2005 16:25:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5xD-0003Bm-4x for dhcwg@megatron.ietf.org; Fri, 21 Jan 2005 16:04:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19023 for <dhcwg@ietf.org>; Fri, 21 Jan 2005 16:04:25 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6D9-0000KS-AM for dhcwg@ietf.org; Fri, 21 Jan 2005 16:20:56 -0500
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 14:11:55 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0LL3pNt014797; Fri, 21 Jan 2005 13:03:52 -0800 (PST)
Received: from rdroms-w2k01.cisco.com ([161.44.65.140]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AON04484; Fri, 21 Jan 2005 16:03:49 -0500 (EST)
Message-Id: <4.3.2.7.2.20050121155629.0ca5b140@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jan 2005 16:03:48 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: margaret@thingmagic.com, narten@us.ibm.com, Stig Venaas <Stig.Venaas@uninett.no>
Subject: [dhcwg] draft-chowdhury-dhc-bcmcv[46]-option-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

As we have been asked to expedite our review of these drafts for the
upcoming 3GPP2 standard, I want to start a WG discussion on the these two
drafts.  Please review the drafts and post comments, especially in the areas
outlined below.  It would be especially helpful to know if 3GPP2 has
considered the use of VIVSO (RFC 3925) for these options, or if there are
concrete requirements for the same server information to be passed through
DHCP in other standards.

- Ralph

=====
(original e-mail, 2004-11-24)

The dhc WG has been asked to consider two drafts,
draft-chowdhury-dhc-bcmcv4-option-01.txt and
draft-chowdhury-dhc-bcmcv6-option-01.txt, for acceptance as WG work
items.  There has been some discussion of these two drafts, starting
at http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04124.html.

There has been no objection to the primary purpose of these drafts,
and the discussion has focused on whether the options defined as in
the two drafts or should they be redefined to be carried as
vendor-identifying vendor-specific options.  As we have a fairly tight
deadline for moving forward on these drafts, I have decided to accept
the drafts as WG work items.

We still need to come to consensus as to the decision about how to
define the options.  Reiterating from my previous e-mail about the
options, here are some considerations for discussion:

3GPP2 has defined some vendor-specific sub-options, for example, to
identify a MIP home agent for the DHCP client.

A 3GPP2 client needs to specify to the DHCP server which parameters it
needs - specifically, whether it needs to receive the BCMCS servers.
If the current drafts are adopted, the client can simply use the
parameter request list option (option code 55) for the request.  If a
VIVSO sub-option is used, 3GPP2 would also define a parameter request
list sub-option.

There is a deployment issue, as some service providers already have
DHCP servers in place that must be updated for any new options.  Is it
the case that the options defined in the current drafts can be
supported without code changes to existing servers?  Use of a VIVSO
sub-option would require code changes to existing servers.  How long
would it take to deploy DHCP server that can support VIVSO.

BCMCS may be adopted across multiple technologies, so the options in
the current drafts would not be specific to 3GPP2.  However, the BCMCS
specification has not adopted by other standards, yet, so we may need
to define additional options for related services in the future if
those services are not interoperable with the 3GPP2 BCMCS service.

- Ralph

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg