Skip to main content

The Differentiated Services Configuration MIB
draft-ietf-snmpconf-diffpolicy-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Margaret Wasserman
2003-12-09
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2003-12-08
09 Amy Vezza IESG state changed to Approved-announcement sent
2003-12-08
09 Amy Vezza IESG has approved the document
2003-12-08
09 Amy Vezza Closed "Approve" ballot
2003-12-08
09 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2003-12-08
09 Bert Wijnen All discusses have been cleared now, sending request to secretariat to announce approval.
2003-12-08
09 Bert Wijnen [Note]: 'Approved' added by Bert Wijnen
2003-12-08
09 Margaret Cullen [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman
2003-12-08
09 Bert Wijnen State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Bert Wijnen
2003-12-08
09 Bert Wijnen New revision supposedly addresses IESG Discuss comments. Checking with Ad who raised the issue.
2003-12-08
09 Bert Wijnen Status date has been changed to 2003-12-08 from 2003-11-11
2003-11-26
09 (System) New version available: draft-ietf-snmpconf-diffpolicy-09.txt
2003-11-21
09 Amy Vezza Removed from agenda for telechat - 2003-11-20 by Amy Vezza
2003-11-20
09 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2003-11-20
09 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-11-20
09 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-11-20
09 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for  by Thomas Narten
2003-11-20
09 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-11-20
09 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-11-20
09 Jon Peterson [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson
2003-11-20
09 Jon Peterson
[Ballot comment]
This document does not have an RFC2119 boilerplate in the typical "Terminology" section. While most of the document is free of 2119 terms, …
[Ballot comment]
This document does not have an RFC2119 boilerplate in the typical "Terminology" section. While most of the document is free of 2119 terms, the Security Considerations contains a couple instances of upper-case "RECOMMENDED". For consistency's sake, a 2119 boilerplate should be added or those 'RECOMMENDEDs' should be demoted.
2003-11-20
09 Jon Peterson [Ballot Position Update] New position, Undefined, has been recorded for  by Jon Peterson
2003-11-19
09 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for  by Ted Hardie
2003-11-19
09 Margaret Cullen
[Ballot discuss]
I have three substantive comments on this document and
several editorial comments.  All of my comments are marked
with '>>':

SUBSTANTIVE:

#1

>> …
[Ballot discuss]
I have three substantive comments on this document and
several editorial comments.  All of my comments are marked
with '>>':

SUBSTANTIVE:

#1

>> General comment:  There are several places where this document
>> discusses things that happen  "at the moment" that a policy is
>> instantiated.  Does that mean that those things will be completed
>> before the SNMP SET returns?  Do the contents of a particular
>> policy need to be locked against modification by another manager
>> while the cloning operation is taking place?

---
#2

  if ( roleMatch("Administrator") )
  then
      /*
      * The $0 gets the "element" returned from the previous
      * statement.  the .2 at the end is the ingress interface

>> s/.2 at the end/.1 at the end/  (?? see below)

      * This sets, for example, diffServDataPathStart.3.2 to be
      * "diffServConfigStart.3.f.o.o" if interface 3 has the role
      * "Administrator".
      */
      setVar("diffServDataPathStart.$0.1",
              "diffServConfigStart.3.f.o.o", Oid)

>> The example doesn't seem to agree with the comment.  I think that
>> this sets the diffServDataPathStart.3.1 to be...

---
#3

  Therefore, we have the following example policy which is configured
  via the POLICY-BASED-MANAGEMENT-MIB module (see [PMMIBDR]):

>> The example seems to be missing.

====

EDITORIAL:

These are non-blocking comments, but should be fixed if the
document is updated for other reasons:

  Unlike most MIB modules, changes to the managed objects in this MIB
  module do not cause a change in the device. 

>> This may just be a semantic distinction, but changes to this
>> MIB certainly would make changes in the device that implements
>> it -- memory locations would take on new values, etc.  I
>> think the authors mean that changes to this MIB won't
>> immediately change how traffic is handled by the device?

---
6.  Template Cloning

  The concept of the DIFFSERV-CONFIG-MIB is based on having traffic
  treatment configuration templates. The templates provide a set of
  configuration values that provide a certain behavior, such as EF
  traffic treatment, in the functional datapath.

>> EF?  Also, AF is used later without being specified.

  The template (or
  functional datapath) is similar to a linked list from a starting
  point and each (functional datapath) element is connected to the next
  element via a so-called the element.

>> The last part of this sentence doesn't parse -- "a so-called
>> the element"?

---
  The moment a template is activated (instantiated) on an interface and
  its interface direction, the template needs to be copied/cloned, so
  that the template remains as a template.  If the template is no
  longer available as a template after an instantiation, the management
  station has to set up a new equivalent template, and the object
  amplification of configuration with SNMP is gone.

>> I think I understand what this is trying to say, but I don't know
>> what "the object amplification of configuration with SNMP" means.
>>
>> Perhaps:
>>
>> When a template is activated (instantiated) on an interface and
>> its interface direction, the template needs to be copied/cloned
>> so that the original template can continue to be used as a
>> template for future activations (instantiations).  Unless an
>> independent clone of the template is created for each instantiation,
>> the benefits of using this MIB for template-based configuration
>> will not be realized.

---
7.  Managed Objects Definitions (MIB Module)


        DESCRIPTION
          "This MIB module contains differentiated services
          specific managed objects to perform higher-level
          configuration management. This MIB allows policies
          to use 'templates' to be used to instantiate

s/allows policies to use 'templates' to be used to instantiate/
allows policies to use 'templates' to instantiate/

---
  diffServConfigId OBJECT-TYPE
      SYNTAX        SnmpAdminString (SIZE(1..116))
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
          "A unique id for the per-hop-behavior policy.  The range
          of up to 116 octets is chosen to stay within the SMI
          limit of 128 subidentifiers in an object identifier."
      ::= { diffServConfigEntry 1 }

>> Unique within what scope?  On this system?  Within an
>> adminstrative domain?
2003-11-19
09 Margaret Cullen [Ballot Position Update] New position, Discuss, has been recorded for  by Margaret Wasserman
2003-11-17
09 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for  by Steve Bellovin
2003-11-16
09 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-11-12
09 Bert Wijnen State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bert Wijnen
2003-11-11
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-11-11
09 Bert Wijnen Placed on agenda for telechat - 2003-11-20 by Bert Wijnen
2003-11-11
09 Bert Wijnen [Note]: 'Responsible: Bert Wijnen' added by Bert Wijnen
2003-11-11
09 Bert Wijnen IETF Last Call did not generate any comments.
Diffserv WG chair (Brian Carpenter) did check and thinks this document is OK as well.
2003-11-11
09 Bert Wijnen Status date has been changed to 2003-11-11 from 2003-08-28
2003-11-11
09 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2003-11-11
09 Bert Wijnen Ballot has been issued by Bert Wijnen
2003-11-11
09 Bert Wijnen Created "Approve" ballot
2003-10-22
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2003-10-08
09 Amy Vezza Last call sent
2003-10-08
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-10-07
09 Bert Wijnen Last Call was requested by Bert Wijnen
2003-10-07
09 Bert Wijnen State Changes to Last Call Requested from AD Evaluation::AD Followup by Bert Wijnen
2003-10-07
09 (System) Ballot writeup text was added
2003-10-07
09 (System) Last call text was added
2003-10-07
09 (System) Ballot approval text was added
2003-10-07
09 Bert Wijnen New revision does address AD review comments.
2003-10-03
08 (System) New version available: draft-ietf-snmpconf-diffpolicy-08.txt
2003-08-28
09 Bert Wijnen
New Revision still has some issues, see below

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 28 augustus 2003 1:22
To: snmpconf@snmp.com …
New Revision still has some issues, see below

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 28 augustus 2003 1:22
To: snmpconf@snmp.com
Subject: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt


We're getting close. Still afe nits.

- sect 2, first para seems to end with an incomplete sentence?

- sect 3 refers to RFC3512 as a BCP. Well, fist of all it is not
  good to talk too much about the maturity level of documents
  inside an RFC. that maturity level is an external label,
  that may change over the lifetime of an RFC.
  But in any case, way back when we decided to make RFC3512 an
  Informational RFC, and that is what it is.

- You have kept the PM-MIB as a normative reference. Based on the
  text, that still seems to make sense... but.. this means that this
  doc will be depending on the PM-MIB to be approved as PS as well.
  So if I bring this one ot IESG, and if we approve it, then it will
  hang in RFC-Editor queue till PM-MIB is ready for RFC as well.
  I can accept the way it is... just let me know if that is indeed
  what you wanted/intended.

- Security section. So do I understand there is no sensitivity to
  reading any of the objects in this MIB? If such is the case, it
  might be good to state so. Now you only talk about write access.

- If you're gonna rev once more anyway, then
  diffServConfigId OBJECT-TYPE
      SYNTAX        SnmpAdminString (SIZE(1..116))
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
          "A unique id for the per-hop-behavior policy.  The range
          of up to 116 octets is chosen to stay within the SMI
          limit of 128 subidentifiers in an object identifier."
      ::= { diffServConfigEntry 1 }
  s/SMI/SNMP/, cause the SMI does not limit it, it is the SNMP PDU
  that does not allow for more than 128 subids in an OID in a
  varBind. I should have seen this last time.

- StorageType, I stated:
    But in any event, you need to say something about write
    access for permanent entries. See the StorageTypeTC in RFC2579
  I see nothing about it. What I mean is some text in DESCRIPTION
  clause aka:
      Conceptual rows having the value 'permanent' need not
      allow write-access to any columnar objects in the row.
  if such is indeed the case.

- I do not see that you addressed:
  11. RowStatus
    Need to say which (if any) objects can be changed while a
    row is active. See RowStatus TC in RFC2579
  It may be as simple as
      All writable objects in this row may be modified at
      any time.
  If such is indeed the case.


Bert
2003-08-28
09 Bert Wijnen Status date has been changed to 2003-08-28 from 2003-08-16
2003-08-15
09 Bert Wijnen State Changes to AD Evaluation::AD Followup from 0::AD Followup by Bert Wijnen
2003-08-15
09 Bert Wijnen State Changes to 0::AD Followup from AD Evaluation::Revised ID Needed by Bert Wijnen
2003-08-15
09 Bert Wijnen New revision received that AD needs to check if comments have been addressed.
2003-08-15
09 Bert Wijnen Status date has been changed to 2003-08-16 from 2003-07-29
2003-08-14
07 (System) New version available: draft-ietf-snmpconf-diffpolicy-07.txt
2003-07-29
09 Bert Wijnen
A revised ID is needed.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 29 juli 2003 16:49
To: Snmpconf (E-mail)
Subject: AD …
A revised ID is needed.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 29 juli 2003 16:49
To: Snmpconf (E-mail)
Subject: AD review of: draft-ietf-snmpconf-diffpolicy-06.txt


Here is my AD review:

1. First, a SMICng compiler (With strict checking) reveals:

  W: f(diffpol.mi2), (20,4) MODULE-IDENTITY diffServConfigMib should
    have at least one REVISION clause
  W: f(diffpol.mi2), (68,4) Row "diffServConfigEntry" has indexing
    that may create variables with more than 128 sub-ids
  - bw: I think this is a bug in SMICng, cause your limit of 116 seems to
        be limiting it to exact 128 sub-ids
  E: f(diffpol.mi2), (204,12) Item "ifCounterDiscontinuityGroup" should
    be IMPORTed
  E: f(diffpol.mi2), (207,15) module "DIFFSERV-MIB" may be specified
    only once
  E: f(diffpol.mi2), (209,12) Item "diffServMIBDataPathGroup" should
    be IMPORTed
  E: f(diffpol.mi2), (209,38) Item "diffServMIBClfrGroup" should
    be IMPORTed
  E: f(diffpol.mi2), (210,12) Item "diffServMIBClfrElementGroup" should
    be IMPORTed
  E: f(diffpol.mi2), (210,41) Item "diffServMIBMultiFieldClfrGroup"
    should be IMPORTed
  E: f(diffpol.mi2), (211,12) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(diffpol.mi2), (211,36) Item "diffServMIBAlgDropGroup" should be IMPORTed
  E: f(diffpol.mi2), (212,12) Item "diffServMIBQGroup" should be IMPORTed
  E: f(diffpol.mi2), (212,31) Item "diffServMIBSchedulerGroup" should be IMPORTed
  E: f(diffpol.mi2), (213,12) Item "diffServMIBMaxRateGroup" should be IMPORTed
  E: f(diffpol.mi2), (213,37) Item "diffServMIBMinRateGroup" should be IMPORTed
  E: f(diffpol.mi2), (214,12) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(diffpol.mi2), (217,14) Item "diffServMIBMeterGroup" should be IMPORTed
  E: f(diffpol.mi2), (222,14) Item "diffServMIBTBParamGroup" should be IMPORTed
  E: f(diffpol.mi2), (227,14) Item "diffServMIBDscpMarkActGroup" should be IMPORTed
  E: f(diffpol.mi2), (232,14) Item "diffServMIBRandomDropGroup" should be IMPORTed
  E: f(diffpol.mi2), (237,15) Item "diffServDataPathStatus" should be IMPORTed
  E: f(diffpol.mi2), (243,15) Item "diffServClfrStatus" should be IMPORTed
  E: f(diffpol.mi2), (249,15) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(diffpol.mi2), (255,15) Item "diffServMultiFieldClfrAddrType" should be
    IMPORTed
  E: f(diffpol.mi2), (261,15) Item "diffServMultiFieldClfrDstAddr" should be
    IMPORTed
  E: f(diffpol.mi2), (267,15) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(diffpol.mi2), (273,15) Item "diffServRandomDropStatus" should be IMPORTed
  E: f(diffpol.mi2), (279,15) Item "diffServQStatus" should be IMPORTed
  E: f(diffpol.mi2), (285,15) Item "diffServSchedulerStatus" should be IMPORTed
  E: f(diffpol.mi2), (291,15) Item "diffServMinRateStatus" should be IMPORTed
  E: f(diffpol.mi2), (297,15) Item "diffServMaxRateStatus" should be IMPORTed

2. I am also missing the Copyright statement in the DESCRIPTION clause of
  the MODULE-IDENTITY.

3. I am also not sure we need to repeat the whole compliance statements from
  the DIFFSERV MIB. It seems to me it is an exact copy of the
  diffServMIBFullCompliance, and if indeed so, then I think it is
  sufficient to state (within the DESCRIPTION clause of
  diffServConfigMIBFullCompliance, that the diffServMIBFullCompliance
  must also be met. See 2nd para page 25 of
      draft-ietf-ops-mib-review-guidelines-01.txt

4. When one reads the doc, one would get the impression that one
  MUST undestand the PM-MIB in order to understand this one. Not only
  because of the normative ref, but also reading the text one gets that
  impression. Harrie and Jon had mentioned that this document would
  not need a normative reference to the PM-MIB, but from the text
  it seems to me that it indeed DOES need to, and if not, then it
  does not make clear how this MIB could/should  be used without
  the PM-MIB.

5. I also suspect that the security-considerations section needs to list
  which tables and objects are security sensitive and why.

6. I also miss the IPR section.

7. There may be other issues that one might find if one does a carefull
  check against:
      draft-ietf-ops-mib-review-guidelines-01.txt

8. Page 14,
  Is it really:
      if
        return roleMatch("Administrator")
  Or is it suppused to be:
      if (roleMatch("Administrator")

  But even with that, I do not think the context is readily understandable
  is it? I think you want to show (possibly with some more complete
  PM-MIB code fragment) how this works and how th various entries
  get created.

  And/Or, show how it can be done without the use of PM-MIB

9. objectdiffServConfigID
      DESCRIPTION
          "A unique id for the per-hop-behavior policy.  The range
          of up to 116 characters is chosen to stay within the SMI
          limit of 128 subidentifiers in an index."
  s/character/octets/
  It is important to distinguis, UTF-8 characters may occupy more than
  one octet per character.


10. StorageType
    Might want to add a DEFVAL ??
    But in any event, you need to say something about write
    access for permanent entries. See the StorageTypeTC in RFC2579

11. RowStatus
    Need to say which (if any) objects can be changed while a
    row is active. See RowStatus TC in RFC2579

12. Pls remove the IMPORT for InetAddressType, InetAddress,
    they are not used

13. RFC3411 needs to be normatively referenced, you are IMPORTing
    SnmpAdminString from it.

REAL NITS

- page 8, last line of first para
  ".. via a so called the element."  ???

- page 11 2nd para
  "... treatment of 1) is also in the tables."
  Does "1)" refer to section 6.2.1 ?? If so, better make that
  explicit

- Page 13
  I wonder if "DSCP(EF)" is a clear indication of the fact that this
  is entry diffServDscpMarkActDscp.
  and same for DSCP(AF).

- Pages 12, 13 and 16
  I understand that the values (content) of things like diffServClfrStorage
  and diffServCountActOctets (etc) are irrelevant. But you may want to
  say something about that.

- I'd change
      ::= { mib-2 xxx }  -- Needs to be assigned by before publishing
  into:
      ::= { mib-2 xxx }  -- to be assigned by IANA


Thanks,
Bert
2003-07-29
09 Bert Wijnen State Changes to AD Evaluation  :: Revised ID Needed from AD Evaluation by Wijnen, Bert
2003-07-29
09 Bert Wijnen AD Evaluation
Responsible: Bert
2003-07-29
09 Bert Wijnen Status date has been changed to 2003-07-29 from
2003-07-29
09 Bert Wijnen State Changes to AD Evaluation from Publication Requested by Wijnen, Bert
2003-07-29
09 Natalia Syracuse Draft Added by Syracuse, Natalia
2003-06-06
06 (System) New version available: draft-ietf-snmpconf-diffpolicy-06.txt
2002-06-19
05 (System) New version available: draft-ietf-snmpconf-diffpolicy-05.txt
2001-03-05
04 (System) New version available: draft-ietf-snmpconf-diffpolicy-04.txt
2000-11-29
03 (System) New version available: draft-ietf-snmpconf-diffpolicy-03.txt
2000-07-06
02 (System) New version available: draft-ietf-snmpconf-diffpolicy-02.txt
2000-04-13
01 (System) New version available: draft-ietf-snmpconf-diffpolicy-01.txt
2000-03-13
00 (System) New version available: draft-ietf-snmpconf-diffpolicy-00.txt