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

Thomas,

Inline please...

> > >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.

I assume you mean "should the CCC option require concat".  We're discussing 
this at PacketCable.

> > >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?

Several comments from various PacketCable team members:

"Kerberos-5 protocol (RFC-1510) does not define any specific backoff and 
retry algorithm. Consequently, all specifics of the backoff and retry 
mechanism for AS- and AP-exchange are defined by the PacketCable security 
spec, and involves the parameters supplied by the DHCP Server to 
parameterize the Kerberos Authentication for Provisioning Service."

Further...

"None of the subsequent IETF drafts such as Kerberos clarifications define 
it either - I don't think that a specific retry mechanism was ever 
considered to be in scope of the Kerberos IETF working group."

Thus the need for the sub-options.

>In terms of how to proceed, you might consider posting proposed text
>for each of the items prior to reissuing the draft.

Cheers,

--

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

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