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