RE: [dhcwg] DHCP Option for CableLabs Client Configuration

["Bernie Volz (EUD)" <[e-mail]>]

Given that duplicating a lot of work is likely to be rather useless, what about
scaling back the IETF draft to remove much of the text and just have the draft
indicate the option number and that there are suboptions and to see the CableLabs
document for complete details?

With the current draft, there's too much there to make it look like an attempt
at a more complete specification. Therefore, removing most of that material and
simply using the draft to reserve the option number might be best.

This approach also means that the IETF (IANA) is out of managing the suboption
space, but I didn't see that you really wanted that anyway. This may also be
good since it avoids lots of additional debate as to how the suboptions are used
(as I assume that is well documented in the CableLabs documents).

The WG and IESG may need to review the CableLabs document to determine whether
the usage is in line with DHCP (though I can't see why it wouldn't be).

Thomas can probably provide more guidance as to how best to proceed.

- Bernie

-----Original Message-----
From: Paul Duffy [mailto:[e-mail]]
Sent: Monday, July 29, 2002 5:01 PM
To: Thomas Narten
Cc: Bernie Volz (EUD); 'Ralph Droms'; [e-mail];
[e-mail]; [e-mail]; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration 


Thomas/Bernie,

A few points of clarification:

1. On the advice of several DHCP and Cablelabs experts, we specifically did 
not duplicate Cablelabs specification content in this draft.  We decided to 
define CCC sub-option syntax and content in the draft, with specific 
Cablelabs specifications elaborating on exactly how and when the CCC 
sub-options are used.  The idea is to avoid significant duplication of text 
and the inevitable synchronization problems that would result between 
multiple documents.

2. CableLabs specifications that employ the CCC option (PacketCable, 
CableHome, etc.) describe specific CCC option usage. CCC client devices use 
DHCP option 60 to identify the "client type" or "project", thus telling the 
DHCP server which CCC sub-options it should be populating in its responses.

At 03:10 PM 7/29/2002 -0400, Thomas Narten wrote:
>I too, just reviewed this document has have some questions/comments.
>
>I agree with Bernie that it's underspecified, and just pointing to the
>other documents is insufficient. There should be enough text in this
>document so that a DHC implementor can figure out what to do.
>
>1) It's not clear who sends/uses the options (i.e., the MTS or
>    CM).

Per comments above...this information is included in the Cablelab's 
specs.  It was decided to refer to the external spec rather than repeat the 
information in the draft.

>2) Its also not clear just what the CM does. Is it being a relay agent
>that routes DHC packets from MTA's differently than normal DHC
>packets?

No.  The CM is not specified to behave as a relay agent.

>Reading between the lines a bit, is the following happening?
>
>a) the CM boots first, and requests (and receives?) sub-options 1 & 2.

Correct, from the access provider's infrastructure...

>b) any DHC request from the MTA goes through the CM (the CM is in
>effect a relay agent) and the CM relays the DHC request to the DHC
>server it learned in step a). The CM knows when it is relaying a MTA
>option because the MTA includes a CCC option.

No.  The CM is not specified to behave as a relay agent.


>Is my understanding anywhere near correct at this point? (I have more
>questions, but the specific questions depend on whether my
>understanding is anywhere near correct at this point).
>
>c) the response from the server to the MTA includes some combination
>of the remaining suboptions.

...correct.  Sub-option content is determined by the content of option 60 
(in the request)


>3) There are some kerberos-specfic sub-options here. I wonder if they
>    make sense from the kerberos perspective (and will try to find
>    someone who can answer). Reason I say this is I'm aware of an older
>    kerberos ID that put Realm information into a  DNS RR, and the
>    realm field was NOT the same as an FQDN (as this ID says it will
>    be)

A PacketCable MTA's realm name and domain name are not the same.  A 
PacketCable deployment will typically be a large, multi vendor 
situation.  The authentication realms and domain name space are kept 
separate.

>4) Options 4 & 5 don't make sense to me immediately. Why would the MTA
>    need special DNS servers (as opposed to just using the ones through
>    it's ISP?)

The PacketCable specs draw a hard line between data access provider and 
telephony service provider.  The access provider is responsible for 
provisioning the CM, the telephony service provider provisions the 
MTA.  These two business entities are assumed to have their own DHCP and 
DNS infrastructure.


>And, why can't the normal DNS server option be used
>    here? If the MTA's DHC requests get routed to the TSP-specific DHC
>    server, it can know to return an appropriate DNS server. Why is a
>    special suboption needed?

CCC sub-options 4/5 allow an optional port number where the standard DNS 
options do not.


>5) I find it odd that there are retransmission controlling timer
>    settings being communicated via DHC. Is there something broken in
>    Kerberos that requires that standard values be overridden?

They are present to allow boot time configuration of corresponding MIB 
objects on a device.  For finer grained control....


>Thomas


I hope this helps.  Please let me know if there are any other points I 
might clarify.

Cheers,



--

Paul Duffy
Cisco Systems, Inc.
[e-mail]