Re: [dhcwg] DHCP Option for CableLabs Client Configuration

Thomas Narten <narten@us.ibm.com> Tue, 30 July 2002 19:23 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05746 for <dhcwg-archive@odin.ietf.org>; Tue, 30 Jul 2002 15:23:19 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20097 for dhcwg-archive@odin.ietf.org; Tue, 30 Jul 2002 15:24:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19952; Tue, 30 Jul 2002 15:21:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19921 for <dhcwg@optimus.ietf.org>; Tue, 30 Jul 2002 15:21:02 -0400 (EDT)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05635 for <dhcwg@ietf.org>; Tue, 30 Jul 2002 15:19:52 -0400 (EDT)
Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6UJKdNv013244; Tue, 30 Jul 2002 15:20:39 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6UJKc7j034100; Tue, 30 Jul 2002 13:20:38 -0600
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g6UJJeM08693; Tue, 30 Jul 2002 15:19:40 -0400
Message-Id: <200207301919.g6UJJeM08693@rotala.raleigh.ibm.com>
To: Paul Duffy <paduffy@cisco.com>
cc: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, "'Ralph Droms'" <rdroms@cisco.com>, dhcwg@ietf.org, nrussell@cisco.com, pgrossma@cisco.com, Matt Osman <M.Osman@cablelabs.com>
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration
In-Reply-To: Message from "Tue, 30 Jul 2002 12:48:58 EDT." <4.3.2.7.2.20020730104742.028c65d8@funnel.cisco.com>
Date: Tue, 30 Jul 2002 15:19:40 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> We could add a paragraph or two describing, in general terms, that the DHCP 
> client requests the CCC option and provide option 60 to identify its client 
> type to the server...the server then determines the CCC sub-option content 
> that would be included in responses.

This would be helpful.

> But we would defer to the specific Cablelabs specifications to
> define the exact sub-option content in the responses. How does that
> sound ?

Could you give an example? Are you talking about removing all the text
from the current ID? I'm not sure I'm in favor of that either.

> >Is there ever a reason for the MTA to use a "normal" DNS server
> >vs. the "TSP DNS"? I would assume not. Thus, the above option appears
> >redundent with the normal DHC option for identifying DNS servers. Can
> >someone clarify here if this is/is not the case?

> Again, sub-options 4 and 5 permit port numbers.  Normal DNS options
>  do not...

Some comments.

First, let's consider the case where the port number version is not
used, i.e., DNS servers are accessed at the normal port numbers. In
this case, how does this option differ from option 6 (the standard
Domain Option)? My sense (from what I understand) is they are the
same. In that case, I would say use that option and don't even define
a sub-option that allows specification of the DNS server without a
port number. No need to define a redundant option.

Second, there has apparently not been an issue in general with the
Domain Option not specifying an alternate port number, presumably
because its not required in general. Why is it required in your spec?
Just saying "it's a requirement" isn't very illuminating.

> >3) It's not immediately clear whether/how the CM uses these
> >    options. They seem specific to the MTA.  Does the CM use these
> >    options?

> Per the PacketCable specs, MTA uses sub-option 4/5.  See the provisioning 
> flows in the MTA prov spec (referenced in the draft).

I just looked at the MTA provising draft. It is not at all clear to me
that the CM needs any of these sub-options. Can you please point me to
the sections in the document that explain how the CM uses them and
what specific sub-options it uses?

> >4)
> >
> > >      |    9    |         | Reserved for future CableLabs use          |
> >
> >I find it odd that this document says "reserved", when the cablelabs
> >document pretty clearly defines this option and what it means. Please
> >clarify.

> The PacketCable MTA prov spec is incorrect.  It will be updated soon. 
> Sub-option 9's usage was dropped just prior to the draft's posting.  The 
> draft is correct and authoritative regarding sub-option 
> definitions/syntax.  Any duplication of the draft's text in the PacketCable 
> specs will soon be removed.

OK. But I will note that the classification of the document is
"ISSUED" (per the cover page), which corresponds to

     "A stable document, which has undergone rigorous member and vendor
     review and is suitable for product testing and development, cross-vendor
     interoperability, and for certification testing."

Can you clarify what the next steps for the document are and when it
will get updated?     

> Sub-options 1 and 2 are the mechanism via which the access provider
> strictly controls which business entities are permitted to offer
> telephony service over its network.  This is described in the
> PacketCable MTA prov spec.

Right. In other words, the MTA needs to use a special DNS server and
get special client-specific configuration. What I don't quite
understand is why that requires Cablelabs-specific options. This seems
(mostly) doable with standard DHCP. In that case, I'd prefer that
approach be used to just defining a bunch of specific (redundant)
options.

Specifically, if the client includes in its Discover with an "I'm a
MTA" option, and the DHC servers return an "I'm a MTA DHC server"
(which the client then selects), this is all fine and consistent with
DHC. From that point on, the MTA DHC server can send it normal
options, and those will be interpreted as the ones that the MTA should
use. You don't need a special option that says "MTA must use this DNS
server rather than the regular server".

I'd like to understand what is wrong with the above reasoning.

> Do sub-options 1 and 2 really constitute "modifying the basic DHC
> client" and "changing basic DHCP behavior"?

IMO, Yes. They modify the way the DHC client behaves. Note that DHC
clients today can select the server based on what it advertises. But
the option you've defined changes that in the following way:

  - it doesn't say "chose this server that sent you the offer", it
    seems to say "choose the server whose address is encoded in the
    sub-option". That's a very different semantic

  - or, it says, from now on, use a different port number when sending
    DHCP requests (again, a *very* different semantic).

> Cablelabs and the several dozen companies that have vetted this
> draft have absolutely no interest in anything but standard
> protocols.  There are several prototype DHCP servers and multiple
> clients running this draft.  This is the first mention that
> Cablelabs has distorted the basic DHCP protocol.

That is why it is important to get DHCP options reviewed within the
IETF, where the DHCP experts are.

> We look to the DHCP gurus for further guidance here...but PacketCable 
> requires an "iron fist" mechanism that allows the access provider to 
> control who is allowed to offer telephony service over its network.

I believe that normal DHCP does this already. I don't understand how
the proposed extensions are needed (at least in the case of the DHC
and DNS options).

> > > CCC sub-options 4/5 allow an optional port number where the standard DNS
> > > options do not.
> >
> >How important is this? Is this critical?

> Its a requirement of the PacketCable architecture.

Why? How important a requirement? Its clearly not needed in all
cases, since some forms of the option do not include a port number.

Thomas

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