RE: 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: [email protected] [mailto:[email protected]] On Behalf
Of John Schnizlein
Sent: Wednesday, March 05, 2003 9:29 AM
To: Wijnen, Bert (Bert)
Cc: [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis
t.html


_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html