[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ietf-ccamp-gmpls-te-mib-16.txt submitted

Hi,

I have submitted this I-D updated after IESG review.

The changes are as follows.

Thanks,
Adrian

****************
draft-ietf-ccamp-gmpls-te-mib-15

===

Lars Eggert - Comment


Section 1.1., paragraph 2:

   LSRs may be migrated to model and manage their TE LSPs using the MIB
   modules in this document in order to migrate the LSRs to GMPLS
   support, or to take advandtage of additional MIB objects defined in


 Nit: s/advandtage/advantage/


Done


Section 8., paragraph 185:

       If the value of
       gmplsTunnelErrorLastErrorType is protocol (2) the error should
       be interpreted in the context of the signling protocol


 Nit: s/signling/signaling/


Done


Section 8., paragraph 198:

         The notification rate applies to the sum
         of all notificaitons in the MPLS-TE-STD-MIB and


 Nit: s/notificaitons/notifications/


Done


Section 9., paragraph 7:

   if the network itself is secure (for example by using IPSec), even


 Nit: s/IPSec),/IPsec),/


Done


Section 12.1., paragraph 22:

   [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
               Conventions for Multiprotocol Label Switching (MPLS)
               Management", draft-ietf-ccamp-gmpls-tc-mib, work in
               progress.


 Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced


Removed

===

Russ Housley - Discuss


 I don't understand gmplsTunnelLinkProtection.  I gather it is
described in RFC3471.  However it seems like this ought to be
 discussed in the security considerations.
Explanation in email to Russ resulted in this response. No editorial action taken. 


I had a DISCUSS based on this comment.  Thank for the explanation.  I've
cleared the DISCUSS.

Russ

At 12:34 PM 8/29/2006, Adrian Farrel wrote:

1. I don't understand the gmplsTunnelLinkProtection whose function is
described in RFC3471.  Since this document describes the MIB to
configure the field it probably shouldn't be an issue for this document.
However it would be good to know if the authors considered any
additional security considerations associated with this variable.


"Protection" here refers to the establishment of a secondary LSP that can
be used to carry the traffic in the event of the failure of the primary
LSP. It is not related to the Security use of the same term.

For more on GMPLS protection terminology you can read RFC4327.


===

Dan Romascanu - Discuss
ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module under transmission. That seems weird. By convention, transmission assignments generally correspond to ifType values, which would result in a "Relationship to the Interfaces MIB" section of the document. If they don't define a new ifType value, I don't see why it should be under transmission. If, on the other hand, this is intended to be the MIB for ifType = mpls (166), then it should have a "Relationship to the Interfaces MIB" section. I think it would be better to put this under the mib-2 tree or under the 
mplsStdMIB tree
After discussion, we determine that the module in question is IANA-GMPLS-TC-MIB.
We agreed that this module should be under the mib-2 tree. The document has been updated accordingly. 

===