RE: [Diffserv] Dscp and DscpOrAny TCs

["Woundy, Richard" <Richard_Woundy@cable.comcast.com>]

Folks,

The motive for most cable folks coming to the IETF is to collaborate on
standards documents between IETF and cable industry experts, that adhere to
the IETF architecture and meet the engineering requirements of the cable
industry. Sometimes that means that folks extend the IETF architecture model
due to considerations that are found first in (and are possibly unique to)
the cable industry. Sometimes that means the cable industry adopts output
from other IETF groups in place of ad-hoc cable industry solutions.
Sometimes we agree not to collaborate -- after all, DOCSIS is supposed to be
a layer two protocol. ;^)

The IPCDN WG as a whole, and this chair in particular, understands that the
IETF owns change control for its drafts and RFCs. That doesn't mean that
folks in IPCDN will never object to changes -- but is that really unique to
this WG?

What Bert says below is all we can ask for from the IETF:

>From my point of view, we will not just accept everything and rubber stamp.
>But I also understand that we have to be practical and that we do not just
>want to make them start from scratch just for the fun of it.

-- Richard Woundy, IPCDN Co-Chair

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, March 07, 2003 1:32 PM
To: Andrew Smith; 'Wijnen, Bert (Bert)'
Cc: diffserv@ietf.org; Woundy, Richard; jf.mule@cablelabs.com;
narten@us.ibm.com; erik.nordmark@sun.com
Subject: RE: [Diffserv] Dscp and DscpOrAny TCs


Inline

> -----Original Message-----
> From: Andrew Smith [mailto:ah_smith@acm.org]
> Sent: vrijdag 7 maart 2003 17:45
> To: 'Wijnen, Bert (Bert)'
> Cc: diffserv@ietf.org; Richard_Woundy@cable.comcast.com;
> jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com
> Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
> 
> Bert,
> 
> When you say "bring their stuff under the IETF umbrella", are you saying
> that the original MIB in question was developed outside of IETF and is
> being brought in, or are you talking about the link technology itself? 
> 
As far as I understand it, several (if not all) of the MIB modules 
(quite a few) have been developed in cablelabs context, and in fact
have been implemented at a large scale.

> If the latter, then I think the older IEEE802/IETF cooperation model on
> MIBs works OK - there you had an IETF WG (bridge, maumib, ifmib etc.)
> defining SMI MIBs under IETF root OID and having WG contributors make
> sure that adequate coordination happened; a newer model where IEEE802
> has defined some of its own SMI MIBs has also been working OK (e.g. Link
> Aggregation MIB from IEEE802, defined under IEEE802's own root OID). 
> 
> For the former case, what I don't think works is to have a MIB defined
> outside of IETF and then brought to the IETF for some reason. What would
> be the reason to do that? for IETF endorsement, for having IETF fixing
> things that are broken, just to use the IETF root OID? I don't know the
> specific reasons in this case for how this work got here. But it's
> obvious to me that, if you bring existing work to IETF for
> standardisation, be it the work of another standards' group, an industry
> group or individual contributions, *you give up change control* and you
> do not get any guarantees of backwards-compatibility: naturally you
> don't expect gratuitous non-compatibility with earlier work - the WG
> needs a valid reason to change something and one such reason would be
> alignment with other IETF MIBs.
> 
I think that is all understood. 
But I will leave it to Rich and JeanFrancois to answer the exact motives
for coming to IETF.