Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Joan,

 

Thanks for the rapid convergence.

 

In-line...

 

Cheers,

Adrian

 

> >> 3*) Question if these documents should have a
> >>    contributors section.  It violates the guidelines
> >>    of "RFC Editorial Guidelines and Procedures"
> >>    http://www.rfc-editor.org/policy.html#policy.auth2
> >>
> >>    There are many people listed under
> >>    Authors but not listed on the front page,
> >>    so how about adding a Contributors Section?
> >
> >Ack
> >We will change the title of "Authors' Addresses" section to be "Contact
> >Details".
>
> According to the rfc-editor website above,
> this should be "Contact Information", is this what you mean?

 

Yes, in deed. And Henrick's little tool catches this admirably.

> >> draft-ietf-ccamp-gmpls-tc-mib-07.txt
> >> ======================================
> >>
> >> Section 3. GMPLS Textual Conventions MIB Definitions
> >> ---------------------------------------------------
>
> >> 1) GmplsFreeformLabel TC
>
> >> 1c) The DESCRIPTION needs a little work:
> >>     DESCRIPTION
> >>        "This value represents a freeform generalized MPLS Label. This
> >>         can be used to represent label types which are not standard in
> >>         the drafts. It may also be used by systems that do not wish to
> >>         represent the labels using the specific label types."
> >>
> >>      Please reword to something like:
> >>
> >>       "This value represents a freeform GMPLS label.  A freeform GMPLS
> >>        label is specified by the system which uses it.  In other words,
> >>        the freeform GMPLS label is not a standard GMPLS label type,
> >>        but is created by the system which uses it."
> >
> >Nack
> >The text as originally stated is correct and your revision is wrong. That
> >is, the freeform label MAY also be used to represent standard labels

> >as octet strings.
> >This is a popular way to handle the management of multiple different types
> >of labels.
> >
> >Will change to:
> >        "This value represents a freeform GMPLS Label. This can be used
> >         to represent label that have label types which are not
> >         standardised. It may also be used by systems that do not wish to

> >         represent labels that have standardised label types using the

> >         type-specific objects in this table."
>
> Sorry, I'm still a little foggy on what this TC is, partly because the
> description is referring to "objects in this table" which is confusing
> in a TC DESCRIPTION, and also the definition of the freeform label
> used here and used in the GmplsGeneralizedLabelType enum seems be
> defined slightly differently.

 

Good point about "objects in this table." That needs to be removed.

 

So, the description of GmplsGeneralizedLabelTypes should be changed to read...

        Determines the interpretation that should be applied to an
        object that encodes a label.

 

But I don't see anything else in the GmplsGeneralizedLabelType enum that presents any interpretation of the freeform object.

> A freeform label as described in the DESCRIPTION clause
> could contain the value of any GMPLS/MPLS labels,
> right?

 

Right.

 

How about...

  "This Textual Convention can be used as the syntax of an object

   that contains any GMPLS label. Objects with this syntax can be

   used to represent labels that have label types that are not
   standardised. The freeform GMPLS Label may also be used by

   systems that do not wish to represent labels that have

   standardised label types using type-specific syntaxes."

> >> 2) GmplsGeneralizedLabelTypes  TC
>
> >> 2b)  Could the SYNTAX order be changed?
> >>
> >>     Currently:
> >>
> >>     SYNTAX INTEGER {
> >>        gmplsMplsLabel(1),
> >>        gmplsPortWavelengthLabel(2),
> >>        gmplsFreeformGeneralizedLabel(3),
> >>        gmplsSonetLabel(4),
> >>        gmplsSdhLabel(5),
> >>        gmplsWavebandLabel(6)
> >>      }
> >>
> >>     Proposed (NOTE also some of the names have been changed):
> >>
> >>    SYNTAX INTEGER {
> >>        gmplsFreeformLabelOrOther(1),
> >>        gmplsMplsLabel(2),
> >>        gmplsPortAndWavelengthLabel(3),
> >>        gmplsSonetLabel(4),
> >>        gmplsSdhLabel(5),
> >>        gmplsWavebandLabel(6)
> >>      }
> >
> >Nack
> >i.  "FreeformOrOther" What other? There is just freeform.
>
> Aren't the label types: gmplsMplsLabel(2),
> gmplsPortAndWavelengthLabel(3),
> gmplsSonetLabel(4),
> gmplsSdhLabel(5),
> gmplsWavebandLabel(6)
> also a kind of freeform GMPLS label (as indicated by the DESCRIPTION
> clause in GmplsFreeformLabel)?

 

It is all to do with the encodings of objects (i.e. the syntaxes) not the use to which the labels can be put. Thus, a normal 20-bit MPLS label an be encoded in an object with syntax MPLSLabel or in an object with syntax GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. In the latter case it is presented as an OCTET STRING.

 

> >ii. Why re-order? The new order seems to have no more logic than the
> >    old order.
>
> Partly depends on the answer to above i. question. 
> If the labels are a kind of freeform label,
> then a better style would be to list
> gmplsFreeformLabel first.  Admittedly, this is a NIT.
>
> Also, please add into the DESCRIPTION clause
> a definition for each enum (an example would
> be MplsLspType in RFC3811). 

 

Yes. That is a good idea.

 

Description will now read...

 

 DESCRIPTION

   "Determines the interpretation that should be applied to an
    object that encodes a label. The possible types are:

 

           gmplsMplsLabel(1)         - The label is an MPLS packet, cell,

                                       or frame label and is encoded as

                                       described for the Textual Convention

                                       MPLSLabel defined in RFC 3811.

    gmplsPortWavelengthLabel(2)      - The label is a port or wavelength

                                       label as defined in RFC 3741.

 

    gmplsFreeformGeneralizedLabel(3) - The label is any form of label encoded

                                       as an OCTET STRING using the Textual

                                       Convention GMPLSFreeformLabel.

    gmplsSonetLabel(4)               - The label is a SONET label as defined

                                       in RFC 3946.

    gmplsSdhLabel(5)                 - The label is an SDH label as defined in

                                       RFC 3946.

    gmplsWavebandLabel(6)            - The label is a waveband label as defined

                                       in RFC 3471."