Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 05 October 2012 11:19 UTC
Return-Path: <adrian@olddog.co.uk>
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 60ECA21F86C6 for <ccamp@ietfa.amsl.com>; Fri, 5 Oct 2012 04:19:03 -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 0-QhHUzL+LV0 for <ccamp@ietfa.amsl.com>; Fri, 5 Oct 2012 04:19:02 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id CEEE621F86C5 for <ccamp@ietf.org>; Fri, 5 Oct 2012 04:19:01 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95BIxuc012319; Fri, 5 Oct 2012 12:19:00 +0100
Received: from 950129200 ([31.99.224.215]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q95BIuvf012270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Oct 2012 12:18:58 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Masanori Miyazawa' <ma-miyazawa@kddilabs.jp>, 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> <004b01cda28b$bddd4040$3997c0c0$@kddilabs.jp>
In-Reply-To: <004b01cda28b$bddd4040$3997c0c0$@kddilabs.jp>
Date: Fri, 05 Oct 2012 12:18:55 +0100
Message-ID: <10ca01cda2eb$36851cc0$a38f5640$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHQW7vPShMYMTWtVF3+Petz8y8AvgFifFZkAgasLsECzcHc8pdzZlqQ
Content-Language: en-gb
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
Reply-To: adrian@olddog.co.uk
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: Fri, 05 Oct 2012 11:19:03 -0000
Thanks. Looks pretty good. I have requested IETF last call. I think the WG may want to look at the document again during the last call to check they are happy with all the changes. Adrian > -----Original Message----- > From: Masanori Miyazawa [mailto:ma-miyazawa@kddilabs.jp] > Sent: 05 October 2012 00:56 > To: adrian@olddog.co.uk; 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 > > 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 > >
- [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-m… Adrian Farrel
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Masanori Miyazawa
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Adrian Farrel
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Masanori Miyazawa
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Adrian Farrel
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Masanori Miyazawa
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Masanori Miyazawa
- Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-t… Adrian Farrel