[dhcwg] Re: draft-ietf-dhc-packetcable-02.txt

At 03:13 PM 7/29/2002 -0400, Thomas Narten wrote:
>Hi.
>
>I understand there is a need to get this document finished very
>quickly in order to get it into an RFC.
>
>Please respond to the messages posted to the mailing list quickly. I
>fear this document may need a bit of work, as parts of it are hard to
>follow, and I am not sure about the soundness of some aspects of the
>ID.
>
>We need quick discussion and resolution if this document is going to
>be completed in time for the August Cablelabs deadline.
>
>Thomas

Folks,

In the spirit of Thomas' original request, I'd like to propose the 
following steps so we can close this out soon...

1. We'll add text, something like the following, near the beginning of the I-D:

"Cablelabs client devices will issue DHCP requests that include options 55 
and 60.  Option 55 will request the CCC option from the DHCP 
server.  Option 60 will specify the specific Cablelabs client type, thus 
directing the DHCP server to populate specific CCC sub-option content in 
its responses.  The details of which CCC sub-options are populated for each 
specific client type are spelled out in the various Cablelabs project 
specifications.  For example, the PacketCable MTA Device Provisioning 
Specification [ref] defines the specific set of CCC sub-options that must 
be populated in DHCP responses to CMs and MTAs in a PacketCable deployment."

2. We'll change the description of sub-option 6 from "The Kerberos Realm 
name is an FQDN" to "The Kerberos Realm name is formatted per RFC 1510".

3. Regarding the optional port numbers on sub-options 1-5....Cablelabs has 
confirmed that we have to have this capability.  For testing, for improved 
security...ultimately... because MSO's/cable operators are going to deploy 
these servers on non standard ports.  We must have a way to configure the 
devices for the non standard port.  If you disagree with our proposals, we 
ask that you please enlighten us re: a specific alternative.

4. Assuming you see the need for the optional port numbers, we strongly 
prefer to stick with sub-option 4/5 as defined in the draft.  This will 
leave sub-options 1-5 more symmetrically defined and will be easier to 
implement.

5. Cablelabs will ECR any specification, referencing this I-D, to bring it 
into alignment with the RFC (when issued).  PacketCable, CableHome, 
etc.  This is normal Cablelabs procedure. We were holding off until the I-D 
made it to RFC.

I hope we can reach agreement soon.  There is important inter operability 
testing coming up at Calblelabs.

Best Regards,

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

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