The MPLS WG Archive

[jcucchiara@mindspring.com]

At 12:11 PM 2/6/04 -0500, Thomas D. Nadeau wrote:
>
>	Thanks for the review.
>
>> -----Original Message-----
>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>> Of jcucchiara@mindspring.com
>> Sent: Friday, February 06, 2004 11:19 AM
>> To: tnadeau@cisco.com; subrah@cisco.com
>> Cc: mpls@UU.NET
>> Subject: draft-ietf-mpls-lc-if-mib-01.txt
>> 
>> 
>> 
>> 
>> Hi Tom and Subrahmanya,
>> 
>> I have a few comments on this draft, please consider these
>> for last call comments.
>> 
>> Overall, I think adding more information with these 2 tables is
>> good, as it provides some extra information and will allow easier
>> look ups in other tables.
>> 
>> 
>> A couple of questions/clarifications:
>> -------------------------------------
>> 1.  Adrian asked about the relationship with some objects in
>>     the LDP MIB, and I would also like some clarification
>>     as to the relationship.
>
>	Yes, still need to get back to him. :P
>
>>     My initial reading led me to think that these LC interfaces
>>     were for static LSPs, are they also for LDP LSPs?
>
>	They work for any LC-ATM/FR Interfaces. Typically
>LDP is used to distributed the labels, but there
>was talk of using RSVP-TE or static too.  In
>any case, the ifs should work.
>
>>     In Section 3 "Terminology" the definition of the LC-ATM
>>     discusses LDP peers, so wanted clarification.  
>> 
>>     Is it necessary to support the MPLS-LDP-STD-MIB's Entity table
>>     in addition to the MPLS-LSR-STD-MIB's  mplsInterfaceTable?
>> 
>> 2.  I was confused as to why these tables are said to 
>>     "extend" the mplsInterfaceTable.  The relationship
>>     looks like it could be an AUGMENTS.  Please clarify.
>> 
>>      If this does turn out to be an AUGMENTS relationship then
>>      there is no need for the RowStatus and StorageType objects.
>> 
>>     
>> Comments in the order they appear in the draft:
>> -----------------------------------------------
>> 
>> Most of these are minor comments but just included them
>> for completeness.  Also, most of the comments which discuss something
>> specific about the LC-ATM 
>> MIB Module, also apply to the LC-FRAME-RELAY MIB Module, so I just
>> put a little comment where I did see that it would apply to 
>> the FRAME-RELAY
>> table also.
>> 
>> 1) table of contents numbering is wrong.
>> 
>> 2) need to update the use of MPLS-LSR-MIB/MPLS-LSR to MPLS-LSR-STD-MIB
>>    and MPLS-TE-MIB/MPLS-TE to MPLS-TE-STD-MIB
>> 
>> 3) Section 5. Interface Stacking of LC-ATM.  
>> 
>>    The last sentence of this section needs to be updated, 
>>    to replace references of mplsInterfaceConfTable with 
>>    mplsInterfaceTable.  Also the section numbers are incorrect,
>>    section 7 should be 6, section 8 should be 7.
>> 
>> 4) The name of the MIB Module should be:
>> 
>>    MPLS-LC-ATM-STD-MIB
>> 
>>    (In general this should be carried through the MIB Module so,
>>     mplsLcAtmMIB should be mplsLcAtmStdMIB, etc.)  This is to be
>>     consistent with the other MPLS MIB Modules.
>> 
>>     Similar comment for LC-FR MIB Module.
>> 
>> 5) CONTACT-INFO
>> 
>>    Needs to be updated for both co-authors.
>>     Similar comment for LC-FR MIB Module.
>> 
>> 6) DESCRIPTION 
>> 
>>    The mplsStdMIB sub-ids of 6 and 7 are already being 
>>    used (mplsLdpFrameRelayStdMIB and mplsLdpGenericStdMIB), 
>>    so please use numbers above 7.
>> 
>>     Similar comment for LC-FR MIB Module.
>> 
>> 
>> 7)  To be consistent with the latest MPLS-LSR-STD-MIB, should
>>     mplsLcAtmIfConfTable, be renamed to mplsLcAtmInterfaceTable?
>> 
>>     Similar comment for LC-FR MIB Module.
>> 
>> 
>> 8)  INDEX -- need clarification as to why AUGMENTS is not being
>>     used.  If AUGMENTS was used, then there would be no need
>>     for the mplsLcAtmIfConfRowStatus object and the 
>>     mplsLcAtmIfConfStoreType object.
>
>	We did not use AUGMENTS because there is
>not a 1-to-1 relationship for EVERY row in the
>parent table.  This it is an 'extends' relationship. 


Yes, I should have known ;)  During the MIB Dr. review
of the LDP MIB, this was changed to say it was a 'sparse augments'
relationship (rather than extends), which I think is more descriptive.

>
>>     Similar comment for LC-FR MIB Module.
>> 
>> 
>> 9) mplsLcAtmVcMerge DESCRIPTION
>> 
>>    gives a value of true(0), but this should be:
>> 
>> TruthValue ::= TEXTUAL-CONVENTION
>>     STATUS       current
>>     DESCRIPTION
>>             "Represents a boolean value."
>>     SYNTAX       INTEGER { true(1), false(2) }
>> 
>> 
>> 10) Compliance Statement.
>> 
>>     My preference would be to see 2 compliances.  One for 
>> full compliance
>>     and one read-only.  I think that there is only a read-only one.
>>
>>     Also, clarification about whether or not the mplsLdpEntityAtmTable
>>     needs to be supported and the relationship to the 
>> mplsLdpAtmLRTable
>>     which is Adrian's question could be clarified here also.
>
>	Yup. Need to look at this closely again.
>
>>     Similar comment for LC-FR MIB Module.
>> 
>> 
>> 11) Security Considerations
>> 
>>    Would be preferable to have separate sections for the
>>    LC-ATM MIB and the LC-FR MIB Modules.  This would be more
>>    consistent with the other MPLS MIBs.
>> 
>> 12) Reference for TC MIB needs to be updated, it is now at draft 10.
>> 
>> 13) Some of the References in the text do not agree with the
>>     Reference, for example, have seen [MPLSTCMIB] in the text
>>     but reference says [TCMIB]
>> 
>> 14) Section 10.  Subrahmanya's contact info does give city, 
>> state info.
>> 
>> 15) Section 11.  Copyright says 2001, should be 2004.
>> 
>> 16) Section 13.  IANA Considerations,  already mentioned above, 
>>      but please use numbers above 7.
>
>	The rest of the comments are fine; will fix.

Thanks!

  -Joan


>
>	--Tom
>
>
>> 
>> Thanks,
>>    -Joan
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>