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

Paul Duffy <> Wed, 23 October 2002 02:45 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id WAA13224 for <>; Tue, 22 Oct 2002 22:45:18 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g9N2lCR23009 for; Tue, 22 Oct 2002 22:47:12 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9N2lCv23006 for <>; Tue, 22 Oct 2002 22:47:12 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA13217 for <>; Tue, 22 Oct 2002 22:44:47 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g9N2j5v22948; Tue, 22 Oct 2002 22:45:05 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g9N2iEv22891 for <>; Tue, 22 Oct 2002 22:44:14 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA13106 for <>; Tue, 22 Oct 2002 22:41:48 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA13239; Tue, 22 Oct 2002 22:43:59 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Oct 2002 22:43:58 -0400
To: Thomas Narten <>
From: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-03.txt
In-Reply-To: <>
References: <Message from Paul Duffy <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


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


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



Paul Duffy
Cisco Systems, Inc.

dhcwg mailing list