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

Thomas Narten <> Fri, 20 December 2002 18:31 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA05206 for <>; Fri, 20 Dec 2002 13:31:40 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gBKIYb232154 for; Fri, 20 Dec 2002 13:34:37 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKIYbv32151 for <>; Fri, 20 Dec 2002 13:34:37 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA05153 for <>; Fri, 20 Dec 2002 13:31:08 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gBKIWEv31929; Fri, 20 Dec 2002 13:32:14 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKIVgv31890 for <>; Fri, 20 Dec 2002 13:31:42 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA04873 for <>; Fri, 20 Dec 2002 13:28:14 -0500 (EST)
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id gBKIV6Zn012414; Fri, 20 Dec 2002 13:31:06 -0500
Received: from ( []) by (8.12.3/NCO/VER6.4) with ESMTP id gBKIV5A7091834; Fri, 20 Dec 2002 11:31:05 -0700
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id gBKIS4o02210; Fri, 20 Dec 2002 13:28:04 -0500
Message-Id: <>
To: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt
In-Reply-To: Message from Paul Duffy <> of "Fri, 20 Dec 2002 12:47:08 EST." <>
Date: Fri, 20 Dec 2002 13:28:04 -0500
From: Thomas Narten <>
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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