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

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

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

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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg