Hello, 

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html 
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 

Document: draft-ietf-ccamp-gmpls-ted-mib-14.txt 
Reviewer: Young Lee
Review Date: 17 October 2012 
IETF LC End Date: 18 October 2012
Intended Status: Standard track

Summary: 
I have no major concerns about this document that I think should be resolved before publication. 

Comments: 
This document is clearly written, but hard to read due to tight indentations and no spacing between major sections and paragraphs throughout the whole document.   

Major Issues: 
No major issues found. 

Minor Issues: 

Abstract

Indentations need to be fixed

Section 2 Introduction

S/ On the other side, MPLS/GMPLS based traffic 
   engineering has so far extended OSPF/ISIS routing protocol with TE 
   functionality [RFC4202], [RFC3630], [RFC5329], [RFC5307], [RFC5305]. 
/ On the other side, MPLS/GMPLS based traffic 
   engineering has so far extended OSPF/ISIS routing protocol with TE 
   functionality per [RFC4202], [RFC3630], [RFC5329], [RFC5307] and [RFC5305]. 

Section 2

S/ To manage such MPLS-TE/GMPLS networks effectively, routing 
   information associated with MPLS/GMPLS TE parameters (TED) is 
   preferred for the network management, however, there is no clear 
   definition of MPLS/GMPLS TE information in existing MIBs related to 
   OSPF(v2 and v3)/ISIS. 
/ To manage such MPLS-TE/GMPLS networks effectively, routing 
   information associated with MPLS/GMPLS TE parameters (TED) is 
   preferred for the network management; however, there is no clear 
   definition of MPLS/GMPLS TE information in existing MIBs related to 
   OSPF(v2 and v3)/ISIS. 

Section 3.3 – Please use consistent cases for all acronyms. 

GMPLS: Generalized Multi-Protocol Label Switching 
   ISIS:  Intermediate System to Intermediate System 
   LSA:   Link state advertisement  Link State Advertisement
   LSP:   Label Switching Path 
   LSR:   Label Switching Router 
   MIB:   Management Information Base 
   OSPF:  Open Shortest Path First 
   PSC:   Packet switch capable -> Packet Switch Capable
   SRLG:  Shared risk link group -> Shared Risk Link Group
   TE:    Traffic Engineering 
   TED:   Traffic Engineering Database 
   TDM:   Time Division Multiplexing 

Section 5.3 – Style of consistency with Section 5.2

S / Also, this is utilized independently because one or more local interface IP address sub TLVs may exist in the same Link-TLV. 
/ This is independently defined, because the Interface IP Address sub-TLV may 
   appear more than once within the same Link-TLV. 

Section 5.4 and 5.5 --- same comment as above

Section 7 

-	Not clear what these MIB Definitions are all about. If these need to be supported, there should statements that these are additional MIBS to be added to existing MIB, etc.  

Style of writing in the following sentence

S / These are the tables and objects and their 
   sensitivity/vulnerability: tedTable, tedLocalIfAddrTable, 
   tedRemoteIfAddrTable, tedSwCapTable and tedSrlgTable contain topology 
   information for the MPLS/GMPLS network.
/ The list of tables and objects that may be vulnerable or sensitive: tedTable, tedLocalIfAddrTable, tedRemoteIfAddrTable, tedSwCapTable and tedSrlgTable. They contain topology information for the MPLS/GMPLS network.

Section 9.1 --- Not clear what is being asked to the IANA. Would it be more specific than “transmission XXX”? Need come clarification on this. 

The IANA is requested to assign {transmission XXX } to the TED-MIB 
   module specified in this document. 


 
Nits: 

Please correct the following issues generated by the Nits tool:

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

  -- The document date (October 4, 2012) is 14 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC2328' is defined on line 1552, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4001' is defined on line 1566, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4801' is defined on line 1579, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5340' is defined on line 1587, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6340' is defined on line 1593, but no explicit
     reference was found in the text

  == Unused Reference: 'ISO10589' is defined on line 1596, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4220' is defined on line 1625, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'


Young