RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Mon, 23 December 2002 21:27 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 QAA15568 for <dhcwg-archive@odin.ietf.org>; Mon, 23 Dec 2002 16:27:09 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNLUhE04356 for dhcwg-archive@odin.ietf.org; Mon, 23 Dec 2002 16:30:43 -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 gBNLUhv04353 for <dhcwg-web-archive@optimus.ietf.org>; Mon, 23 Dec 2002 16:30:43 -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 QAA15526 for <dhcwg-web-archive@ietf.org>; Mon, 23 Dec 2002 16:26:37 -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 gBNLSUv04272; Mon, 23 Dec 2002 16:28:30 -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 gBNLMGv04140 for <dhcwg@optimus.ietf.org>; Mon, 23 Dec 2002 16:22:16 -0500
Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15439 for <dhcwg@ietf.org>; Mon, 23 Dec 2002 16:18:10 -0500 (EST)
Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id gBNLL5CH019768; Mon, 23 Dec 2002 14:21:05 -0700 (MST)
Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 23 Dec 2002 14:21:02 -0700
X-Server-Uuid: 43374831-6ABA-4273-9165-009ABBFC7FBB
Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <ZDJHCM2M>; Mon, 23 Dec 2002 14:21:01 -0700
Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD01A@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: 'Thomas Narten' <narten@us.ibm.com>, Paul Duffy <paduffy@cisco.com>
cc: dhcwg@ietf.org
Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt
Date: Mon, 23 Dec 2002 14:20:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1219A1B4231847-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Thomas, I think I agree with the main points of your email below. First, I agree that it is unreasonable for CableLabs to define a new option/sub-option, to choose a option/sub-option code, to mandate implementation of that option/sub-option in certified products -- and then later to take that specification and to expect to have it rubber-stamped by an IETF working group. That is a waste of time for everyone involved. Second, I agree that the correct direction is for CableLabs to submit drafts for IETF critical review and blessing -- before it is required in certified products. This direction may be sometimes painful culturally for the CableLabs community, but the "pain" should enable the industry to specify new features in a better long-term way (e.g. not having to re-specify the same features). I think our point of divergence is about maintaining some flexibility for CableLabs. Let's suppose, hypothetically, that someone discovers that the cable industry need an additional CCC suboption right now, and writes and submits a new draft today. Also consider the current CableLabs calendar, <http://www.cablemodem.com/downloads/2003_Certification_Schedule.pdf>. If the new draft isn't approved by IANA before February 12th (which I believe is incredibly aggressive), then CableLabs would not certify any products in compliance with the new draft before November 17th, which would imply no significant cable deployments until 2004. If the draft represents a nice-to-have feature, then this delay might be acceptable. If the draft represents an emergency item that would otherwise prevent VoIP over cable deployments in 2003, then the delay would be crushing. For an emergency extension, I can imagine these two possible responses: - CableLabs and the IETF/IESG would work on this draft in "emergency mode" to make a very aggressive date. That seems to be pushing to the limits on an all-volunteer organization such as the IETF. It also begs the question about whether CableLabs and the IETF would agree about what constitutes an "emergency". - CableLabs could define its own interim extension, perhaps with some help from the IETF. The IETF/IESG would approve the draft on its own timetable, on its own terms (e.g. likely changing syntax and option codes). CableLabs vendors in the future would have to support both the CableLabs extension (backward compatibility) and the IETF draft/RFC extension for product certification -- until the CableLabs extension is phased out. Note that the CableLabs vendor implementation penalty for not working through the IETF process would be to implement two similar mechanisms (e.g. two sub-options) for the same extension. That would provide incentive to work as early as possible through the IETF as part of the normal specification process. I hope you see where I am going with this... -- Rich -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Saturday, December 21, 2002 10:48 AM To: Paul Duffy Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt > Is the intent here that IETF wants to insure the sub-option number DOES > change (from experimental to official) when a CCC sub-option draft reaches > RFC? The intent is that the option be reviewed by the community and finalized *before* it becomes either a de facto standard, or one that cablelabs has made a standard through its certification waves. Once it is in effect a standard, - there is little incentive to finish the document - reasonable requests to change the option are rejected as "too late, it's already implemented" - the WG is stuck with a document they may not like, but that they can't do anything about. This is not the way we get good options defined. What we need to figure out how to do is get the IETF to review/bless the option *before* it is needed by cablelabs. > Forcing a change in the implementations? If that is the case, then > this discussion is over and Cablelabs will need to agree to your proposal. Note, the "change" we are talking about is potentially very minor. Just use a different option number. If it is known in advance that it will change, software can be designed to allow it to be changed later. My real concern with the above is the sense that "we can't change even the option number", which to me means that if the IETF asks for changes in the option, its too late as well, since such changes would be even *more* work to make. Right? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Ted Lemon
- Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Thomas Narten
- Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Thomas Narten
- Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Ralph Droms
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt Ted Lemon
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Woundy, Richard
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Jean-Francois Mule
- RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt Jean-Francois Mule
- Re: [dhcwg] draft-narten-iana-experimental-alloca… Thomas Narten