The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

	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. 

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

	--Tom


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