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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Sep 2006 14:02:53 +0100

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.

===