Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition
draft-ietf-mpls-lc-if-mib-08

[Ballot discuss]
The Gen-Art review from Joel Halpern has raised some points that are unclear to a new reader (even though he is quite knowledgeable in this area). It seems that all these points need clarifying text, even if they are technically OK as specified.

Ongoing dialogue about these points follows (response from Joel to Tom Nardeau):

My comments on the questions in line...
Joel

At 04:43 PM 9/13/2005, Thomas D. Nadeau wrote:

>>> There is the absence of the usual section describing the
>>> structure / functioning of the MIB.  And there is the fact that
>>> section 4 references sections 6 and 7 when the correct reference
>>> is sections 5 and 6?  It is possible that the section two text is
>>> vestigial, and that the section 4 text needs correcting.  But the
>>> absence of the usual structural description makes me wonder if
>>> something is simply missing?
>
>
>    We had one in the original version of the draft, but I believe we
> removed it because the structure of the MIB was so simple it
> didn't seem to warrant one.  No one objected during the WG last
> calls or reviews.


Well, the fact that I am finding the items confusing may be an indication that the removal was a mistake.
The fact that no-one complained may be more a reflection of how few people read MIBs.


>>> Issue:  There is no explanation of the fields for describing the
>>> usage of the mplsLcAtmStdUnlabTrafVpi and
>>> mplsLcAtmStdUnlabTrafVci.  RFC 3035 indicates that ranges need to
>>> be partiitioned.  Obviously, this document is making some
>>> assumption about that partioning.  However, the combination of
>>> field descriptions in the MIB is insufficient to allow this reader
>>> to understand the intent.
>
>
>    I guess this reader doesn't understand your question. I just
> re-read the description and it seems to explain precisely what the field
> is for: the configured upper range of VPI values that the LSR is
> willing to accept for LC-ATM operation.  This is in essence, what
> is described in section 7 of RFC3035.


RFC 3035 says "partition".  This MIB appears to have decided that the correct partition is that VPIs below a certain level are for unlabelled traffic, and VPIs above that are for labelled traffic.  That is by no means the only possible partition.  It is not an obviously correct partition.
Further, the mplsLcAtmStdUnlabTrafVci says that it is "the VCI value" over which this LSR is willing to accept unlabeled traffic.
a) Why only one VCI?
b) Is that one for each VPI?
Again, that is a partitioning, but not the only possible or only obvious partitioning.

The chosen partitioning may be the best model to use.  But the model ought to be stated explicitly, with explanation.


>>> Issue:  The text for mplsLcAtmVcDirectlyConnected and
>>> mplsLcAtmLcAtmVPI seems to assume that indirectly connected LC-ATM
>>> switches will always be connected by only one VP.  That is not
>>> required by 3035, and does not seem a necessary assumption.
>
>
>    Would it help you if we moved the "(by means of a VP)"
> to "(by means of an ATM Virtual Path)?  If you look
> at the text in section 7.2 of RFC3035 it does indeed
> imply that "an" ATM Virtual Path is used for the indirect
> connection (and this is indeed how its implemented):


My concern is that the MIB supports only a single VP.  The text in 3035 section 7.2 allows multiple VPs (although the wording is not the clearest ever written.)


>>> Issue:  RFC 3034 calls out support for devices which support both
>>> labelled and unlabelled traffic on separated DLCIs.  Unlike the
>>> ATM tables earlier in the document, the FR tables do not have
>>> provision for indicating which DLCI ranges are supporting which
>>> mode.  Is there an assumption that the ranges here are for
>>> labelled traffic, and that some other MIB identifies the ranges
>>> for labelled traffic.
>
>
>    All I can say is that the implementations that were polled (and
> the MPLS WG)
> thought the structure we had was fine, so that is what we went with.


The structure does not match RFC 3034.  The RFC explicitly calls for support for mixed mode devices.  If the MIB is going to choose to cite 3034 and to not support that mode, it MUST say so. And it SHOULD explain why.

[Ballot comment]
From Bert Wijnen:

When I se this entry in a Table:
  MplsLcAtmStdInterfaceConfEntry ::= SEQUENCE {
  mplsLcAtmStdCtrlVpi                AtmVpIdentifier,
  mplsLcAtmStdCtrlVci                MplsAtmVcIdentifier,
  mplsLcAtmStdUnlabTrafVpi            AtmVpIdentifier,
  mplsLcAtmStdUnlabTrafVci            MplsAtmVcIdentifier,
  mplsLcAtmStdVcMerge                TruthValue,
  mplsLcAtmVcDirectlyConnected        TruthValue,
  mplsLcAtmLcAtmVPI                  AtmVpIdentifier,
  mplsLcAtmStdIfConfRowStatus        RowStatus,
  mplsLcAtmStdIfConfStorageType      StorageType
  }

Then I recommend (for naming consistency) to rename
  mplsLcAtmVcDirectlyConnected        TruthValue,
  mplsLcAtmLcAtmVPI                  AtmVpIdentifier,
to
  mplsLcAtmStdVcDirectlyConnected    TruthValue,
  mplsLcAtmStdLcAtmVPI                AtmVpIdentifier,

In the security considerations, you write:
    o    the MplsLcAtmStdInterfaceConfTable and
        mplsLcFrStdInterfaceConfTable collectively
but the actual tables in the MIB module are named:
  mplsLcAtmStdInterfaceConfTable
  mplsLcFrStdInterfaceConfTable
So the first table name is incorrect (capital M which should
be lowercase). It occurs again later in the section
I know... this is REALLY a NIT, but once the doc has become an
RFC, you cannot fix it anymore.

---

From AAA_doctor Jari:
I reviewed this draft. It looks OK, but I'll admit that I know
very little about MPLS. Some nits were found, however:

>        is capabile of ATM VC merge, otherwise it MUST

s/capabile/capable/

>        MPLS-related configuration and/or performanc statistics.

s/performanc/performance/

>        LSR is willing to accept unlabled traffic

s/unlabled/unlabeled/

>        where possible.  Specifically,SNMPv3 VACM and USM MUST be

s/,/, /

[Ballot comment]
From AAA_doctor Jari:
I reviewed this draft. It looks OK, but I'll admit that I know
very little about MPLS. Some nits were found, however:

>        is capabile of ATM VC merge, otherwise it MUST

s/capabile/capable/

>        MPLS-related configuration and/or performanc statistics.

s/performanc/performance/

>        LSR is willing to accept unlabled traffic

s/unlabled/unlabeled/

>        where possible.  Specifically,SNMPv3 VACM and USM MUST be

s/,/, /

IANA Comments:
Upon approval of this document the IANA will register 2 mplsStdMIB numbers for
MPLS-LC-ATM-STD-MIB (suggested value mplsStdMIB 9) and MPLS-LC-FR-STD-MIB(suggested value mplsStdMIB 10).  These assignments will be made in the mplsStdMIB registry found at the following:
http://www.iana.org/assignments/smi-numbers

Recording my review comments for revision 5:
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Monday, May 23, 2005 23:34
To: Thomas D. Nadeau; Alex Zinin; Loa Andersson
Cc: Subrahmanya Hegde
Subject: RE: draft-ietf-mpls-lc-if-mib-05.txt to IESG


Catching up.

SMIlint errors:

  C:\smi\mibs\work>smilint -s -m -l 6 ./MPLS-LC-ATM-STD-MIB
  ./MPLS-LC-ATM-STD-MIB:48: [3] {revision-after-update} revision
                            date after last update
  ./MPLS-LC-ATM-STD-MIB:51: [3] {revision-missing} revision for
                            last update is missing

Or in smicng speak:

  W: f(mplslcatm.mi2), (48,8) The first revision should match
            the last update for MODULE-IDENTITY mplsLcAtmStdMIB

It seems that in the "Security Considerations" section, there
is text that is supposed to be in parenthesis, but shows up in
double quotes, which makes reading it very hard.
If I recall correctly, I have seen Tom's word-template do this
before? Anyway, probably better to fix it.

This Informative ref looks very strange to me:
  [RFC3815]    J. Cucchiara, et al., "Definitions of
                Managed Objects for the Multiprotocol Label
                Switching, Label Distribution Protocol
                (LDP)", ,
                June 2004.

It seems to reference an RFC (3815), but then has an internet draft
listed as the document that it references!?


I wonder: can the index for the tables be zero?
          and if so, what does that mean?

I see that my comments to rev 04 have not all been addressed,
These are still valid comments/nits:

- You are using [RFCxxxx] type citations inside MIB DESCRIPTION clauses.
  We really do not that. They get lost when a MIB is extracted.
  In my cases, you can just use RFCxxxx or (RFCxxxx)
  Of course you always need references to docs you IMPORT from or docs you
  REFERENCE via REFERENCE clauses.

- I do also not understand:
    mplsLcAtmStdModuleROCompliance
  why not name it mplsLcAtmStdModuleReadOnlyCompliance?
  Not mandatory, but a concept we have followed in several other
  MIB modules, even in some some you co-authored. Consistency in naming
  is always helpfull (or so I think)

- I also wonder why you cale itr "storeType" instead of "StorageType"
  Again... just a m,atter of naming consistency.... see some of the
  other MIB documents you co-authored.

Bert

Recording my review comments for rev 04

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Monday, January 17, 2005 16:57
To: Thomas D. Nadeau
Cc: Alex Zinin; Subrahmanya Hegde; Loa Andersson
Subject: RE: [Fwd: RE: Fwd: draft-ietf-mpls-lc-if-mib-04.txt for RFC]


The "findref" tool that I have I got (privately) from RFC-Editor.
They were reluctant to hand it out, cause it has known bugs and
concerns. I had to promise to not hand it out... so !?

ANyway, when I run it against you new doc:

  !! Missing Reference for citation: [RFC2434]
  P001 L845:    Standards Action as specified in [RFC2434].

  !! Missing Reference for citation: [RFC3034]
  P001 L505:          in [RFC3034].
  P001 L068:    [RFC3034] and ATM [RFC3035] interfaces can be realized given

  !! Missing Reference for citation: [RFC3035]
  P001 L177:          [RFC3035].
  P001 L315:        (see [RFC3035]). If the interface is directly
  P001 L068:    [RFC3034] and ATM [RFC3035] interfaces can be realized given

  !! Missing Reference for citation: [RFC3813]
  P001 L153:        FROM MPLS-LSR-STD-MIB        -- [RFC3813]
  P001 L484:        FROM MPLS-LSR-STD-MIB      -- [RFC3813]

Besides that, a very quick scan on some of those citations and through the references
tells me...

- You are using [RFCxxxx] type citations inside MIB DESCRIPTION clauses.
  We really do not that. They get lost when a MIB is extracted.
  In my cases, you can just use RFCxxxx or (RFCxxxx)
  Of course you always need references to docs you IMPORT from or docs you
  REFERENCE via REFERENCE clauses.
  In the past we had suggested to use -- [RFCxxxx] on the IMPORT statement.
  (So I willa ccept that if you have done that in exisitng MIB docs).

  These days we suggest to include some text. For example
  OLD:

  5. MPLS Label Controlled ATM MIB Definitions

  MPLS-LC-ATM-STD-MIB DEFINITIONS ::= BEGIN
  IMPORTS
  MODULE-IDENTITY, OBJECT-TYPE
      FROM SNMPv2-SMI
  MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF
  RowStatus, StorageType, TruthValue
      FROM SNMPv2-TC
  AtmVpIdentifier
      FROM ATM-TC-MIB              -- [RFC2514]
  mplsStdMIB, MplsAtmVcIdentifier
      FROM MPLS-TC-STD-MIB        -- [RFC3811]
  mplsInterfaceIndex
      FROM MPLS-LSR-STD-MIB        -- [RFC3813]
  ;

  NEW:

  5. MPLS Label Controlled ATM MIB Definitions

  The following MIB module imports from [RFC2514), [RFC3811] and [RFC3813].
  It further uses [RFCxxxx] in REFERENCE clauses.

  MPLS-LC-ATM-STD-MIB DEFINITIONS ::= BEGIN
  IMPORTS
  MODULE-IDENTITY, OBJECT-TYPE
      FROM SNMPv2-SMI
  MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF
  RowStatus, StorageType, TruthValue
      FROM SNMPv2-TC
  AtmVpIdentifier
      FROM ATM-TC-MIB           
  mplsStdMIB, MplsAtmVcIdentifier
      FROM MPLS-TC-STD-MIB     
  mplsInterfaceIndex
      FROM MPLS-LSR-STD-MIB     
  ;

OK in the current references section I see:

  [RFC3812]    Srinivasan, C., Viswanathan, A. and T.
---^^^^^^^^^
                Nadeau, "MPLS Multiprotocol Label Switching
                (MPLS) Label Switch Router Management
                Information Base ", RFC3813, June 2004.
-------------------------------------^^^^^^^

i.e. a conflict of RFC number. I did not check title.

  [RFC3814]    Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
---^^^^^^^^^
                Traffic Engineering Management Information Base ",
                RFC3812, June 2004.
-----------------^^^^^^^

i.e. a conflict of RFC number. I did not check title.

  [LDPMIB]      J. Cucchiara, et al., "Definitions of
                Managed Objects for the Multiprotocol Label
                Switching, Label Distribution Protocol
                (LDP)", ,
                November 2003.

The LDPMIB was published as RFC3815 in June last year.

------

Further, I now do NOT understand:

mplsLcAtmStdModuleFullCompliance MODULE-COMPLIANCE
  STATUS current
  DESCRIPTION
      "Compliance statement for agents that provide
        full support for MPLS-LC-ATM-STD-MIB. Such
        devices can be monitored and also be configured
        using this MIB module."
  MODULE -- this module
      MANDATORY-GROUPS {
        mplsLcAtmStdIfGroup
      }

      OBJECT      mplsLcAtmStdIfConfRowStatus
      SYNTAX      RowStatus { active(1) }
      WRITE-SYNTAX RowStatus { active(1), notInService(2),
                              createAndGo(4), destroy(6)
                            }
      DESCRIPTION "Support for createAndWait and notReady is
                  not required."

  ::= { mplsLcAtmStdCompliances 1 }

if you allow a WRITE-SYNTAX of notInService, then it seems to me
that such is also needed on the SYNTAX. Namely, if you put a row
in notInService, then a read of the RowStatus will/should show
notInService.

I do also not understand:
  mplsLcAtmStdModuleROCompliance
why not name it mplsLcAtmStdModuleReadOnlyCompliance?
Not mandatory, but a concept we have followed in several other
MIB modules, even in some some you co-authored. Consistency in naming
is always helpfull (or so I think)

You probably want to update the dates for LAST-UPDATED and REVISION
and the copyright as well... !!??


I find this strange:
mplsLcAtmStdIfConfStoreType OBJECT-TYPE
  SYNTAX        StorageType
  MAX-ACCESS    read-create
  STATUS        current
  DESCRIPTION
      "This SNMP storage type for this conceptual row. Conceptual
        rows having the value 'permanent' must allow write-access
        to all the writable columnar objects in the row."
  ::= { mplsLcAtmStdInterfaceConfEntry 9 }

Not sure I fully understand the use of a "permanent" row if you allow
write access to all columns. In any event, the value "permanent"
of the StiorageType column cannot be changed.
And a row can also not be deleted via a "destroy" of the RowStatus.
As you can read in RFC2579.

I also wonder why you cale itr "storeType" instead of "StorageType"
Again... just a m,atter of naming consistency.... see some of the
otehr MIB documents you co-authored.

ANd not that some of this I only checked for the ATM part of the
document, you may want to check the FR part yourself!

Oh well...

Bert