[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt
Hi Adrian,
A couple of minor comments inline below.
thanks,
Joan
> ----- Original Message -----
> From: Adrian Farrel
> To: tnadeau@cisco.com ; ccamp@ops.ietf.org ; jcucchiara@mindspring.com
> Cc: bwijnen@lucent.com ; jcucchiara@mindspring.com
> Sent: Saturday, September 24, 2005 6:02 AM
> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt
>
>
> 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."
>
Instead of saying "not standardised" could you say "not defined in any
RFCs"?
This is a small point but not sure if a label in a "proposed standard"
is considered "standardised" yet.
Similarly, with the second use of "standarised" could you say "defined"?
> > >> 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.
Should be "MplsLabel"
>
> 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.
Please rename this enum to: gmplsFreeformLabel
which will match the GmplsFreeformLabel TC. (Also, GMPLSFreeformLabel
should be 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."
>
Please be sure to include all the above referenced RFCs in the
REFERENCE Clause of this object (and also in the Normative References
Section of this draft).