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

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 20 Dec 2002 16:42:41 -0700

Folks,

>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?  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.

I wish there was a way to balance IETF's needs to review new suboptions, and
CableLabs needs to define new suboptions in a timely fashion.

I appreciate the fact that the IETF process allowed the CCC option draft to
be cleaned up in many respects (e.g. removing unneeded port numbers, using
DHCP option concatenation).

At the same time, the IETF process has been relatively slow, compared to
CableLabs timelines. Obviously a major part of the problem has been the way
the draft was managed -- started in March 2000, suffered long time gaps
between drafts, and allowed to expire. But the draft has been fairly
actively managed since August 2002 by its two co-authors (one might disagree
with their positions, but they have tried to be responsive). If the IESG
were to approve the draft in January 2003 and the RFC editor were to publish
in March 2003 (being only a little optimistic), that's still seven months
since active management -- that's not including the original write-up time.
I wonder whether a new suboption could be realistically documented,
approved, and published using the standard IETF process within six months.

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.

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

One very messy way to balance between the polar extremes would be that
CableLabs throws new experimental suboptions into its non-IETF-endorsed
option 177, which suboptions might be ignored or redefined in IETF-endorsed
CCC option. But the result is that PacketCable devices and DHCP servers that
were serious about the cable market (because they worry about backward
compatibility with now-obsolete CableLabs suboptions) would need to
implement both option/suboption codes forever.

I think we would suffer the same results if some of the CCC suboption space
was dedicated to CableLabs-experimental use.

Can someone propose something better?

-- Rich

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

---

From: Thomas Narten <[email-masked]>
Date: Sat, 21 Dec 2002 10:56:06 -0500

> I wish there was a way to balance IETF's needs to review new
> suboptions, and CableLabs needs to define new suboptions in a timely
> fashion.

I agree. I am still under the assumption that this is achievable.

> I appreciate the fact that the IETF process allowed the CCC option
> draft to be cleaned up in many respects (e.g. removing unneeded port
> numbers, using DHCP option concatenation).

> At the same time, the IETF process has been relatively slow,
> compared to CableLabs timelines. Obviously a major part of the
> problem has been the way the draft was managed -- started in March
> 2000, suffered long time gaps between drafts, and allowed to
> expire. But the draft has been fairly actively managed since August
> 2002 by its two co-authors (one might disagree with their positions,
> but they have tried to be responsive). If the IESG were to approve
> the draft in January 2003 and the RFC editor were to publish in
> March 2003 (being only a little optimistic), that's still seven
> months since active management -- that's not including the original
> write-up time.  I wonder whether a new suboption could be
> realistically documented, approved, and published using the standard
> IETF process within six months.

I believe it can. IMO, part of the issue here with cablelabs options
in particular is a startup issue. We only in August really seriously
looked at this document. A number of substantive (and general) issues
were raised and have been mostly resolved. (Note also, some of these
issues come from bad experiences that have been had in the IPCDN WG,
where cablelabs is the main player. I do not believe we can ignore
those experiences and just do as has been done in the past, without
risking that we are setting ourselves up for failure.)  I expect we
both have a much better understanding of the needs of the other body,
and are in a much better position to move quickly on future documents.

Note also, I don't think the delay between IESG approval and RFC
publication is a real issue. (If it is we should chat more.) I've been
led to understand is that the issue is IESG approval of the document,
and IANA assignment of the code points. IANA assigns the code point
more-or-less immediately after IESG approval of a document (this can
be expedited if it is known to be critical). So the key issue is IESG
approval of the document.  BTW, despite my grumbling in earlier
posting, I did go ahead and put the document in the next IESG telechat
(scheduled for next week) so we can hopefully work out the last issues
and get IESG review in parallel. So I think we are still quite capable
of getting the document approved in January.

> 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.

> was dedicated to CableLabs-experimental use.

Key point: it is the notion that cablelabs takes a pre-finalized
version of an option and effectively makes it a standard that is
unchangable in practice that is the root problem (this *exact* issue
has been a repeating problem in the IPCDN WG). Once you ship
something, it becomes *much* harder to modify the option. People say
"its not worth it". "We can't change what is already deployed". It is
*this* *issue* we need to avoid. We need to get options finalized and
through the process prior to them become de facto standards on the
cablelabs side. If we can't do that, we might as well just give up.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Dec 2002 10:20:59 -0500

As a way of getting more timely coordination between CableLabs and the 
IETF, would it be possible to involve the IETF earlier in the process of 
developing an option?  That is, as soon as CableLabs identifies the need 
for a new sub-option, publish an Internet-Draft describing that sub-option 
and bring it to the IETF/DHCWG.  Development can take place in parallel - 
Internet-Drafts are cheap - so that the WG has a chance to review the new 
option and can be prepared to bring it to last call as soon as the 
CableLabs change control process has the new specs in place.

- Ralph