Re: [dhcwg] DHCP Option for CableLabs Client Configuration

[Paul Duffy <[e-mail]>]

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]




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