Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt

From: "Tom Petch" <[email-masked]>
Date: Mon, 14 Mar 2005 15:19:42 +0100

I find the IANA Considerations section less than clear.  I suggest that you
differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB

I would also reword it slightly as follows.

**   MPLS and GMPLS related standards track MIB modules are rooted under the
   mplsStdMIB subtree.

   One of the MIB modules contained in this document extends tables
   contained in MPLS MIB modules.

**  The two MIB modules contained in this document, like that in
GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree.

**   New assignments in the mplsStdMIB subtree can only be made via a Standards
Action as specified   in [RFC2434].

11.1. IANA Considerations for GMPLS-LSR-STD-MIB

   The IANA is requested to assign { mplsStdMIB xx } to the
   GMPLS-LSR-STD-MIB module specified in this document.

11.2. IANA Considerations for GMPLS-LABEL-STD-MIB

** The IANA is requested to assign { mplsStdMIB yy } to the
   GMPLS-LABEL-STD-MIB module specified in this document.

Tom Petch

draft-ietf-ccamp-gmpls-te-mib-08.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 15 Mar 2005 09:53:10 -0000

Good man, Tom.

Thanks.
Adrian

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 15 Mar 2005 12:29:07 +0100

A minor comment; this document has
 false (0),
in several places; following RFC 2579, I think this should be
 false (2)

A larger question,; this mib augments tables in the mpls mib (RFC3812); is there
a reason why the AUGMENTS construct was not used?

Tom Petch

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Mar 2005 16:34:06 -0000

Hi Tom,

> in several places; following RFC 2579, I think this should be

Good catch. This is in the example which is why we didn't catch it by
compiling.

> a reason why the AUGMENTS construct was not used?

This is not my area of expertise!
I think that there are two strict augmentations and in these cases
AUGMENTS was used.

The other cases are, I believe, extensions.

I *think* the difference is that an AUGMENT is always present and an
extension is only present if used.
(Feels like I'm on shaky ground!)

Cheers,
Adrian

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 16 Mar 2005 22:09:30 +0100

To quote from RFC2578
" Instances of subordinate columnar
   objects of a conceptual row augmentation are identified according to
   the INDEX clause of the base conceptual row corresponding to the
   object named in the AUGMENTS clause.  Further, instances of
   subordinate columnar objects of a conceptual row augmentation exist
   according to the same semantics as instances of subordinate columnar
   objects of the base conceptual row being augmented.  As such, note
   that creation of a base conceptual row implies the correspondent
   creation of any conceptual row augmentations"

exactly; or

- AUGMENTS is an alternative to INDEX in SMIv2
- there is a one to one correspondence between rows in the base table and rows
in the AUGMENTS table(s - can be more than one), same index columns, same index
values
- the column objects in the AUGMENTS table(s) are created when the row in the
base table is created; assuming that the agent implements those columns in the
AUGMENTS table(s) - that is a matter of conformance clauses etc.

Reading the text, I thought these conditions were met - but I was not sure;
seeing the INDEX clauses makes me think I am not understanding the text, I am
missing something:-)

Tom Petch

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Mar 2005 22:51:45 -0000

Thanks for the references.
This fits with what I thought.

Viz. Augments means that an entry in the augmenting table is created
whenever an entry in the base table is created.
Extends means that an entry in the extending table is created only when
required.

The indexing in the two cases is the same.

Cheers,
Adrian

----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2005 9:09 PM
Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt

> > > A larger question,; this mib augments tables in the mpls mib
(RFC3812);
> > is there

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 18 Mar 2005 09:29:40 +0100

This MIB contains several 'enumerations' except they are not enumerations but
text in
DESCRIPTION clauses  -  gmplsTunnelGPid gmplsTunnelSwitchingType
gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference.  So these are
not defined anywhere in SMI; and as this points out, these values will be added
to in future RFC.

I think these should be in a MIB under IANA control and there is already a way
to do just that, namely to put them in an IANA MIB (as opposed to a standards
track MIB) with the RFC specifying under what conditions the IANA MIB can be
updated (standards track, IESG, expert etc).

This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which
also points to previous examples of this.  And this issue has already surfaced,
albeit obliquely, on this list once before in the context of
IANAItuProbableCause which uses this procedure and is now published as part of
the Alarm MIB (RFC 3877).

Not to do this now creates extra work in the future; when an implementor has to
create their own SMI and whenever these values need to be updated.

Tom Petch

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Mar 2005 17:38:13 -0000

Tom,

Good advice.

We'll look at how to do this.

Adrian
----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, March 18, 2005 8:29 AM
Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt

> This procedure is described in
draft-ietf-ops-mib-review-guidelines-04.txt which

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 18 Mar 2005 19:38:54 +0100

Digging deeper (sorry, I should done this before sending any e-mail:-(

RFC 3471 says in IANA considerations
"This document defines the following namespaces:

      o LSP Encoding Type: 8 bits
      o Switching Type: 8 bits
      o Generalized PID (G-PID): 16 bits

   All future assignments should be allocated through IETF Consensus
   action or documented in a Specification.

  LSP Encoding Type - valid value range is 1-255.  This document
   defines values 1-11.

   Switching Type - valid value range is 1-255.  This document defines
   values 1-4, 100, 150 and 200.

   Generalized PID (G-PID) - valid value range is 0-1500.  This document
   defines values 0-46."

fine no problem

Switching type

draft-ietf-ccamp-ospf-gmpls-extensions-12.txt adds
         51    Layer-2 Switch Capable  (L2SC)
 but makes no mention of that in IANA considerations; should it?

The MIB text cites as reference draft-ietf-ccamp-gmpls-routing-09.txt which has
no IANA considerations and I cannot see adding a value; should this be
OSPF-gmpls-extensions?

And draft-ietf-ccamp-gmpls-g709-09.txt says

 "Switching Type:
        Assigned by IANA via IETF Standards Track RFC  Action. "

ie this is now more restrictive than RFC 3471; is this really intended?

LSP encoding type

The MIB cites
draft-ietf-ccamp-gmpls-g709-06.txt,
This should be -09 which says

   - LSP Encoding Type:
        12              defined in Section 3.1.1
        13              defined in Section 3.1.1
     Allocation Policy:
        [0..239]        Assigned by IANA via IETF Standards Track RFC Action.

ie this is now more restrictive than RFC3471; was this intended?

Generalized PID

Same story, MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, which should be -09,
does add values but again is more restrictive about how the values can be
updated.

Standing back, there are these three enumerations, they will be added to over
the years, what is the right policy for updating them? Standards track, expert
review, IETF consensus?

How best to keep the MIBS in line with the I-Ds at least at initial publication,
which is the authoritative document?(define it all in the MIB:-)

Are there any more in other documents, perhaps for which no MIB yet exists? (RFC
3471 does list five sets of numbers - I have only looked at these three - and
there an awfully large number of GMPLS documents most of which I have not looked
at)