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

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