The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I am pretty happy with rev 02.

Here where I still have some questions:

You have:

   ::= { transmission xxx } -- To be assigned by IANA (experimental 114
                            -- can be used in the interim)

I would like you to change it as follows (assuming you and WG agree
that you prefer to get 200 assigned:

   ::= { transmission xxx } -- To be assigned by IANA (we request that
                            -- 200 will be assigned, becuase teLink
                            -- has already been assigned 200 in the
                            -- IANAifType-MIB module).

I suspect that some MIB doctors will take issue with (and so probably bring 
it up during IETF Last Call, so might as well fix it now):
  teLinkAddressType OBJECT-TYPE
     SYNTAX        InetAddressType
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
       "The type of Internet address for the TE link. Only IPv4,
        IPv6 and unknown (for unnumbered links) need to be supported."

The reason is that the "what needs to be supported" is normally somthing
you write in the COMPLIANCE statements, as you have done. So if you take
out the 2nd sentence, then in the future other types could be supported 
and all you then need to do is create a new MODULE-COMPLIANCE stmnt
(which can even be done in a separate document). The current
MODULE-COMPLIANCE already states which types need to be supported.

would it be too much to ask that you prefix all

   compnentXxxx descriptors with "te", so that all MIB
   objects in this mib module start with te.??

And w.r.t.

> > - I have trouble with:
> >       OBJECT      teLinkRowStatus
> >       SYNTAX      INTEGER { active(1), notInService(2),
> >                             createAndGo(4), destroy(6) }
> >       DESCRIPTION
> >           "The notReady(3) state need not be supported."
> > 
> >   I think what you want to specify is that createAndWait is not needed.
> >   Since you allow all objects to be changed in 'active' mode, the 
> >   notInService may not be needed either. (I am assuming here that I 
> >   did understand your intent... which I am not sure of). In that case
> >   something like the following example from RFC3289 would be better:
> > 
> >     OBJECT diffServClfrStatus
> >     SYNTAX RowStatus { active(1) }
> >     WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
> >     DESCRIPTION
> >        "Support for createAndWait and notInService is not required."
> > 
> > [Martin] The notInService is required since it is one of the state that
> > allows writes (see explanation a few points above). notReady 
> > and createAndWait are not required. For read-only, only active is
> > required. I have updated text in this respect.
> > 
> Mmm... in the example in section 7, you DO show that you would do a
> createAndWait for the teLinkTable, don't you?
> So this COMPLIANCE statement seems to be in conflict with that.
> So pls decide what it is or should be and then we need to
> make a proper specification that is in sync with that.
> 
> It seems to me, that for your teLinkRowStatus in the rev 01 document
> (assuming you do want createAndWait as per section 7) that the
> statement on teLinkRowStatus should be removed.
> If indeed you do not want/need createAndWait (but then sect 7 needs
> an update), then it could be changed to:
> 
>      OBJECT      teLinkRowStatus
>      SYNTAX      INTEGER { active(1), notInService(2) }
>      WRITE-SYNTAX RowStatus { notInService(2), createAndGo(4),
>                               destroy(6) }
>      DESCRIPTION
>          "The notReady(3) and createAndWait(5) states need
>           not be supported."
> 
> [Martin] No createAndWait is required. See above.
> 
But you did not split the possible valued into a SYNTAX and WRITE-SYNTAX
as per above proposal. I think my proposal would be better, although
yours will work.

Bert