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

Paul Duffy <> Fri, 20 December 2002 19:41 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id OAA07733 for <>; Fri, 20 Dec 2002 14:41:53 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gBKJipu04012 for; Fri, 20 Dec 2002 14:44:51 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKJipv04009 for <>; Fri, 20 Dec 2002 14:44:51 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA07681 for <>; Fri, 20 Dec 2002 14:41:22 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gBKJgDv03877; Fri, 20 Dec 2002 14:42:13 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKJZ4v03005 for <>; Fri, 20 Dec 2002 14:35:04 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA07398 for <>; Fri, 20 Dec 2002 14:31:34 -0500 (EST)
Received: from (localhost []) by (8.12.2/8.12.2) with ESMTP id gBKJZ8oM029968; Fri, 20 Dec 2002 14:35:08 -0500 (EST)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03330; Fri, 20 Dec 2002 14:34:34 -0500 (EST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 20 Dec 2002 14:34:34 -0500
To: Thomas Narten <>
From: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.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: <>, <>


CableLabs/IETF seem to be down to two issues.

1. The IANA considerations section.
2. MUST/SHOULD re: RFC 3396.

I'm going to have to discuss this with Cablelabs.  I'll try to get these 
questions answered ASAP, but given the holidays...I'll do what I can.


At 01:28 PM 12/20/2002 -0500, Thomas Narten wrote:
>Oops, I didn't respond to the rest of your message. Sorry.
>Paul Duffy <> writes:
> > Hello Thomas,
> > Please be aware that a rev 5 was sent to internet-drafts and to yourself
> > several weeks still has not appeared in the DHC WG list.  It
> > looks like you're still looking at rev 4.  I will re-send the email.
> > At 10:47 AM 12/20/2002 -0500, Thomas Narten wrote:
> > >I was about to put this document back before the IESG formally, but I
> > >notice that the IANA considerations section still talks about future
> > >cablelabs suboptions being assigned via "expert review". I thought
> > >there was agreement to make this "IETF Consensus". I.e., see:
> > >
> > > 
> .html
> > >
> > >I haven't checked the other edits carefully. Is this document *really*
> > >ready for advancement, or did some other things get left out?
> > This is not my understanding.  My understanding is that early on, with
> > Ralph's guidance, we had general consensus for the text as it 
> stands.  Some
> > months later a couple questions were raised (noted above).
>Saying there was a consensus in the past, and then *not* responding to
>the issue when it is raised again saying why you don't want to make
>change is not consistent with the way the IETF works. In the thread I
>referenced, there was discussion about how to maybe deal with the
>concerns Cablelabs had.
>Ave you had a chance to look at
>draft-narten-iana-experimental-allocations-02.txt?  Does this address
>any of your concerns? (Or do I still not really understand the
>concerns behind this?)
> > Cablelabs intends to place any new sub-option additions before IETF for
> > approval (witness the recent submission of sub-option 51), but we STRONGLY
> > would prefer to be allowed to assign the sub-option codes.  It will make
> > life a bit easier for the component manufacturers, compliance
> > testing, etc.
>In other words, you want the option number for implementations before
>the ID has been reviewed and finallized by the community.  Isn't this
>what led to the situation with the current document having sat around
>for two years before it became urgent to finalize it (and then oops,
>we've already done it this way, now it's painful to change...). I'll
>note that the -00 version of this ID appeared in March of 2000.
>We really need to avoid these types of problems in the future. (And
>this is a bit of a plea to the WG in general: can we please just
>finish some of the work that is going on in this WG? Things take a
>long time becaue folks don't push for closure.)
>The right way is:
>1) propose the option
>2) get it reviewed in DHC
>3) ship the document to the IESG for approval
>4) get a code point assigned.
>None of the above needs to take years (even if we have examples to the
>contrary).  But if people think a particular document/option is
>important, then they need to drive it to closure in a timely
>fashion. I am not a fan of early assignment of code points because I
>have seen the problems this can lead to, and it futher reduces what
>little incentive there already seems to be to actually finish a
> > >In this case, if the CCC option exceeds 255, under what conditions
> > >should the SHOULD be ignored? I can't think if any right off.
> > The SHOULD resulted from discussions with the device manufacturers.  The
> > intent of the SHOULD was to accommodate devices that existed long before
> > this RFC.  By making this a MUST, these devices will be
> > non-compliant.  PacketCable has been in the works for several 
> years...early
> > field trials are starting.
>It is not generally a goal of IETF IDs/RFCs to grandfather earlier
>implementations. Doing so effectively prevents a document from
>specifying the correct behavior. Surely you see the problems here.
>Besides, how can a two year old implementation be compliant with the
>*current* version of this ID? It seems like we've made a number of
>signficant changes to it....
> > Helps ?  Please lets keep this discussion going.  With your help, I 
> want to
> > close this draft/RFC up ASAP.
>Agreed. Let's get closure and move on.
>dhcwg mailing list


Paul Duffy
Cisco Systems, Inc.

dhcwg mailing list