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

Thomas Narten <> Fri, 20 December 2002 15:52 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id KAA00014 for <>; Fri, 20 Dec 2002 10:52:25 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gBKFtMb23012 for; Fri, 20 Dec 2002 10:55:22 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKFtMv23009 for <>; Fri, 20 Dec 2002 10:55:22 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA29999 for <>; Fri, 20 Dec 2002 10:51:51 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gBKFqgv22964; Fri, 20 Dec 2002 10:52:42 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKFpPv22930 for <>; Fri, 20 Dec 2002 10:51:25 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA29903 for <>; Fri, 20 Dec 2002 10:47:57 -0500 (EST)
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id gBKFohZn023178; Fri, 20 Dec 2002 10:50:44 -0500
Received: from ( []) by (8.12.3/NCO/VER6.4) with ESMTP id gBKFogA7116452; Fri, 20 Dec 2002 08:50:43 -0700
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id gBKFlgj01291; Fri, 20 Dec 2002 10:47:42 -0500
Message-Id: <>
To: Paul Duffy <>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt
In-Reply-To: Message from Paul Duffy <> of "Tue, 22 Oct 2002 22:43:58 EDT." <>
Date: Fri, 20 Dec 2002 10:47:42 -0500
From: Thomas Narten <>
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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?

Also, general comment (not to single this ID out, though it occurs
here). When making changes to documents in response to issues that
have been raised (especially on the mailing list), it is generally
preferable to respond to such comments not just by saying "OK, will be
fixed in the next rev", but by saying "OK, here are the text changes I
propose -- do they look OK?"

The advantage of this approach is you get instant review/feedback on
whether the changes are ideal. I mention this here because  there was
discussion about whether to include a normative reference to the
dhc-concat draft, in the case where options are too long to fit in a
single option. There was no indication on the mailing list that this
change would be made, but there is new text to that effect in the

   {+When the total length of a CCC option exceeds 255 octets, the 
   procedure outlined in [4] SHOULD be employed to split the option into 
   multiple, smaller options.+} 
My immediate reaction to the text is that this should be a MUST, not a
SHOULD. If one goes and reads the definition of SHOULD, it say:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

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.

It would have been more efficient to have iterated on this text on the
mailing list the point the issue orignally came up. That way, we might
have avoided the need for another revision of the document. Note that
the same applies for the point above that seems to have been missed.

dhcwg mailing list