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

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Nov 2004 16:46:56 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Nov 2004 16:11:25 -0800

On Wed, Nov 24, 2004 at 04:46:56PM -0500, Ralph Droms wrote:
> supported without code changes to existing servers?

Speaking for ISC DHCP;

Of draft-chowdury-dhc-bcmcv4-option-1, section 4.2 can be supported
easily today by our server.  Section 4.1 could be made to perform as
documented in the draft, without modifying code, but the configuration
syntax would be somewhat awkward.

> Use of a VIVSO

Versions of ISC DHCP Server currently in wide deployment could
support VIVCO/VIVSO today, with some trickier than usual
configuration (oddly similar to what would have to be done for
section 4.1).

With one disclaimer:  It would not work well at all for multiple
vendor ID's.

In order to support multiple vendors, you would have to statically
configure responses for every possible combination of VIVCO contents
that you expect to receive (either the VIVCO contents would have to be
consistent on every boot, which when I glanced I think is not mandated
by the RFC, or you would have to interpolate every possible combination
and every subsequent response and provide them all in configuration).

So, I think it could be made to work, but the level of difficulty does
present a significant barrier to adoption, not to mention the lack of
scalability to multiple enterprise id's, which makes this approach,
at least for ISC DHCP, less and less appealing the more vendors get
on board.  This makes it seem unfair to ask 3GPP2 to go this route
when it would be less likely that we would ask anyone else to follow
them.

Beyond this, ISC has not, today, laid down the schedule framework for
the next feature release of ISC DHCP which may or may not contain
formal support for RFC3925.  So, I cannot accurately answer the question
of how long it would take to reach deployment, which suggests we should
estimate my answer to be an infinite value.

So I would promote the approach of the current v4 draft.

-- 
David W. Hankins		"If you don't do it right the first time,
Operations Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Nov 2004 17:30:41 -0700

I think the working group has pretty much agreed to go forward with 
Vendor Identified Vendor Specific suboptions, so on a practical level 
it seems like a mistake not to use it.   Either we want to do things 
that way, or we don't, and it seems like the consensus is that we do.   
Hacking the ISC server to support these options isn't particularly 
hard; if somebody really wants it before you have time to do it, they 
can always implement it themselves and send you patches!

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 29 Nov 2004 10:56:30 -0800

> that way, or we don't, and it seems like the consensus is that we do.   

We do, I agree completely with that.

> can always implement it themselves and send you patches!

Do not mistake my statement as a condemnation against adopting
VIVSO, I merely am not able to provide accurate information about
what may appear in an upcoming ISC DHCP feature release at this
particular moment in time, or even when that will be.

Due to the size and content of the feature request list, we are
going to have to spread them out over several releases.  It is not
clear to me that VIVSO will make the next feature release.

Mr. Droms was indicating a need for urgency.  I hope to rectify my
ignorance about our release schedule soon, and will correct myself
if that information is still useful to the workgroup.

But at this particular moment in time, I am unable to promote VIVSO
as the mechanism for this draft.