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

[jcucchiara@mindspring.com]

Adrian,

Thank you for the quick turn around.  I have removed issues where we
are in agreement (both the ack'd and nack'd) and will comment only 
on those ones which might need further discussion (both ack'd and nack'd).

Please see comments inline.

  thanks, Joan


At 01:49 PM 9/22/05 +0100, Adrian Farrel wrote:
>Hi Joan,
>
>Thanks again for the thorough review.
>
>Please see below our responses on the general comments and the TC MIB
>module.
>
>I have indicated Ack or Nack for each point you raised.  Where there is a
>Nack I have indicated either our reasoning or a proposed alternate
>solution.
>
>Cheers,
>Adrian
>
>> General comments for all 3 drafts:
>> ================================================
>
>> 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".
>That covers all

According to the rfc-editor website above,
this should be "Contact Information", is this what you mean?



>
>
>> 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. 

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


>> 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)?

>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).