Re: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-ted-mib-14.txt

[Leeyoung <[e-mail]>]

Dear Masanori,

If the new IANA TED-MIB assignment cannot be known a priori before the submission, I am fine with the current statement. 

Thanks.
Young

-----Original Message-----
From: Masanori Miyazawa [mailto:[e-mail]] 
Sent: Wednesday, November 07, 2012 7:18 PM
To: Leeyoung; [e-mail]
Cc: [e-mail]; [e-mail]; 'CCAMP'
Subject: RE: RtgDir review: draft-ietf-ccamp-gmpls-ted-mib-14.txt

Dear Young,

Thank you for your comments. We modified the document based on your comments.
Regarding IANA consideration section in your comments, we think that this was typo, this should read "yyy".
Is it right?
However, we believe that IANA will know what is expected for this action since it mirrors the actions they have applied for many other MIB modules.

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

Regards,
Masanori

> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: Friday, October 19, 2012 2:22 AM
> To: [e-mail]
> Cc: [e-mail];
> [e-mail]; CCAMP
> Subject: RtgDir review: draft-ietf-ccamp-gmpls-ted-mib-14.txt
> 
> 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