Subject: RE: [Diffserv] The DsCodePoint definition

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 13 Dec 2000 03:31:22 +0100

Comments inline

> ----------
> From: 	Andy Bierman[SMTP:[email-masked]]
> Sent: 	Tuesday, December 12, 2000 9:07 PM
> To: 	Harrie Hazewinkel
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: [Diffserv] The DsCodePoint definition
> 
> Harrie Hazewinkel wrote:
> > 
> > HI,
> > 
> > I was wondering why there is a difference between
> > 2 definitions of the DiffServ CodePoint in different
> > MIB modules. The two different MIMB modules are
> > the DIFFSERV-MIB (of diffserv) and the DSMON-MIB (of RMON).
> > 
> > I beleive these 2 TCs should be the same and taken from the
> > DIFFSERV-MIB, because that is from the diffserv WG.
> > 
> > ----------- From the DIFFSERV-MIB (draft 05) -----------------
> > Dscp ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "d"
> >     STATUS   current
> >     DESCRIPTION
> >        "The IP header Diffserv Code-Point that may  be  used
> >        for  discriminating or marking a traffic stream.  The
> >        value  -1  ( 4294967295 for Integer32 )  is  used  to
> >        indicate a wildcard i.e. any value."
> >     SYNTAX   Integer32 (4294967295 | 0..63)
> 
> just noticed how broken this TC is...
>  1) an Integer32 object cannot contain the value 4294967295
I have made that comments to the Diffserv list already, and they
will need to fix it with using -1
>  2) missing REFERENCE clause
>     (where exactly in 2474 is the 'wildcard' DSCP value discussed?)
Yep, this one was raised by someone else (was it Andrew?)

But the important thing, we need a fixed TC that is usable by both
MIBs I think. Or maybe 2 TCs as I also suggested on the diffserv
list.

Bert

> Andy
> 
> > --------------------------------------------------------------
> > 
> > ------------ From the DSMON-MIB (draft 03) -------------------
> > DsmonDSCodePoint ::= TEXTUAL-CONVENTION
> >     STATUS current
> >     DESCRIPTION
> >             "This TC describes an object which identifies the
> >             Differentiated Services Codepoint (DSCP) value found within
> >             the DS field in a network layer packet header (e.g., IPv4
> >             and IPv6)."
> >     REFERENCE
> >             "Definition of the Differentiated Services Field (DS Field)
> >             in the IPv4 and IPv6 Headers [RFC2474]."
> >     SYNTAX Integer32 (0..63)
> > --------------------------------------------------------------
> > 
> > OK, I will admit the definition of the DiffServ-MIB is currently
> > broken, but that will be fixed (this week at the IETF, I hope).
> > 
> > Harrie
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
> 

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

---

From: Andrew Smith <[email-masked]>
Date: Tue, 12 Dec 2000 22:05:21 -0800

2 TCs defined in the same MIB module, to be precise.

Andrew

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Dec 2000 10:15:38 -0800

> 2 TCs defined in the same MIB module, to be precise.

I disagree.
There is no need for the DSMON MIB to have a normative
reference to the DIFFSERV MIB. 

The primary focus of RMON is collect statistics based on
observable characteristics of network traffic. RFC 2474 
specifies the observable attributes of a packet containing
a DSCP field. The REFERENCE clause in the DsCodePoint TC
properly identifies RFC 2474, and no additional coupling to
any other documents is required.

BTW, SMIv2 does not allow a TC to be defined as a variant of
another TC, so Harrie's suggestion won't work.

Andy

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 15 Dec 2000 12:55:06 -0500

Andy:
I have created a new module in the Diff Serv MIB to hold the 2 new DSCP TCs.
You don't need to reference the whole Diff Serv MIB, just the DSCP TC Module.
I hope this help for you to reference the DSCP TC definition from the
DiffServ WG.
Right now the 2 TCs in DSMIB-07 are Dscp (0..63) and DscpOrAny (-1 | 0..63).
This will be published this coming weekend in Diff Serv MIB -07.
Other than requiring an import in the RMON MIB to get the DSCP TC,
is there any technical issue in using a common DSCP TC definition?
Would like to do what I can to resolve this.
Thanks!
-- Kwok --

>> >>>             in the IPv4 and IPv6 Headers [RFC2474]."
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Dec 2000 13:25:56 -0800

> Would like to do what I can to resolve this.

I did not agree to this change.
I don't think it's a good idea to couple the progress of the DSMON MIB RFC
to the DIFFSERV MIB RFC. The DSMON MIB module will (potentially) be
held up at each level of publication, waiting for any or all of
the MIB modules in the DIFFSERV MIB RFC. 

If you publish a DIFFSERV-TC MIB module in its own RFC,
I'll change the DSMON MIB. 

Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Dec 2000 13:40:39 -0600

Andy,

My understanding was that publishing the TC in a separate RFC remains
possible. We *will* publish a stand-alone diffserv MIB including this
TC anyway, for the same reason that you mention - to avoid any dependencies.

  Brian