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

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

Thomas,

(Reminder: this discussion is about defining future CCC sub-options, e.g.
about the IANA Considerations for draft-ietf-dhc-packetcable-05.txt)

The 30-day clock on the CableLabs change control process can be reset for
major changes, so everything at CableLabs does not have to be decided in 30
days.

It would not have been realistic for all the changes embodied in
draft-ietf-dhc-packetcable-04.txt to be approved in one CableLabs 30-day
review cycle, which is why I stated:

> The ECx timeframe doesn't sound realistic in an IETF setting, and in
> fact might be a non-goal.

It might be more realistic for the (theoretical) definition of an additional
CCC sub-option to be approved by CableLabs in 30 days -- especially if the
sub-option were an obvious solution, a "no-brainer" if you will. That was
the real concern from my email.

But let's talk about the real CableLabs milestones, which revolve around
product certification waves. Here are two sources for such information:

<http://www.cablemodem.com/downloads/2003_Certification_Schedule.pdf>

<http://www.ipcdn.org/milestones.html> -- please focus on the Certification
Wave dates here

Note that the ECR (Engineering Change Request) cut-off date from the second
link above is 30 days before the ECN (Engineering Change Notice) acceptance
date from the first link above. This is the effect of the CableLabs change
control process 30-day clock. The ECR is written at the beginning of the
change control process, and the ECN is the output of the change control
process.

Once a cable-related internet-draft is IESG-approved and has IANA-assigned
numbers (e.g. option and sub-option codes), then someone in the CableLabs
community writes and submits an appropriate ECR, which would presumably be
approved and issued as an ECN 30 days later.

The base CableLabs specifications plus the ECNs form the requirements for
CableLabs product certification. CableLabs will not certify equipment in a
particular wave, unless it meets the requirements from the ECNs that apply
to that wave. That's how cable vendors are motivated to implement
requirements in their products -- and also why they are motivated to review
ECRs within the 30-day window.

As you can see from the CableLabs milestones, if a particular ECR/ECN
deadline is missed, we suffer a 4-5 month delay on product implementation
and deployment. That's why CableLabs would be concerned about timeliness in
specification approvals.

Hope this helps in our mutual understanding of approval processes.

-- Rich

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Saturday, December 21, 2002 10:56 AM
To: Woundy, Richard
Cc: 'Paul Duffy'; [e-mail]
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt

[snip]

> The comparison would be to the CableLabs Change Control process
> (e.g.  ECR/ECO/ECN), in which a change request is typically reviewed
> and approved by vendors and operators in a 30-day window. The
> vendors are motivated to review such changes in a timely fashion
> because it immediately impacts the requirements on products that
> they produce. However, the CableLabs vendor/operator community often
> does not have the same technical experience as the IETF audience.

Are you really saying that the time from initial proposal until the
time the spec is finalized is 30 days? I have a hard time believing
that. What exactly is "change request" above, and what sorts of
changes are allowed? It is one thing to make minor changes, like
fixes. It is probably something very different to add something
completely new.

> The ECx timeframe doesn't sound realistic in an IETF setting, and in
> fact might be a non-goal.

It is critical that the timeline requirements of cablelabs be exported
to the IETF and that the IETF understand what they are. One problem
has been that there has been (and still continues to be) confusion
about what the real deadlines are. *If* we had firm timelines to look
at, we could make a realistic assessment of whether the IETF can do
its part within that time frame. We (the WG) can then commit to
meeting those needs. This is quite possible, so long as we have a
clear understanding of the timelines and we *both* agree to execute on
a *realistic* plan.

[snip]

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