[no subject]

By the way, quite a bit of the discussion about the Dscp, DscpOrAny,
VlanID and VlanIDOrAny is also an issue for MIB modules from the past
from IETF WGs.

> [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,
> including the Diffserv MIB. However, in the end, it was decided to merge
> it into the main Diffserv MIB module (it became the
> "diffServMultiFieldClfrTable" in RFC3289 - maybe it is less visible
> there but maybe ADs can do something to raise awareness of its presence
> amongst other WGs].
> 
That is why I DID ask the question to IPCDN WG, did you guys look at the
other filter tables that we already have in the IETF.

Bert
> 
> Andrew Smith
> 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Friday, March 07, 2003 2:57 AM
> To: Andrew Smith; Bert Wijnen
> 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
> 
> 
> 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@acm.org]
> > Sent: woensdag 5 maart 2003 21:42
> > To: Bert Wijnen
> > 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
> > 
> > 
> > I've not been following the DOCSIS MIB work closely and 
> don't know the
> > context in which this MIB was developed. That said, 
> shouldn't IETF be
> > promoting the use of generic, already-standards-track 
> > solutions, instead
> > of trying to police each new reincarnation of the same 
> thing? It would
> > have been nice if, given that this MIB is a work item of an 
> > IETF WG, the
> > IESG had put in some provision in the WG charter about re-use of
> > existing IETF work where appropriate, rather than reinventing 
> > the wheel
> > (which this looks like - see my first sentence above 
> though). Granted,
> > there is a choice of almost-equivalent wheels for packet
> > matching/filtering in the IETF standards-track repertoire but 
> > that's not
> > an argument for creating yet another one.
> > 
> > This is one aspect of the general IETF process issue of how 
> to ensure
> > that appropriate "subject matter experts" are available to a WG that
> > needs them, even when that subject matter's own WG is no longer
> > existent: the more generic the solutions that IESG steers us to, the
> > less this maintenance problem will be.
> > 
> > Reuse of already-defined MIB ojects/tables is also one of the issues
> > that an SMIng should try to make easier (and people have been 
> > looking at
> > doing this, I believe).
> > 
> > Andrew Smith
> > 
> > 
> > -----Original Message-----
> > From: diffserv-admin@ietf.org 
> > [mailto:diffserv-admin@ietf.org] On Behalf
> > Of John Schnizlein
> > Sent: Wednesday, March 05, 2003 9:29 AM
> > To: Wijnen, Bert (Bert)
> > Cc: diffserv@ietf.org
> > Subject: Re: [Diffserv] Dscp and DscpOrAny TCs
> > 
> > 
> > Good catch, Bert.
> > The idea of a mask for the DSCP was killed some time ago in Policy
> > Framework based on its incompatibility with the following explicit
> > prohibition in the definition of the Differentiated Services Field:
> > 
> > RFC 2474 Section 3, page 7
> >    Implementors should note that the DSCP field is six bits 
> wide.  DS-
> >    compliant nodes MUST select PHBs by matching against the 
> > entire 6-bit
> >    DSCP field, e.g., by treating the value of the field as a 
> > table index
> >    which is used to select a particular packet handling 
> > mechanism which
> >    has been implemented in that device.  The value of the CU 
> > field MUST
> >    be ignored by PHB selection.  The DSCP field is defined as an
> >    unstructured field to facilitate the definition of future per-hop
> >    behaviors.
> > 
> > John
> > 
> > At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote:
> > >Do Diffservers think that the following is wise and makes sense?
> > >
> > >   docsSubMgtPktFilterDscpValue OBJECT-TYPE
> > >       SYNTAX      Dscp
> > >       MAX-ACCESS  read-create
> > >       STATUS      current
> > >       DESCRIPTION
> > >           "The Differentiated Services Code Point (DSCP) value to
> > match
> > >            in the IP packet."
> > >       DEFVAL { 0 }
> > >       ::= { docsSubMgtPktFilterEntry 9 }
> > >
> > >   docsSubMgtPktFilterDscpMask OBJECT-TYPE
> > >       SYNTAX      Dscp
> > >       MAX-ACCESS  read-create
> > >       STATUS      current
> > >       DESCRIPTION
> > >           "The mask to apply against the DSCP value to be 
> matched in
> > >       the IP packet.  The default for both these objects taken
> > together
> > >       matches all DSCP values. A packet matches this filter if the
> > >       following is true:
> > >           AND (FilterDscpValue, FilterDscpMask) ==
> > >           AND (Packet DSCP Value, FilterDscpMask)."
> > >       DEFVAL { 0 }
> > >       ::= { docsSubMgtPktFilterEntry 10 }
> > >
> > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt 
> and I'd like
> > >to hear comments from Diffserv experts.
> > >
> > >Thanks,
> > >Bert 
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/diffserv
> > Archive:
> > http://www.ietf.org/mail-archive/working-groups/diffserv/curre
> nt/maillis
> t.html
> 
> 
_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html