[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
Thanks for your thoroughness, Joan.
All points agreed.
Adrian
----- Original Message -----
From: <jcucchiara@mindspring.com>
To: <adrian@olddog.co.uk>; <tnadeau@cisco.com>; <ccamp@ops.ietf.org>
Cc: <bwijnen@lucent.com>; <jcucchiara@mindspring.com>
Sent: Wednesday, September 28, 2005 2:38 AM
Subject: 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).
>
>
>
>
>