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

Paul Duffy <paduffy@cisco.com> Fri, 20 December 2002 19:41 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07733 for <dhcwg-archive@odin.ietf.org>; Fri, 20 Dec 2002 14:41:53 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKJipu04012 for dhcwg-archive@odin.ietf.org; Fri, 20 Dec 2002 14:44:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJipv04009 for <dhcwg-web-archive@optimus.ietf.org>; Fri, 20 Dec 2002 14:44:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07681 for <dhcwg-web-archive@ietf.org>; Fri, 20 Dec 2002 14:41:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJgDv03877; Fri, 20 Dec 2002 14:42:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJZ4v03005 for <dhcwg@optimus.ietf.org>; Fri, 20 Dec 2002 14:35:04 -0500
Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07398 for <dhcwg@ietf.org>; Fri, 20 Dec 2002 14:31:34 -0500 (EST)
Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBKJZ8oM029968; Fri, 20 Dec 2002 14:35:08 -0500 (EST)
Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03330; Fri, 20 Dec 2002 14:34:34 -0500 (EST)
Message-Id: <4.3.2.7.2.20021220142915.02902e18@funnel.cisco.com>
X-Sender: paduffy@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 20 Dec 2002 14:34:34 -0500
To: Thomas Narten <narten@us.ibm.com>
From: Paul Duffy <paduffy@cisco.com>
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt
Cc: dhcwg@ietf.org
In-Reply-To: <200212201828.gBKIS4o02210@rotala.raleigh.ibm.com>
References: <Message from Paul Duffy <paduffy@cisco.com> <4.3.2.7.2.20021220115411.02af9638@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

Thomas,

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.

Cheers,

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 <paduffy@cisco.com> writes:
>
> > Hello Thomas,
>
> > Please be aware that a rev 5 was sent to internet-drafts and to yourself
> > several weeks back...it 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:
> > >
> > >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416 
> .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
>document.
>
> > >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.
>
>Thomas
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

--

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


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