Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib

"Masanori Miyazawa" <ma-miyazawa@kddilabs.jp> Thu, 04 October 2012 23:55 UTC

Return-Path: <ma-miyazawa@kddilabs.jp>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48881F041F for <ccamp@ietfa.amsl.com>; Thu, 4 Oct 2012 16:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jyUqxja30WZ for <ccamp@ietfa.amsl.com>; Thu, 4 Oct 2012 16:55:53 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7571F041E for <ccamp@ietf.org>; Thu, 4 Oct 2012 16:55:51 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D517817481B1; Fri, 5 Oct 2012 08:55:38 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It2XWD00y2X9; Fri, 5 Oct 2012 08:55:37 +0900 (JST)
Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id E850B174817B; Fri, 5 Oct 2012 08:55:37 +0900 (JST)
Received: from miyazawaVAIO (dhcp50.wlan.kddilabs.jp [172.19.110.50]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id D41541E0002; Fri, 5 Oct 2012 08:55:37 +0900 (JST)
From: "Masanori Miyazawa" <ma-miyazawa@kddilabs.jp>
To: <adrian@olddog.co.uk>, <draft-ietf-ccamp-gmpls-ted-mib.all@tools.ietf.org>
References: <0b7101cd3de9$8bfadbc0$a3f09340$@olddog.co.uk> <00ef01cd43b1$35ebf160$a1c3d420$@kddilabs.jp> <153401cd8046$b2af4770$180dd650$@olddog.co.uk>
In-Reply-To: <153401cd8046$b2af4770$180dd650$@olddog.co.uk>
Date: Fri, 5 Oct 2012 08:55:33 +0900
Message-ID: <004b01cda28b$bddd4040$3997c0c0$@kddilabs.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHQW7vPShMYMTWtVF3+Petz8y8AvgFifFZkAgasLsGXiRPgAA==
Content-Language: ja
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2012 23:55:53 -0000

Adrian

I revised the document based on your comments.
Could you please confirm it?

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-14

Regards,
Masanori

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Wednesday, August 22, 2012 6:16 PM
> To: 'Masanori Miyazawa';
> draft-ietf-ccamp-gmpls-ted-mib.all@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: RE: AD review of draft-ietf-ccamp-gmpls-ted-mib
> 
> Hi,
> 
> I'm sorry! I missed this email.
> 
> Please see in line.
> 
> > > Could you please sort out "MIB" versus "MIB module". There is only
> > > one MIB. There are many MIB modules - this document defines a MIB
> > > module
> > >
> > [Masanori Miyazawa]
> > # I could not understand above comment. You mean that descriptions of
> > "MIB modules" exit in this document?
> 
> Mainly you should talk about "the MIB module defined in this document".
> 
> The MIB module defined in this document forms part of "the MIB" i.e. all
> the data in the whole world:-)
> 
> > > You need to avoid using citations (e.g. [RFC3630]) within the MIB
> > > module itself. MIB modules are extracted from their documents and
stand
> alone.
> 
> This means that you are allowed to use square brackets between in the MIB
> module itself.
> 
> Some example changes are...
> 
> OLD
>    tedTable OBJECT-TYPE
>       SYNTAX       SEQUENCE OF TedEntry
>       MAX-ACCESS   not-accessible
>       STATUS       current
>       DESCRIPTION
>         "This table indicates multiple TED information which has been
>    supported by [RFC3630]."
>    ::= { tedObjects 1 }
> NEW
> tedTable OBJECT-TYPE
>       SYNTAX       SEQUENCE OF TedEntry
>       MAX-ACCESS   not-accessible
>       STATUS       current
>       DESCRIPTION
>         "This table indicates multiple TED information which has been
>          supported by RFC 3630."
>       REFERENCE
>         "Traffic Engineering (TE) Extensions to OSPF Version 2,
>          RFC 3630."
>    ::= { tedObjects 1 }
> END
> 
> 
> OLD
>    tedLocalRouterId OBJECT-TYPE
>        SYNTAX       TedRouterIdTC
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>          "This object represents the router ID of the router originating
>    the LSA. If OSPF is used to advertise LSA, this represents a Router
>    ID. If ISIS is used, this represents a System ID. Otherwise, this
>    represents zero."
>        REFERENCE
>          " OSPF Version 2, [RFC2328], C.1
>            OSPF for IPv6, [RFC5340], C.1
>            [ISO10589], Section 7.1 "
>    ::= { tedEntry 2 }
> NEW
>    tedLocalRouterId OBJECT-TYPE
>        SYNTAX       TedRouterIdTC
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION
>          "This object represents the router ID of the router originating
>    the LSA. If OSPF is used to advertise LSA, this represents a Router
>    ID. If ISIS is used, this represents a System ID. Otherwise, this
>    represents zero."
>        REFERENCE
>          "1. OSPF Version 2, RFC 2328, C.1
>           2. OSPF for IPv6, RFC 5340, C.1
>           3. Intermediate system to Intermediate system routeing
>              information exchange protocol for use in conjunction with
>              the Protocol for providing the Connectionless-mode Network
>              Service (ISO 8473), ISO10589, Section 7.1."
>    ::= { tedEntry 2 }
> END
> 
> 
> OLD
>    tedLinkType OBJECT-TYPE
>        SYNTAX       INTEGER {
>                     pointToPoint (1),
>                     multiAccess (2)
>                     }
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION
>          "This indicates the type of the link such as point-to-point or
>    multi-access."
>        REFERENCE
>          " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC
>    3630], 2.5.1"
>    ::= { tedEntry 8 }
> NEW
>    tedLinkType OBJECT-TYPE
>        SYNTAX       INTEGER {
>                     pointToPoint (1),
>                     multiAccess (2)
>                     }
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION
>          "This indicates the type of the link such as point-to-point or
>    multi-access."
>        REFERENCE
>          "Traffic Engineering (TE) Extensions to OSPF Version 2,
>           RFC 3630, 2.5.1"
>    ::= { tedEntry 8 }
> END
> 
> 
> > > I'm having some trouble with the use of 2119 language in the
> > > Description for tedLinkInformationData.
> > >
> > > Two examples...
> > >
> > >           If tedLinkInformationSource has the value unknown(0), this
> > >        object SHOULD contain a value of zeroDotZero.
> > >
> > > Under what circumstances can this use of "SHOULD" be varied?
> > [Masanori Miyazawa]
> > # At this time, we do not have a detailed situation to vary change to
> > the value unknown (0).
> > Should we delete the word "SHOULD"? or should the value unknown (0) be
> > deleted in this MIB if it is not used?
> 
> This looks like it needs to read...
> 
>         If tedLinkInformationSource has the value unknown(0), this
>         object MUST contain a value of zeroDotZero.
> 
> > >           If tedLinkInformationSource has the value
> > >        locallyConfigured(1), this object MAY contain the identifier
> of
> > >        the corresponding row entry in the teLinkTable of TE-LINK-STD-
> > >        MIB[RFC4220], the identifier of the corresponding row in a
local
> > >        proprietary TE link MIB module, or the value of zeroDotZero
> > >        otherwise.
> > >
> > > The use of "MAY" here implies that an implementation can choose to
> > > fill in the row pointer if it likes, but this is entirely an
> > > implementation choice. Is this what you are saying, or do you want
> > > to constrain the behavior more forcefully if TE-LINK-STD-MIB is
> implemented?
> > >
> > [Masanori Miyazawa]
> > # No, we think the implementation of this object is not constrained
> > forcefully.  If the pointer is needed, we think this object should be
> used.
> 
> OK.
> How about making it...
> 
>            If tedLinkInformationSource has the value
>         locallyConfigured(1), an implementation can use this object to
>         supply the identifier of the corresponding row entry in the
>         teLinkTable of TE-LINK-STD-MIB (RFC 4220), the identifier of
>         the corresponding row in a local proprietary TE link MIB module,
>         or the value of zeroDotZero.
> 
> > >    tedLocalIfAddrEntry OBJECT-TYPE
> > >        SYNTAX       TedLocalIfAddrEntry
> > >        MAX-ACCESS   not-accessible
> > >        STATUS       current
> > >        DESCRIPTION
> > >          "This entry contains the IP address information of the
> > > local TE
> > >    link."
> > >        INDEX { tedLinkIndex, tedLocalIfAddr }
> > >    ::= { tedLocalIfAddrTable 1 }
> > >
> > >    TedLocalIfAddrEntry ::= SEQUENCE {
> > >        tedLocalIfAddrType    InetAddressType,
> > >        tedLocalIfAddr        InetAddress
> > >
> > >        }
> > >
> > > What would it look like to walk this table by increasing index value?
> > > Would all the shorter v4 addresses show first, or would the
> > > numerically smaller v6 addresses get mixed in with the v4 addresses?
> > >
> > > If the latter is possible, you should use the address type as an
> > > index as well.
> > >
> > [Masanori Miyazawa]
> > # As you know, note that tedLocalIfAddrTable as well as
> > tedRemoteIfAddrTable are independently defined, because the Interface
> > IP Address sub-TLV may appear more than once within the same Link-TLV.
> > Therefore, if the address is only used as index, another arbitrary
> > index such as tedIndex would be also needed to represent the
> > relationship with tedTable.
> 
> OK. Understood.
> 
> > > tedStatusChangeNotificationMaxRate and
> > > tedCreatedDeletedNotificationMaxRate
> > >
> > > I am surprised that the Defval for these is 0 (no throttling) since
> > > the text recognises that this is a risky situation that may cause
> > > the box to blow up. Surely the default should be some safe setting.
> > >
> > > But then I wondered what a suitable safe setting would be and
> > > realised it would be "No Notifications". Except there is no way to
> > > say this with these objects.
> > >
> > > What do you think?
> > [Masanori Miyazawa]
> > #The reason for setting 0 as defval is to prevent sudden increase in
> > notification information. If we set the value as 10, the SNMP manager
> > would receive a number of alarms which is proportional to number of
> > routers. For instance, same ospf domain consists of 5 routers, the
> > SNMP manager would receive up to 50 alarms. So, I think that the optimal
> value of defval is 1.
> 
> OK. Make that change.
> 
> > > For completeness, we usually get asked to state in the Security
> > > section what the risks are with write access objects. In this case
> > > it is really easy...
> > >
> > >    There are only two write-access objects in this MIB module:
> > >    tedStatusChangeNotificationMaxRate and
> > >    tedCreatedDeletedNotificationMaxRate.  Malicious modification of
> > >    these objects could cause the management agent, the network, or the
> > >    router to become overloaded with Notifications in cases of high
> > >    churn within the network.
> > [Masanori Miyazawa]
> > # You mean that we only need to describe the above sentence in section
> > 8[security consideration]?
> 
> Yes.
> 
> Thanks,
> Adrian
>