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

["Masanori Miyazawa" <[e-mail]>]

Hi Young,

Thank you for your response.
We will modify the document based on comments including your other comments, and post it.

Regards,
Masanori


> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: Friday, November 09, 2012 3:30 AM
> To: Masanori Miyazawa; [e-mail]
> Cc: [e-mail];
> [e-mail]; 'CCAMP'
> Subject: RE: RtgDir review: draft-ietf-ccamp-gmpls-ted-mib-14.txt
> 
> 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
>