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

["Woundy, Richard" <[e-mail]>]

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:[e-mail]]
Sent: Saturday, December 21, 2002 10:48 AM
To: Paul Duffy
Cc: [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg