headers
Jean-Francois Mule | 8 Mar 2003 00:23
Favicon

RE: Dscp and DscpOrAny TCs

> 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
I second Rich's point above.
The cable industry and CableLabs have made tremendous efforts to adopt a
higher net citizen profile in working *with* IETF (of which some of us
"cable" engineers feel a part of and have been a part of in previous
lifes).

Jean-Francois Mule, the other IPCDN Co-Chair
_______________________________________________
diffserv mailing list
diffserv <at> ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
Permalink | Reply |
headers
Woundy, Richard | 8 Mar 2003 00:15
Picon

RE: Dscp and DscpOrAny TCs

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 <at> lucent.com]
Sent: Friday, March 07, 2003 1:32 PM
To: Andrew Smith; 'Wijnen, Bert (Bert)'
Cc: diffserv <at> ietf.org; Woundy, Richard; jf.mule <at> cablelabs.com;
(Continue reading)

Permalink | Reply |
headers
Wijnen, Bert (Bert | 7 Mar 2003 19:31
Picon
Favicon

RE: Dscp and DscpOrAny TCs

Inline

> -----Original Message-----
> From: Andrew Smith [mailto:ah_smith <at> acm.org]
> Sent: vrijdag 7 maart 2003 17:45
> To: 'Wijnen, Bert (Bert)'
> Cc: diffserv <at> ietf.org; Richard_Woundy <at> cable.comcast.com;
> jf.mule <at> cablelabs.com; narten <at> us.ibm.com; erik.nordmark <at> 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
(Continue reading)

Permalink | Reply |
headers
Wijnen, Bert (Bert | 7 Mar 2003 11:57
Picon
Favicon

RE: Dscp and DscpOrAny TCs

Andrew,

Sure.... and what I am doing here is not the ideal solution,
but clearly I am trying to get various solutions aligned
as much as possible (you have seen my issues raised
for common definitions for Dscp, DscpOrAny, FlowLabel,
FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc.

In the case of DOCSIS, the original stuff got developed
outside IETF. They now try to bring their stuff under the
IETF umbrella. We could tell them to drop/ditch all their own
stuff and start from scratch... which I suspect will not work,
or we can try to get them aligned as much as possible without
making them start from scratch.

I think I am on the latter path...
Are you suggesting we (IETF) should be on the former path?

Just trying to understand what you are urging us to do.

Thanks,
Bert 

> -----Original Message-----
> From: Andrew Smith [mailto:ah_smith <at> acm.org]
> Sent: woensdag 5 maart 2003 21:42
> To: Bert Wijnen
> Cc: diffserv <at> ietf.org; Richard_Woundy <at> cable.comcast.com;
> jf.mule <at> cablelabs.com; narten <at> us.ibm.com; erik.nordmark <at> sun.com
> Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
(Continue reading)

Permalink | Reply |
headers
Andrew Smith | 7 Mar 2003 17:44
Picon
Favicon

RE: 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? 

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.

[Note that, for this particular example of filter/pattern-matching on IP
packets with DSCPs, I'd originally proposed a separate generic MIB
module (included a "sixTupleClassifier" table) for the reason of making
it clear that this was general purpose and should be used by other MIBs,
(Continue reading)

Permalink | Reply |

Gmane