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

[Thomas Narten <[e-mail]>]

Paul Duffy <[e-mail]> writes:

> RFC 2131 Section 4.4.1 "The time over which the client collects
> messages and the mechanism used to select one DHCPOFFER are
> implementation dependent".  PacketCable does not feel CCC.1/.2 in
> any way modifies the RFC.

OK, I think we're OK then. What would be good is if the words in the
document communicated clearly what is going on (at a high-level) so
its clear how the option is used (at a high-level) and that the usage
is consistent with the DHC specs.

> > >    Due to specific needs of the MTA configuration process (described in
> > >    [5]), a new CableLabs Client Configuration (CCC) option is needed for
> > >    the DHCP protocol.  Both CM and MTA DHCP clients will request this
> > >    option.  When requested, both the CM and TSP DHCP servers will
> > >    populate this option into DHCP responses.
> >
> >
> >Doesn't the client also provide this option and fill in some info?
> >better to say this above (one or two sentences here would suffice). Or
> >maybe just merge Section 9 text into the text here.

> No, an MTA DHCP client never populates CCC option content into its any if 
> its requests.  The PacketCable MTA provisioning  specification (section 7) 
> contains detailed descriptions of when the CCC option is/is not populated 
> into DHCP messaging.

> PacketCable's intent is to specify option syntax in the draft/RFC, while 
> referring to the PacketCable MTA prov specification for usage 
> details.  Otherwise, we're going to end up pulling large pieces of the 
> PacketCable provisioning spec into this draft...lots of duplication between 
> the documents (which I thought we agreed was undesirable).

Right.

> That said, I can add a sentence or two stating that the client never 
> populates CCC option content into DHCP request messages.

This is all I'm asking for. So that at a high-level one can understand
what is going on. The details can be elsewhere.

> >Should this document add a normative references to
> >draft-ietf-dhc-concat-05.txt (which has been approved by the IESG, so
> >referencing it shouldn't be a problem)? Seems like that would make
> >sense.

> If you feel inclusion of this draft is a hard requirement, PacketCable will 
> have to open this issue with the manufacturers...further delaying the 
> progress of this draft (not good for us).  I'm also going to need an RFC # 
> for the ref ?

Note: dhc-concat has been approved by the IESG, so this document
doesn't need to wait for it.

The question is, should this document require the other as well? Seems
to me like that might be useful. Hence, I asked.

> >The CCC options for configuring Kerberos parameters seems odd to me
> >(what kerberos document talks about the need for tuning these
> >parameters?). The IESG may want this reviewed by someone with kerberos
> >clue. (I'm just saying this so that there are no surprises should this
> >issue come up later.)

> This is a specific need of a PacketCable MTA.  It does not present any 
> issues with the Kerberos RFCs.  The CCC option is, by definition, Cablelabs 
> specific, so PacketCable does not see this causing any issues with non 
> Cablelabs devices.

If there are no issues with the kerberos RFCs, why do you need an
option to tune how they behave?

In terms of how to proceed, you might consider posting proposed text
for each of the items prior to reissuing the draft. That way, you're
more likely to get quick review of the new wording and that might save
on the need for an additional revision.

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