From bclaise@cisco.com Wed Jan 2 03:33:22 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7A21F9096; Wed, 2 Jan 2013 03:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 2qbUlsa5LLr0; Wed, 2 Jan 2013 03:33:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2146B21F9092; Wed, 2 Jan 2013 03:33:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02BXBj5004279; Wed, 2 Jan 2013 12:33:13 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02BX8VT021319; Wed, 2 Jan 2013 12:33:08 +0100 (CET) Message-ID: <50E41AF4.4050208@cisco.com> Date: Wed, 02 Jan 2013 12:33:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "ops-dir@ietf.org" , "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary="------------060001090604070607000701" Cc: "adslmib-chairs@ietf.org" , Lynne Bartholomew , Edward Beili , Moti Morgenstern Subject: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 11:33:22 -0000 This is a multi-part message in MIME format. --------------060001090604070607000701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mib&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), we discussed with the RFC editor whether the following RFCs should be normative or informative: Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. I thought that they should be normative, based on the justification at http://www.ietf.org/iesg/statement/normative-informative.html Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. The RFC editors answered: Thank you for the email. We see your point and agree that it makes sense that the references would be listed as normative, but we do not make calls on which documents are listed as informative vs normative. We note that https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists the six references in question -- RFCs 3410, 3414,3826, 5591, 5592, and 6353 -- as informative. Please request that the wiki be updated, if necessary. So normative or informative references? Shall I update the WIKI? Regards, Benoit --------------060001090604070607000701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mib&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), we discussed with the RFC editor whether the following RFCs should be normative or informative: 
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].
I thought that they should be normative, based on the justification at http://www.ietf.org/iesg/statement/normative-informative.html
Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.
The RFC editors answered:
Thank you for the email.  We see your point and agree that it makes sense that the references would be listed as normative, but we do not make calls on which documents are listed as informative vs normative.  We note that https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, and 6353 -- as informative. Please request that the wiki be
updated, if necessary.
So normative or informative references?
Shall I update the WIKI?

Regards, Benoit



--------------060001090604070607000701-- From bwijnen@bwijnen.net Wed Jan 2 04:59:51 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0833821F90D5; Wed, 2 Jan 2013 04:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 chdYU+eqEvYz; Wed, 2 Jan 2013 04:59:50 -0800 (PST) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 31BF921F90BB; Wed, 2 Jan 2013 04:59:47 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.80) (envelope-from ) id 1TqNuw-0001Eq-Dg; Wed, 02 Jan 2013 13:59:34 +0100 Message-ID: <1B68AEB678704642B3C4C8FBC528D4A9@BertLaptop> From: "Bert Wijnen" To: "Benoit Claise" , , "MIB Doctors \(E-mail\)" References: <50E41AF4.4050208@cisco.com> In-Reply-To: <50E41AF4.4050208@cisco.com> Date: Wed, 2 Jan 2013 13:52:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_165F_01CDE8F0.74F809E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: adslmib-chairs@ietf.org, Lynne Bartholomew , Edward Beili , Moti Morgenstern Subject: Re: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 12:59:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_165F_01CDE8F0.74F809E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC3410 is an informational document and has ALWAYS been listed as = informational. So... if you make it Normative, you have a downref. The 3414 and 3826 might be listed as Normative. The otehr 3 are only listed as MAY implement. So would it then have to = be normative? For me the most important thing is that the pointers to all this documents are listed, so you can quickly find them. Bert ----- Original Message -----=20 From: Benoit Claise=20 To: ops-dir@ietf.org ; MIB Doctors (E-mail)=20 Cc: adslmib-chairs@ietf.org ; Lynne Bartholomew ; Edward Beili ; Moti = Morgenstern=20 Sent: Wednesday, January 02, 2013 12:33 PM Subject: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: = normative or informative references? Dear all, In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt = (https://datatracker.ietf.org/doc/search/?name=3Ddraft-ietf-adslmib-gbond= -mib&rfcs=3Don&activeDrafts=3Don&author=3D&group=3D&area=3D&ad=3D&state=3D= &subState=3D), we discussed with the RFC editor whether the following = RFCs should be normative or informative:=20 Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they = should be normative, based on the justification at = http://www.ietf.org/iesg/statement/normative-informative.html Normative references specify documents that must be read to = understand or implement the technology in the new RFC, or whose = technology must be present for the technology in the new RFC to work.=20 The RFC editors answered: Thank you for the email. We see your point and agree that it makes = sense that the references would be listed as normative, but we do not = make calls on which documents are listed as informative vs normative. = We note that https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security = lists the six references in question -- RFCs 3410, 3414, 3826, 5591, = 5592, and 6353 -- as informative. Please request that the wiki be updated, if necessary. So normative or informative references? Shall I update the WIKI? Regards, Benoit -------------------------------------------------------------------------= ----- _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ------=_NextPart_000_165F_01CDE8F0.74F809E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC3410 is an informational document and has ALWAYS = been=20 listed as informational.
So... if you make it Normative, you have a=20 downref.
The 3414 and 3826 might be listed as = Normative.
 
The otehr 3 are only listed as MAY implement. So = would it then=20 have to be normative?
 
For me the most important thing is that the pointers = to all=20 this
documents are listed, so you can quickly find=20 them.
 
Bert
 
----- Original Message -----
From:=20 Benoit = Claise=20
To: ops-dir@ietf.org ; MIB = Doctors=20 (E-mail)
Cc: adslmib-chairs@ietf.org ; = Lynne=20 Bartholomew ; Edward Beili ; Moti Morgenstern =
Sent: Wednesday, January 02, = 2013 12:33=20 PM
Subject: [MIB-DOCTORS] Security = Guidelines for IETF MIB Modules: normative or informative = references?

Dear all,

In the AUTH48 process for=20 draft-ietf-adslmib-gbond-mib-11.txt (https://datatracker.= ietf.org/doc/search/?name=3Ddraft-ietf-adslmib-gbond-mib&rfcs=3Don&am= p;activeDrafts=3Don&author=3D&group=3D&area=3D&ad=3D&= state=3D&subState=3D),=20 we discussed with the RFC editor whether the following RFCs should be=20 normative or informative: 
   Implementations MUST =
provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].
I thought = that they=20 should be normative, based on the justification at ht= tp://www.ietf.org/iesg/statement/normative-informative.html
Normative references specify documents that must be read = to=20 understand or implement the technology in the new RFC, or whose = technology=20 must be present for the technology in the new RFC to work. =
The=20 RFC editors answered:
Thank you for the email.  We see your point and agree that = it=20 makes sense that the references would be listed as normative, but we = do not=20 make calls on which documents are listed as informative vs = normative.=20  We note that https= ://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists=20 the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, and 6353 -- as informative. Please request that = the wiki=20 be
updated, if necessary.
So normative or = informative=20 references?
Shall I update the WIKI?

Regards, = Benoit



_______________________________________________
MIB-DOCTORS = mailing=20 = list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib= -doctors
------=_NextPart_000_165F_01CDE8F0.74F809E0-- From bclaise@cisco.com Wed Jan 2 07:55:18 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C272B21F8433 for ; Wed, 2 Jan 2013 07:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8se7T7AMVIQw for ; Wed, 2 Jan 2013 07:55:18 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 19AFD21F8432 for ; Wed, 2 Jan 2013 07:55:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02FtA4u002453; Wed, 2 Jan 2013 16:55:10 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02Ft88L026277; Wed, 2 Jan 2013 16:55:09 +0100 (CET) Message-ID: <50E4585C.1080207@cisco.com> Date: Wed, 02 Jan 2013 16:55:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nevil Brownlee , Ronald Bonica , "MIB Doctors (E-mail)" , Juergen Schoenwaelder References: <50D0E6C4.4020105@auckland.ac.nz> <20121218221343.GA80603@elstar.local> In-Reply-To: <20121218221343.GA80603@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] [eman] IESG writeup for draft-ietf-eman-rfc4133bis-05 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:55:18 -0000 Hi Juergen, Would you be willing to review this one part of the MIB doctor process? Regards, Benoit > On Wed, Dec 19, 2012 at 10:57:24AM +1300, Nevil Brownlee wrote: >> >> Juergen Schoenwalder was particularly helpful as a reviewer at WGLC >> though the changes srising were minor. >> >> If there was a MIB Doctor, Media Type or other expert review, what was >> its course (briefly)? >> >> Two of the draft's editors are on the MIB Doctors list, so is >> Juergen Schoenwalder. >> > Note that I did _not_ do a complete MIB doctor review. I only reviewed > the diffs; there might be consistency/terminology issues somewhere > hidden in the old text which I did not review. > > /js > From ietfdbh@comcast.net Thu Jan 3 08:20:21 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104221F8521 for ; Thu, 3 Jan 2013 08:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7G6+MDGR-oIc for ; Thu, 3 Jan 2013 08:20:20 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 7357921F8461 for ; Thu, 3 Jan 2013 08:20:17 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id jR6q1k00316LCl05EULGAq; Thu, 03 Jan 2013 16:20:16 +0000 Received: from [192.168.0.14] ([71.233.85.150]) by omta06.westchester.pa.mail.comcast.net with comcast id jULD1k01R3Ecudz3SULFFl; Thu, 03 Jan 2013 16:20:16 +0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 03 Jan 2013 11:20:13 -0500 From: David Harrington To: Bert Wijnen , Benoit Claise , , "MIB Doctors (E-mail)" Message-ID: Thread-Topic: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? In-Reply-To: <1B68AEB678704642B3C4C8FBC528D4A9@BertLaptop> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357230016; bh=mCqdBnWewT8acePlFIhbKyi9H4GC1htPx9nYmZ48xxE=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=WV8UqezItFB8VGaIYTs7PfPzP8hUCXxKvNM7zUoMGL/ArYPVzMRoovtzFIW905EoI b+D+p+djfzUrE+XxSgbPVQiJR9QP4tF/qPw6HxqQdWeLwidRIjinCycbPwPxRmjBax o5eN+TkM8ubH+JhXU/580n/bEzIvUjs84Mo9qeJgHy9TLN+QfCrrjdMCyDGggv128w rdYmGP1Xlqm2oBt4FvQwLuavO3hELPhIhAnJHpVbnhk27umnUeMMA6hgfH3ccj8Mhv 9QVyjRkI6ihVUpG9Iz8ed4kUkjvcGPU5A/a6ocujcGyWWsv8AfqS5PLPXiHldvlJgY wi8an/lr3L80Q== Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:20:21 -0000 Hi, The mib security boilerplate changed in December of 2011, following discussion between the OPS and Security ADs and the MIB Doctors. IIRC, we always made implementation of SNMPv3 recommended but not required. No MIB module (except those specifically related to managing SNMPv3) should require SNMPv3 to work. Any MIB theoretically should work with any version of SNMP (given known interoperability issues of SNMPv1 vs SMIv2, etc.). Theoretically (and according to IAB recommendations in RFC1052), the MIB should also be able to work with protocols other than SNMP, since "The MIB" is just a database that (theoretically) is independent of the protocol used to access it. So no MIB module (with exceptions) should REQUIRE a specific protocol or protocol version to access it. (yawn. I'm sure you guys are tired of hearing this from me ;-) We deliberately made RFC3410 Informational to avoid downrefs. IIRC, you cannot implement RFC3410 because it doesn't define a protocol; it's just a roadmap. SNMPv3 was designed as something of a framework that could be built from multiple pieces - a messaging model, a security model, an ACM model, etc. RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it was definitely an SNMPv3 WG decision that this was AN architecture, not THE architecture for SNMPv3, to allow for alternative approaches (such as ISMS work on transport models) and to allow for implementation-specific decisions that would not affect the on-the-wire protocol. The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which RFCs actually make up SNMPv3, and are MUST implement). But that seems to fly in the face of the SNMPv3 WG intention to NOT make a certain set of RFCs **THE** SNMPv3 definition. (Of course, the IESG approved an IETF Standard called SNMPv3, which contained the RFC34xx series as a set of RFCs within the somewhat-abstract SNMPv3 Standard, to ensure base interoperability.) I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs MUST be implemented, and make those references normative. I.e., what you would be doing is defining THE set of RFCs that define SNMPv3. I personally think it best not to require a specific version of SNMP as part of the boilerplate for a MIB module. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 1/2/13 7:52 AM, "Bert Wijnen" wrote: >RFC3410 is an informational document and has ALWAYS been >listed as informational. >So... if you make it Normative, you have a >downref. >The 3414 and 3826 might be listed as Normative. > >The otehr 3 are only listed as MAY implement. So would it then >have to be normative? > >For me the most important thing is that the pointers to all >this >documents are listed, so you can quickly find >them. > >Bert > > > ----- Original Message ----- > From: > Benoit Claise > > To: ops-dir@ietf.org ; MIB Doctors > (E-mail) > Cc: adslmib-chairs@ietf.org ; Lynne > Bartholomew ; Edward Beili > ; Moti Morgenstern > > Sent: Wednesday, January 02, 2013 12:33 > PM > Subject: [MIB-DOCTORS] Security > Guidelines for IETF MIB Modules: normative or informative references? > >Dear all, > >In the AUTH48 process for > draft-ietf-adslmib-gbond-mib-11.txt >(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi >b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), > we discussed with the RFC editor whether the following RFCs should be > normative or informative: > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they > should be normative, based on the justification at >http://www.ietf.org/iesg/statement/normative-informative.html > Normative references specify documents that must be read to > understand or implement the technology in the new RFC, or whose >technology > must be present for the technology in the new RFC to work. > >The > RFC editors answered: > > Thank you for the email. We see your point and agree that it > makes sense that the references would be listed as normative, but we >do not > make calls on which documents are listed as informative vs normative. > We note that >https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists > the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, >and 6353 -- as informative. Please request that the wiki > be >updated, if necessary. > > >So normative or informative > references? >Shall I update the WIKI? > >Regards, Benoit > > > > > >________________________________________ > > _______________________________________________ >MIB-DOCTORS mailing > list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors > > >_______________________________________________ >OPS-DIR mailing list >OPS-DIR@ietf.org >https://www.ietf.org/mailman/listinfo/ops-dir From bclaise@cisco.com Tue Jan 8 02:58:22 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59421F8EDC; Tue, 8 Jan 2013 02:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] 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 9PwgDWehEWgu; Tue, 8 Jan 2013 02:58:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 85F7B21F8ED5; Tue, 8 Jan 2013 02:58:21 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08AwJgE016474; Tue, 8 Jan 2013 11:58:19 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08AwJMF013143; Tue, 8 Jan 2013 11:58:19 +0100 (CET) Message-ID: <50EBFBCA.40209@cisco.com> Date: Tue, 08 Jan 2013 11:58:18 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20130107232516.3109.98148.idtracker@ietfa.amsl.com> In-Reply-To: <20130107232516.3109.98148.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130107232516.3109.98148.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: UPDATED Agenda and Package for the January 10, 2013 Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:58:22 -0000 Dear all, Please find below the agenda of the January 10th IESG telechat. Please send your questions, comments, and concerns before January 9th COB. Specifically for the OPS people in these mailer, I would like to draw your attention to the I2RS charter. See https://datatracker.ietf.org/doc/charter-ietf-i2rs/ Thanks and Regards, Benoit ============================================== INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-01-10 IESG Teleconference This agenda was generated at 2013-01-07 15:22:43 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-bliss-call-completion-18 Call Completion for Session Initiation Protocol (SIP) (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the document shepherd. Token: Robert Sparks o draft-ietf-appsawg-json-patch-09 JSON Patch (Proposed Standard) Token: Barry Leiba o draft-ietf-appsawg-json-pointer-08 JavaScript Object Notation (JSON) Pointer (Proposed Standard) Token: Barry Leiba o draft-ietf-v6ops-464xlat-08 464XLAT: Combination of Stateful and Stateless Translation (Best Current Practice) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-mboned-auto-multicast-14 Automatic Multicast Tunneling (Proposed Standard) Note: Lenny Giuliano (lenny@juniper.net) is the Document Shepherd. Token: Ronald Bonica o draft-ietf-sipcore-priority-00 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field (Proposed Standard) Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-dhc-relay-id-suboption-11 The DHCPv4 Relay Agent Identifier Suboption (Proposed Standard) Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd. Token: Ralph Droms 2.2 Individual Submissions 2.2.1 New Items o draft-salgueiro-vcarddav-kind-device-06 vCard KIND:device (Proposed Standard) Token: Pete Resnick o draft-daboo-ical-vcard-parameter-encoding-02 Parameter Value Encoding in iCalendar and vCard (Proposed Standard) Token: Barry Leiba o draft-bonica-special-purpose-05 Special-Purpose IP Address Registries (Best Current Practice) Note: The document shepherd is Joel Halpern,  . Token: Ralph Droms 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-karp-routing-tcp-analysis-06 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide (Informational) Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-v6ops-icp-guidance-04 IPv6 Guidance for Internet Content and Application Service Providers (Informational) Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-6renum-enterprise-05 IPv6 Enterprise Network Renumbering Scenarios, Considerations and Methods (Informational) Note: Lee Howard (lee.howard@twcable.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-trill-oam-req-04 Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links) (Informational) Note: The Document Shepherd is Donald Eastlake (d3e3e3@gmail.com). Token: Ralph Droms 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-wilde-describes-link-00 IETF conflict review for draft-wilde-describes-link draft-wilde-describes-link-02 The 'describes' Link Relation Type (ISE: Informational) Token: Barry Leiba 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Interface to the Routing System (i2rs) 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o IP Security Maintenance and Extensions (ipsecme) 4.2.2 Proposed for Approval NONE From bclaise@cisco.com Tue Jan 8 04:03:54 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D721F8CD8 for ; Tue, 8 Jan 2013 04:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5qch0wp9hDL0 for ; Tue, 8 Jan 2013 04:03:53 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAB421F8CD7 for ; Tue, 8 Jan 2013 04:03:53 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08C3qk2024145 for ; Tue, 8 Jan 2013 13:03:52 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08C3pP7002272; Tue, 8 Jan 2013 13:03:52 +0100 (CET) Message-ID: <50EC0B27.2090409@cisco.com> Date: Tue, 08 Jan 2013 13:03:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stewart Bryant Subject: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:03:54 -0000 MIB doctors, http://www.rfc-editor.org/errata_search.php?eid=3292 I would like to double-check that this errata should be verified. Regards, Benoit From j.schoenwaelder@jacobs-university.de Tue Jan 8 04:56:41 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48E21F8B0E for ; Tue, 8 Jan 2013 04:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 XsovvhI4OygP for ; Tue, 8 Jan 2013 04:56:40 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 92C8921F8AE3 for ; Tue, 8 Jan 2013 04:56:40 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7752520BD5; Tue, 8 Jan 2013 13:56:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0V-K0hjEYce5; Tue, 8 Jan 2013 13:56:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0249320746; Tue, 8 Jan 2013 13:56:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BD7D723D4FC5; Tue, 8 Jan 2013 13:56:38 +0100 (CET) Date: Tue, 8 Jan 2013 13:56:38 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130108125637.GA2607@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" , Stewart Bryant References: <50EC0B27.2090409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EC0B27.2090409@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , Stewart Bryant Subject: Re: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:56:41 -0000 On Tue, Jan 08, 2013 at 01:03:51PM +0100, Benoit Claise wrote: > MIB doctors, > > http://www.rfc-editor.org/errata_search.php?eid=3292 > I would like to double-check that this errata should be verified. > Looks reasonable. It seems smilint does not detect this problem. I have to dig into the libsmi source code to see whether I can get it changed such that smilint flags this kind of error in the future. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue Jan 8 05:10:53 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1D21F85C3 for ; Tue, 8 Jan 2013 05:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 nU21WZGERT+7 for ; Tue, 8 Jan 2013 05:10:52 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 30DB221F84F2 for ; Tue, 8 Jan 2013 05:10:52 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08DAoro001808 for ; Tue, 8 Jan 2013 14:10:51 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08DAoT0018573; Tue, 8 Jan 2013 14:10:50 +0100 (CET) Message-ID: <50EC1ADA.80609@cisco.com> Date: Tue, 08 Jan 2013 14:10:50 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Stewart Bryant References: <50EC0B27.2090409@cisco.com> <20130108125637.GA2607@elstar.local> In-Reply-To: <20130108125637.GA2607@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 13:10:53 -0000 Thanks Juergen. Regards, Benoit > On Tue, Jan 08, 2013 at 01:03:51PM +0100, Benoit Claise wrote: >> MIB doctors, >> >> http://www.rfc-editor.org/errata_search.php?eid=3292 >> I would like to double-check that this errata should be verified. >> > Looks reasonable. > > It seems smilint does not detect this problem. I have to dig into the > libsmi source code to see whether I can get it changed such that > smilint flags this kind of error in the future. > > /js > From bwijnen@bwijnen.net Tue Jan 8 05:11:06 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705F521F8689 for ; Tue, 8 Jan 2013 05:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001] 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 7l2vlebdRE3F for ; Tue, 8 Jan 2013 05:11:05 -0800 (PST) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4155921F84F2 for ; Tue, 8 Jan 2013 05:11:05 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.80) (envelope-from ) id 1TsYxK-0008WK-7D; Tue, 08 Jan 2013 14:11:02 +0100 Message-ID: <020EC8A1B6964C4683786A4E5DF60A10@BertLaptop> From: "Bert Wijnen" To: "Juergen Schoenwaelder" , "Benoit Claise" References: <50EC0B27.2090409@cisco.com> <20130108125637.GA2607@elstar.local> In-Reply-To: <20130108125637.GA2607@elstar.local> Date: Tue, 8 Jan 2013 14:11:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: "MIB Doctors \(E-mail\)" , Stewart Bryant Subject: Re: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 13:11:06 -0000 SMICng strict checking DOES flag it as an error (beside many other warnings). For the error reported as an errata, see the bottom of this list. I am somehwat surprised. RFC-Editor (back in my days at least, which is before the december date of this RFC) is supposed to check MIB modules with SMICng checker. Bert C:\bw\smicng\rfcs>smicng rfc4750a.inc Successful parsing C:\bw\smicng\rfcs>smicng rfc4750b.inc W: f(rfc4750b.mi2), (162,14) Variable "ospfVirtIfAreaId" in notification "ospfVirtIfStateCh ange" is an index for a table W: f(rfc4750b.mi2), (163,14) Variable "ospfVirtIfNeighbor" in notification "ospfVirtIfState Change" is an index for a table W: f(rfc4750b.mi2), (180,14) Variable "ospfNbrIpAddr" in notification "ospfNbrStateChange" is an index for a table W: f(rfc4750b.mi2), (181,14) Variable "ospfNbrAddressLessIndex" in notification "ospfNbrSta teChange" is an index for a table W: f(rfc4750b.mi2), (204,14) Variable "ospfVirtNbrArea" in notification "ospfVirtNbrStateCh ange" is an index for a table W: f(rfc4750b.mi2), (205,14) Variable "ospfVirtNbrRtrId" in notification "ospfVirtNbrStateC hange" is an index for a table W: f(rfc4750b.mi2), (220,14) Variable "ospfIfIpAddress" in notification "ospfIfConfigError" is an index for a table W: f(rfc4750b.mi2), (221,14) Variable "ospfAddressLessIf" in notification "ospfIfConfigErro r" is an index for a table W: f(rfc4750b.mi2), (239,14) Variable "ospfVirtIfAreaId" in notification "ospfVirtIfConfigE rror" is an index for a table W: f(rfc4750b.mi2), (240,14) Variable "ospfVirtIfNeighbor" in notification "ospfVirtIfConfi gError" is an index for a table W: f(rfc4750b.mi2), (258,14) Variable "ospfIfIpAddress" in notification "ospfIfAuthFailure" is an index for a table W: f(rfc4750b.mi2), (259,14) Variable "ospfAddressLessIf" in notification "ospfIfAuthFailur e" is an index for a table W: f(rfc4750b.mi2), (277,14) Variable "ospfVirtIfAreaId" in notification "ospfVirtIfAuthFai lure" is an index for a table W: f(rfc4750b.mi2), (278,14) Variable "ospfVirtIfNeighbor" in notification "ospfVirtIfAuthF ailure" is an index for a table W: f(rfc4750b.mi2), (295,14) Variable "ospfIfIpAddress" in notification "ospfIfRxBadPacket" is an index for a table W: f(rfc4750b.mi2), (296,14) Variable "ospfAddressLessIf" in notification "ospfIfRxBadPacke t" is an index for a table W: f(rfc4750b.mi2), (309,13) Variable "ospfVirtIfAreaId" in notification "ospfVirtIfRxBadPa cket" is an index for a table W: f(rfc4750b.mi2), (310,13) Variable "ospfVirtIfNeighbor" in notification "ospfVirtIfRxBad Packet" is an index for a table W: f(rfc4750b.mi2), (322,14) Variable "ospfIfIpAddress" in notification "ospfTxRetransmit" is an index for a table W: f(rfc4750b.mi2), (323,14) Variable "ospfAddressLessIf" in notification "ospfTxRetransmit " is an index for a table W: f(rfc4750b.mi2), (326,14) Variable "ospfLsdbType" in notification "ospfTxRetransmit" is an index for a table W: f(rfc4750b.mi2), (327,14) Variable "ospfLsdbLsid" in notification "ospfTxRetransmit" is an index for a table W: f(rfc4750b.mi2), (328,14) Variable "ospfLsdbRouterId" in notification "ospfTxRetransmit" is an index for a table W: f(rfc4750b.mi2), (342,14) Variable "ospfVirtIfAreaId" in notification "ospfVirtIfTxRetra nsmit" is an index for a table W: f(rfc4750b.mi2), (343,14) Variable "ospfVirtIfNeighbor" in notification "ospfVirtIfTxRet ransmit" is an index for a table W: f(rfc4750b.mi2), (345,14) Variable "ospfLsdbType" in notification "ospfVirtIfTxRetransmi t" is an index for a table W: f(rfc4750b.mi2), (346,14) Variable "ospfLsdbLsid" in notification "ospfVirtIfTxRetransmi t" is an index for a table W: f(rfc4750b.mi2), (347,14) Variable "ospfLsdbRouterId" in notification "ospfVirtIfTxRetra nsmit" is an index for a table W: f(rfc4750b.mi2), (361,14) Variable "ospfLsdbAreaId" in notification "ospfOriginateLsa" i s an index for a table W: f(rfc4750b.mi2), (362,14) Variable "ospfLsdbType" in notification "ospfOriginateLsa" is an index for a table W: f(rfc4750b.mi2), (363,14) Variable "ospfLsdbLsid" in notification "ospfOriginateLsa" is an index for a table W: f(rfc4750b.mi2), (364,14) Variable "ospfLsdbRouterId" in notification "ospfOriginateLsa" is an index for a table W: f(rfc4750b.mi2), (381,14) Variable "ospfLsdbAreaId" in notification "ospfMaxAgeLsa" is a n index for a table W: f(rfc4750b.mi2), (382,14) Variable "ospfLsdbType" in notification "ospfMaxAgeLsa" is an index for a table W: f(rfc4750b.mi2), (383,14) Variable "ospfLsdbLsid" in notification "ospfMaxAgeLsa" is an index for a table W: f(rfc4750b.mi2), (384,14) Variable "ospfLsdbRouterId" in notification "ospfMaxAgeLsa" is an index for a table W: f(rfc4750b.mi2), (420,14) Variable "ospfIfIpAddress" in notification "ospfIfStateChange" is an index for a table W: f(rfc4750b.mi2), (421,14) Variable "ospfAddressLessIf" in notification "ospfIfStateChang e" is an index for a table W: f(rfc4750b.mi2), (438,14) Variable "ospfAreaId" in notification "ospfNssaTranslatorStatu sChange" is an index for a table W: f(rfc4750b.mi2), (469,21) Variable "ospfNbrIpAddr" in notification "ospfNbrRestartHelper StatusChange" is an index for a table W: f(rfc4750b.mi2), (470,21) Variable "ospfNbrAddressLessIndex" in notification "ospfNbrRes tartHelperStatusChange" is an index for a table W: f(rfc4750b.mi2), (488,21) Variable "ospfVirtNbrArea" in notification "ospfVirtNbrRestart HelperStatusChange" is an index for a table W: f(rfc4750b.mi2), (489,21) Variable "ospfVirtNbrRtrId" in notification "ospfVirtNbrRestar tHelperStatusChange" is an index for a table E: f(rfc4750b.mi2), (518,21) Group "ospfTrapControlGroup" is both a MANDATORY and condition al group for module "OSPF-TRAP-MIB" *** 1 error and 43 warnings in parsing Bert ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Benoit Claise" Cc: "MIB Doctors (E-mail)" ; "Stewart Bryant" Sent: Tuesday, January 08, 2013 1:56 PM Subject: Re: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 > On Tue, Jan 08, 2013 at 01:03:51PM +0100, Benoit Claise wrote: >> MIB doctors, >> >> http://www.rfc-editor.org/errata_search.php?eid=3292 >> I would like to double-check that this errata should be verified. >> > > Looks reasonable. > > It seems smilint does not detect this problem. I have to dig into the > libsmi source code to see whether I can get it changed such that > smilint flags this kind of error in the future. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Tue Jan 8 07:27:33 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468EB21F8525; Tue, 8 Jan 2013 07:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 zYkVs2MXOKaX; Tue, 8 Jan 2013 07:27:31 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 50E2E21F8514; Tue, 8 Jan 2013 07:27:31 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08FRH1I017584; Tue, 8 Jan 2013 16:27:17 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r08FR7SZ016033; Tue, 8 Jan 2013 16:27:13 +0100 (CET) Message-ID: <50EC3ACB.8050100@cisco.com> Date: Tue, 08 Jan 2013 16:27:07 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000709060407080702060802" Cc: "MIB Doctors \(E-mail\)" , ops-dir@ietf.org, Bert Wijnen , Lynne Bartholomew Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:27:33 -0000 This is a multi-part message in MIME format. --------------000709060407080702060802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, I understand your argument, and I tend to agree with you. The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references; Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. There are two things we can do 1. do nothing, because it's not worth it. 2. Correct the sentence OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed): SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. NEW: SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410])._W__hen implementing SNMPv3, full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._ Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. And we move the following references from informative to normative [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. [RFC5591] Harrington, D., and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", July 2011. I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a few documents in AUTH48 waiting on this) Feedback? Unless I hear otherwise, I will apply the changes in a week from now. Thanks Dan for helping on this issue. Regards, Benoit > Hi, > > The mib security boilerplate changed in December of 2011, following > discussion between the OPS and Security ADs and the MIB Doctors. > > IIRC, we always made implementation of SNMPv3 recommended but not required. > No MIB module (except those specifically related to managing SNMPv3) > should require SNMPv3 to work. > Any MIB theoretically should work with any version of SNMP (given known > interoperability issues of SNMPv1 vs SMIv2, etc.). > Theoretically (and according to IAB recommendations in RFC1052), the MIB > should also be able to work with protocols other than SNMP, since "The > MIB" is just a database that (theoretically) is independent of the > protocol used to access it. > So no MIB module (with exceptions) should REQUIRE a specific protocol or > protocol version to access it. > (yawn. I'm sure you guys are tired of hearing this from me ;-) > > We deliberately made RFC3410 Informational to avoid downrefs. > IIRC, you cannot implement RFC3410 because it doesn't define a protocol; > it's just a roadmap. > > SNMPv3 was designed as something of a framework that could be built from > multiple pieces - a messaging model, a security model, an ACM model, etc. > RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it > was definitely an SNMPv3 WG decision that this was AN architecture, not > THE architecture for SNMPv3, to allow for alternative approaches (such as > ISMS work on transport models) and to allow for implementation-specific > decisions that would not affect the on-the-wire protocol. > > The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would > make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which > RFCs actually make up SNMPv3, and are MUST implement). > But that seems to fly in the face of the SNMPv3 WG intention to NOT make a > certain set of RFCs **THE** SNMPv3 definition. > (Of course, the IESG approved an IETF Standard called SNMPv3, which > contained the RFC34xx series as a set of RFCs within the somewhat-abstract > SNMPv3 Standard, to ensure base interoperability.) > > I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs > MUST be implemented, and make those references normative. > I.e., what you would be doing is defining THE set of RFCs that define > SNMPv3. > > I personally think it best not to require a specific version of SNMP as > part of the boilerplate for a MIB module. > > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 1/2/13 7:52 AM, "Bert Wijnen" wrote: > >> RFC3410 is an informational document and has ALWAYS been >> listed as informational. >> So... if you make it Normative, you have a >> downref. >> The 3414 and 3826 might be listed as Normative. >> >> The otehr 3 are only listed as MAY implement. So would it then >> have to be normative? >> >> For me the most important thing is that the pointers to all >> this >> documents are listed, so you can quickly find >> them. >> >> Bert >> >> >> ----- Original Message ----- >> From: >> Benoit Claise >> >> To: ops-dir@ietf.org ; MIB Doctors >> (E-mail) >> Cc: adslmib-chairs@ietf.org ; Lynne >> Bartholomew ; Edward Beili >> ; Moti Morgenstern >> >> Sent: Wednesday, January 02, 2013 12:33 >> PM >> Subject: [MIB-DOCTORS] Security >> Guidelines for IETF MIB Modules: normative or informative references? >> >> Dear all, >> >> In the AUTH48 process for >> draft-ietf-adslmib-gbond-mib-11.txt >> (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi >> b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), >> we discussed with the RFC editor whether the following RFCs should be >> normative or informative: >> Implementations MUST provide the security features described by the >> SNMPv3 framework (see [RFC3410]), including full support for >> authentication and privacy via the User-based Security Model (USM) >> [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they >> should be normative, based on the justification at >> http://www.ietf.org/iesg/statement/normative-informative.html >> Normative references specify documents that must be read to >> understand or implement the technology in the new RFC, or whose >> technology >> must be present for the technology in the new RFC to work. >> >> The >> RFC editors answered: >> >> Thank you for the email. We see your point and agree that it >> makes sense that the references would be listed as normative, but we >> do not >> make calls on which documents are listed as informative vs normative. >> We note that >> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists >> the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, >> and 6353 -- as informative. Please request that the wiki >> be >> updated, if necessary. >> >> >> So normative or informative >> references? >> Shall I update the WIKI? >> >> Regards, Benoit >> >> >> >> >> >> ________________________________________ >> >> _______________________________________________ >> MIB-DOCTORS mailing >> list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> >> _______________________________________________ >> OPS-DIR mailing list >> OPS-DIR@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-dir > > --------------000709060407080702060802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Dave,

I understand your argument, and I tend to agree with you.

The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references;
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].

There are two things we can do

1. do nothing, because it's not worth it.

2. Correct the sentence

OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed):
   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.
NEW: 
   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED.
   Implementations MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.
And we move the following references from informative to normative
   [RFC3414] Blumenthal, U., and B. Wijnen, 
             "User-based Security Model (USM) for version 3 of the
             Simple Network Management Protocol (SNMPv3)", RFC 3414,
             December 2002.

   [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie,
             "The Advanced Encryption Standard (AES) Cipher 
             Algorithm in the SNMP User-based Security Model",
             RFC 3826, June 2004.
   [RFC5591] Harrington, D., and W. Hardaker,
             "Transport Security Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.

   [RFC5592] Harrington, D., Saloway, J., and W. Hardaker,
             "Secure Shell Transport Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.

   [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport 
             Model for the Simple Network Management Protocol (SNMP)",
             July 2011.

I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a few documents in AUTH48 waiting on this)

Feedback?
Unless I hear otherwise, I will apply the changes in a week from now.

Thanks Dan for helping on this issue.

Regards, Benoit


Hi,

The mib security boilerplate changed in December of 2011, following
discussion between the OPS and Security ADs and the MIB Doctors.

IIRC, we always made implementation of SNMPv3 recommended but not required.
No MIB module (except those specifically related to managing SNMPv3)
should require SNMPv3 to work.
Any MIB theoretically should work with any version of SNMP (given known
interoperability issues of SNMPv1 vs SMIv2, etc.).
Theoretically (and according to IAB recommendations in RFC1052), the MIB
should also be able to work with protocols other than SNMP, since "The
MIB" is just a database that (theoretically) is independent of the
protocol used to access it.
So no MIB module (with exceptions) should REQUIRE a specific protocol or
protocol version to access it.
(yawn. I'm sure you guys are tired of hearing this from me ;-)

We deliberately made RFC3410 Informational to avoid downrefs.
IIRC, you cannot implement RFC3410 because it doesn't define a protocol;
it's just a roadmap.

SNMPv3 was designed as something of a framework that could be built from
multiple pieces - a messaging model, a security model, an ACM model, etc.
RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it
was definitely an SNMPv3 WG decision that this was AN architecture, not
THE architecture for SNMPv3, to allow for alternative approaches (such as
ISMS work on transport models) and to allow for implementation-specific
decisions that would not affect the on-the-wire protocol.

The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would
make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which
RFCs actually make up SNMPv3, and are MUST implement).
But that seems to fly in the face of the SNMPv3 WG intention to NOT make a
certain set of RFCs **THE** SNMPv3 definition.
(Of course, the IESG approved an IETF Standard called SNMPv3, which
contained the RFC34xx series as a set of RFCs within the somewhat-abstract
SNMPv3 Standard, to ensure base interoperability.)

I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs
MUST be implemented, and make those references normative.
I.e., what you would be doing is defining THE set of RFCs that define
SNMPv3.

I personally think it best not to require a specific version of SNMP as
part of the boilerplate for a MIB module.


--
David Harrington
Ietfdbh@comcast.net
+1-603-828-1401





On 1/2/13 7:52 AM, "Bert Wijnen" <bwijnen@bwijnen.net> wrote:


RFC3410 is an informational document and has ALWAYS been
listed as informational.
So... if you make it Normative, you have a
downref.
The 3414 and 3826 might be listed as Normative.

The otehr 3 are only listed as MAY implement. So would it then
have to be normative?

For me the most important thing is that the pointers to all
this
documents are listed, so you can quickly find
them.

Bert


 ----- Original Message -----
 From: 
 Benoit Claise <mailto:bclaise@cisco.com>
 
 To: ops-dir@ietf.org ; MIB Doctors
 (E-mail) <mailto:mib-doctors@ietf.org>
 Cc: adslmib-chairs@ietf.org ; Lynne
 Bartholomew <mailto:lbartholomew@amsl.com> ; Edward Beili
<mailto:EdwardB@actelis.com> ; Moti Morgenstern
<mailto:Moti.Morgenstern@ecitele.com>
 Sent: Wednesday, January 02, 2013 12:33
 PM
 Subject: [MIB-DOCTORS] Security
 Guidelines for IETF MIB Modules: normative or informative references?
 
Dear all,

In the AUTH48 process for
 draft-ietf-adslmib-gbond-mib-11.txt
(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi
b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=),
 we discussed with the RFC editor whether the following RFCs should be
 normative or informative:
  Implementations MUST provide the security features described by the
  SNMPv3 framework (see [RFC3410]), including full support for
  authentication and privacy via the User-based Security Model (USM)
  [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they
 should be normative, based on the justification at
http://www.ietf.org/iesg/statement/normative-informative.html
 Normative references specify documents that must be read to
   understand or implement the technology in the new RFC, or whose
technology 
   must be present for the technology in the new RFC to work.

The 
 RFC editors answered:
 
   Thank you for the email.  We see your point and agree that it
   makes sense that the references would be listed as normative, but we
do not 
   make calls on which documents are listed as informative vs normative.
    We note that 
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists
   the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592,
and 6353 -- as informative. Please request that the wiki
   be
updated, if necessary.


So normative or informative
 references?
Shall I update the WIKI?

Regards, Benoit



 
 
________________________________________

 _______________________________________________
MIB-DOCTORS mailing
 list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors


_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

--------------000709060407080702060802-- From j.schoenwaelder@jacobs-university.de Tue Jan 8 10:12:31 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D551F0CB3 for ; Tue, 8 Jan 2013 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Wmt8CmwNZ6sc for ; Tue, 8 Jan 2013 10:12:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BE1DD1F0CF5 for ; Tue, 8 Jan 2013 10:12:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E48520BE6; Tue, 8 Jan 2013 19:12:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t2ChrBxmVDx9; Tue, 8 Jan 2013 19:12:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 775F520BDD; Tue, 8 Jan 2013 19:12:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1579A23D68DC; Tue, 8 Jan 2013 19:12:26 +0100 (CET) Date: Tue, 8 Jan 2013 19:12:26 +0100 From: Juergen Schoenwaelder To: Benoit Claise , "MIB Doctors (E-mail)" , Stewart Bryant Message-ID: <20130108181226.GA42474@elstar.local> Mail-Followup-To: Benoit Claise , "MIB Doctors (E-mail)" , Stewart Bryant References: <50EC0B27.2090409@cisco.com> <20130108125637.GA2607@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130108125637.GA2607@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [MIB-DOCTORS] GROUP versus MANDATORY-GROUPS in errata 3292 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:12:31 -0000 On Tue, Jan 08, 2013 at 01:56:38PM +0100, Juergen Schoenwaelder wrote: > It seems smilint does not detect this problem. I have to dig into the > libsmi source code to see whether I can get it changed such that > smilint flags this kind of error in the future. I managed to convince smilint to catch this: OSPF-TRAP-MIB:539: group 'ospfTrapControlGroup' is both mandatory and optional in `ospfTrapCompliance' We have similar issues in the RDBMS-MIB [RFC 1697] and the RIPv2-MIB [RFC1724]. I am not sure it is worth doing something about this. All the other IETF MIB modules seem to be fine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Jan 8 13:11:34 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5F221F853E for ; Tue, 8 Jan 2013 13:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 XE8djUEul+XH for ; Tue, 8 Jan 2013 13:11:27 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id D822221F8578 for ; Tue, 8 Jan 2013 13:11:26 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id lYbQ1k0051swQuc5FZBSu6; Tue, 08 Jan 2013 21:11:26 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta15.westchester.pa.mail.comcast.net with comcast id lZBR1k00C3Ecudz3bZBRE2; Tue, 08 Jan 2013 21:11:26 +0000 From: "ietfdbh" To: "'Benoit Claise'" References: <50EC3ACB.8050100@cisco.com> In-Reply-To: <50EC3ACB.8050100@cisco.com> Date: Tue, 8 Jan 2013 16:11:28 -0500 Message-ID: <025001cdede4$ba097200$2e1c5600$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0251_01CDEDBA.D1395D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIeLITTx1XEqfqNbiNJBt0MVL/V2wKcwQ55l4pQHdA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357679486; bh=rLJfuoWEelOcspnqK9CBFIAfxJYLhHEiw1heAXWJch8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ZXuI9V88BgaMlgCr4XC6LY+UJlB+04aImMmYY07gJT8hYYDPa5SH8dwU16gKknaZY QtY/Z5qErB+OQs/uUXv++JYDWBpSGMdKK/TbiZ7487oA6loiS78TRgwNMgiZbB0m1h N9wGWUQz6TBVcplAvmnkDckYTnCWsmQ9MfdzA5fmrMDnJbYWVAVo9VLQRkVH6Qa5/h KgtgaXG3s/v2dVp5Frm7jy/lWWXCc814P7l55lrJbd2mBwzPY+chizipP+9vLKQ79V uPpGnhUOrCdr21pABXHDD/mJwSD2N5rVYS3MNpUWwnZ2EDTAZQdF2Oy+zbuScVOLlf j/tq377vy+Pnw== Cc: "'MIB Doctors \(E-mail\)'" , ops-dir@ietf.org, 'Bert Wijnen' Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 21:11:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0251_01CDEDBA.D1395D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Benoit, Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be broken by using SNMPv1 or SNMPv2. And, a MIB module typically will not be broken by the use of SNMPv3 with a security model other than USM with AES. And, a MIB module will not be broken by using a protocol other than SNMP. Hence, I think that MUST is being used inappropriately when the boilerplate says SNMPv3 MUST be supported for a particular MIB module. I think what we really want to say is that we RECOMMEND SNMPv3 - for purposes of security - with USM/AES for purposes of interoperability. I recommend the text read: Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB. If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well? As one of the developers of SNMPv3, I certainly would like to see it implemented, but I think this boilerplate is being heavy handed by saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported. The original MIB boilerplate combination said SNMP was typically used for carrying MIB data, and version 3 of SNMP was RECOMMENDED because of its security properties. That makes sense to me. The MUST does not. That said, I am fine with the current boilerplate if that's what the IESG wants; I just think it's not very accurate. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, January 08, 2013 10:27 AM To: David Harrington Cc: Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne Bartholomew Subject: Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? Hi Dave, I understand your argument, and I tend to agree with you. The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references; Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. There are two things we can do 1. do nothing, because it's not worth it. 2. Correct the sentence OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed): SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. NEW: SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. And we move the following references from informative to normative [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. [RFC5591] Harrington, D., and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", July 2011. I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a few documents in AUTH48 waiting on this) Feedback? Unless I hear otherwise, I will apply the changes in a week from now. Thanks Dan for helping on this issue. Regards, Benoit Hi, The mib security boilerplate changed in December of 2011, following discussion between the OPS and Security ADs and the MIB Doctors. IIRC, we always made implementation of SNMPv3 recommended but not required. No MIB module (except those specifically related to managing SNMPv3) should require SNMPv3 to work. Any MIB theoretically should work with any version of SNMP (given known interoperability issues of SNMPv1 vs SMIv2, etc.). Theoretically (and according to IAB recommendations in RFC1052), the MIB should also be able to work with protocols other than SNMP, since "The MIB" is just a database that (theoretically) is independent of the protocol used to access it. So no MIB module (with exceptions) should REQUIRE a specific protocol or protocol version to access it. (yawn. I'm sure you guys are tired of hearing this from me ;-) We deliberately made RFC3410 Informational to avoid downrefs. IIRC, you cannot implement RFC3410 because it doesn't define a protocol; it's just a roadmap. SNMPv3 was designed as something of a framework that could be built from multiple pieces - a messaging model, a security model, an ACM model, etc. RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it was definitely an SNMPv3 WG decision that this was AN architecture, not THE architecture for SNMPv3, to allow for alternative approaches (such as ISMS work on transport models) and to allow for implementation-specific decisions that would not affect the on-the-wire protocol. The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which RFCs actually make up SNMPv3, and are MUST implement). But that seems to fly in the face of the SNMPv3 WG intention to NOT make a certain set of RFCs **THE** SNMPv3 definition. (Of course, the IESG approved an IETF Standard called SNMPv3, which contained the RFC34xx series as a set of RFCs within the somewhat-abstract SNMPv3 Standard, to ensure base interoperability.) I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs MUST be implemented, and make those references normative. I.e., what you would be doing is defining THE set of RFCs that define SNMPv3. I personally think it best not to require a specific version of SNMP as part of the boilerplate for a MIB module. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 1/2/13 7:52 AM, "Bert Wijnen" wrote: RFC3410 is an informational document and has ALWAYS been listed as informational. So... if you make it Normative, you have a downref. The 3414 and 3826 might be listed as Normative. The otehr 3 are only listed as MAY implement. So would it then have to be normative? For me the most important thing is that the pointers to all this documents are listed, so you can quickly find them. Bert ----- Original Message ----- From: Benoit Claise To: ops-dir@ietf.org ; MIB Doctors (E-mail) Cc: adslmib-chairs@ietf.org ; Lynne Bartholomew ; Edward Beili ; Moti Morgenstern Sent: Wednesday, January 02, 2013 12:33 PM Subject: [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? Dear all, In the AUTH48 process for draft-ietf-adslmib-gbond-mib-11.txt (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), we discussed with the RFC editor whether the following RFCs should be normative or informative: Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they should be normative, based on the justification at http://www.ietf.org/iesg/statement/normative-informative.html Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. The RFC editors answered: Thank you for the email. We see your point and agree that it makes sense that the references would be listed as normative, but we do not make calls on which documents are listed as informative vs normative. We note that https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, and 6353 -- as informative. Please request that the wiki be updated, if necessary. So normative or informative references? Shall I update the WIKI? Regards, Benoit ________________________________________ _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir ------=_NextPart_000_0251_01CDEDBA.D1395D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 

Unless it is an SNMPv3-specific MIB module, a MIB module will usually = not be broken by using SNMPv1 or SNMPv2.

And, a MIB module typically will not be broken by the use of SNMPv3 = with a security model other than USM with AES.

And, a MIB module will not be broken by using a protocol other than = SNMP.

 

Hence, I think that MUST is being used inappropriately when the = boilerplate says SNMPv3 MUST be supported for a particular MIB = module.

 

I think what we really want to say is that we RECOMMEND SNMPv3 = – for purposes of security – with USM/AES for purposes of = interoperability.

I recommend the text read:

   =
Implementations SHOULD provide the security features described by =
the
   SNMPv3 framework (see [RFC3410]), =
and implementations claiming compliance to the SNMPv3 standard =
MUST include full support for
   =
authentication and privacy via the User-based Security Model =
(USM)
   [RFC3414] with the AES cipher =
algorithm [RFC3826].
 
Of =
course, it can be debated whether every MIB module document should =
include compliance requirements for ONE of the protocols that COULD be =
used to access the MIB.
If we are going to add =
SNMPv3-compliance requirements to every MIB document, and syslog and =
netconf and ipfix and others can also be used to carry the data =
described in the MIB module, should we include compliance requirements =
for specific versions of the syslog protocol, the netconf protocol, the =
ipfix protocol, and so on in the MIB boilerplate as =
well?
 

As one of the developers of SNMPv3, I certainly would like to see it = implemented, but I think this boilerplate is being heavy handed by = saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be = supported.

The original MIB boilerplate combination said SNMP was typically used = for carrying MIB data, and version 3 of SNMP was RECOMMENDED because of = its security properties. That makes sense to me. The MUST does = not.

 

That said, I am fine with the current boilerplate if that’s = what the IESG wants; I just think it’s not very = accurate.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, = January 08, 2013 10:27 AM
To: David Harrington
Cc: = Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne = Bartholomew
Subject: Re: [OPS-DIR] [MIB-DOCTORS] Security = Guidelines for IETF MIB Modules: normative or informative = references?

 

Hi = Dave,

I understand your argument, and I tend to agree with = you.

The problem statement is: the following sentence is kind of = broken , because RFC 3414 and RFC 3826 are informative = references;

   Implementations MUST provide =
the security features described by the
   =
SNMPv3 framework (see [RFC3410]), including full support =
for
   authentication and privacy via the =
User-based Security Model (USM)
   =
[RFC3414] with the AES cipher algorithm [RFC3826].


There are two things we can do

1. do = nothing, because it's not worth it.

2. Correct the sentence =

OLD (the 3 paragraphs are copied for completeness, while only = the second and third one are changed):

   =
SNMP versions prior to SNMPv3 did not include adequate =
security.
   Even if the network itself =
is secure (for example by using =
IPsec),
   there is no control as to who =
on the secure network is
   allowed to =
access and GET/SET (read/change/create/delete) the =
objects
   in this MIB =
module.
 
   =
Implementations MUST provide the security features described by =
the
   SNMPv3 framework (see [RFC3410]), =
including full support for
   =
authentication and privacy via the User-based Security Model =
(USM)
   [RFC3414] with the AES cipher =
algorithm [RFC3826].  =
Implementations
   MAY also provide =
support for the Transport Security Model =
(TSM)
   [RFC5591] in combination with a =
secure transport such as SSH
   [RFC5592] =
or TLS/DTLS =
[RFC6353].
 
   =
Further, deployment of SNMP versions prior to SNMPv3 is =
NOT
   RECOMMENDED.  Instead, it is =
RECOMMENDED to deploy SNMPv3 and to
   =
enable cryptographic security.  It is then a =
customer/operator
   responsibility to =
ensure that the SNMP entity giving access to =
an
   instance of this MIB module is =
properly configured to give access to
   =
the objects only to those principals (users) that have =
legitimate
   rights to indeed GET or SET =
(change/create/delete) them.

NEW: = 

   SNMP versions prior to SNMPv3 did =
not include adequate security.
   Even if =
the network itself is secure (for example by using =
IPsec),
   there is no control as to who =
on the secure network is
   allowed to =
access and GET/SET (read/change/create/delete) the =
objects
   in this MIB =
module.
   Implementations MUST provide =
the security features described by the
   =
SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full =
support for
   authentication and =
privacy via the User-based Security Model =
(USM)
   [RFC3414] with the AES =
cipher algorithm [RFC3826] is =
RECOMMENDED.
   Implementations MAY =
also provide support for the Transport Security Model =
(TSM)
   [RFC5591] in combination with a =
secure transport such as SSH
   [RFC5592] =
or TLS/DTLS [RFC6353].
   Further, =
deployment of SNMP versions prior to SNMPv3 is =
NOT
   RECOMMENDED.  Instead, it is =
RECOMMENDED to deploy SNMPv3 and to
   =
enable cryptographic security.  It is then a =
customer/operator
   responsibility to =
ensure that the SNMP entity giving access to =
an
   instance of this MIB module is =
properly configured to give access to
   =
the objects only to those principals (users) that have =
legitimate
   rights to indeed GET or SET =
(change/create/delete) them.

And we = move the following references from informative to = normative

   [RFC3414] Blumenthal, U., and =
B. Wijnen, =

        &nb=
sp;    "User-based Security Model (USM) for =
version 3 of =
the
        =
     Simple Network Management Protocol =
(SNMPv3)", RFC =
3414,
       =
      December =
2002.
 
   =
[RFC3826] Blumenthal, U., Maino, F., and K. =
McCloghrie,
      &nbs=
p;      "The Advanced Encryption Standard =
(AES) Cipher =

        &nb=
sp;    Algorithm in the SNMP User-based Security =
Model",
      &nb=
sp;      RFC 3826, June =
2004.
   [RFC5591] Harrington, D., and W. =
Hardaker,
       =
      "Transport Security Model for the =
Simple Network =

        &nb=
sp;    Management Protocol (SNMP)", June =
2009.
 
   =
[RFC5592] Harrington, D., Saloway, J., and W. =
Hardaker,
       =
      "Secure Shell Transport Model for =
the Simple Network =

        &nb=
sp;    Management Protocol (SNMP)", June =
2009.
 
   =
[RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport =

        &nb=
sp;    Model for the Simple Network Management =
Protocol =
(SNMP)",
      &n=
bsp;      July 2011.


I want to go for = solution 2. If we redo the full discussion, and the discussion goes = nowhere, I'll go for solution 1 (I have a few documents in AUTH48 = waiting on this)

Feedback?
Unless I hear otherwise, I will = apply the changes in a week from now.

Thanks Dan for helping on = this issue.

Regards, = Benoit

Hi,
<= pre> 
The mib security boilerplate changed in =
December of 2011, following
discussion between the =
OPS and Security ADs and the MIB =
Doctors.
 
IIRC, we =
always made implementation of SNMPv3 recommended but not =
required.
No MIB module (except those specifically =
related to managing SNMPv3)
should require SNMPv3 =
to work.
Any MIB theoretically should work with any =
version of SNMP (given known
interoperability =
issues of SNMPv1 vs SMIv2, etc.).
Theoretically =
(and according to IAB recommendations in RFC1052), the =
MIB
should also be able to work with protocols =
other than SNMP, since "The
MIB" is just =
a database that (theoretically) is independent of =
the
protocol used to access =
it.
So no MIB module (with exceptions) should =
REQUIRE a specific protocol or
protocol version to =
access it.
(yawn. I'm sure you guys are tired of =
hearing this from me =
;-)
 
We deliberately =
made RFC3410 Informational to avoid downrefs.
IIRC, =
you cannot implement RFC3410 because it doesn't define a =
protocol;
it's just a =
roadmap.
 
SNMPv3 was =
designed as something of a framework that could be built =
from
multiple pieces - a messaging model, a =
security model, an ACM model, etc.
RFC3411 =
***describes*** an architecture suitable for SNMPv3 usage, but =
it
was definitely an SNMPv3 WG decision that this =
was AN architecture, not
THE architecture for =
SNMPv3, to allow for alternative approaches (such =
as
ISMS work on transport models) and to allow for =
implementation-specific
decisions that would not =
affect the on-the-wire =
protocol.
 
The 12/2011 =
security boilerplate makes SNMPv3 support a MUST, which =
would
make the defining SNMPv3 RFCs Normative =
(otherwise it is ambiguous which
RFCs actually make =
up SNMPv3, and are MUST implement).
But that seems =
to fly in the face of the SNMPv3 WG intention to NOT make =
a
certain set of RFCs **THE** SNMPv3 =
definition.
(Of course, the IESG approved an IETF =
Standard called SNMPv3, which
contained the RFC34xx =
series as a set of RFCs within the =
somewhat-abstract
SNMPv3 Standard, to ensure base =
interoperability.)
 
I =
think if SNMPv3 is a MUST, the boilerplate should spell out which =
RFCs
MUST be implemented, and make those references =
normative.
I.e., what you would be doing is =
defining THE set of RFCs that =
define
SNMPv3.
 
I personally think it best not to require a specific version =
of SNMP as
part of the boilerplate for a MIB =
module.
 
 
--
David =
Harrington
Ietfdbh@comcast.net
+1-603-828-1401
 
=
 
 
 =

 
On 1/2/13 7:52 AM, "Bert =
Wijnen" <bwijnen@bwijnen.net> =
wrote:
 
RFC3410 is an =
informational document and has ALWAYS been
listed =
as informational.
So... if you make it Normative, =
you have a
downref.
The 3414 =
and 3826 might be listed as =
Normative.
 
The otehr 3 =
are only listed as MAY implement. So would it =
then
have to be =
normative?
 
For me the =
most important thing is that the pointers to =
all
this
documents are listed, =
so you can quickly =
find
them.
 
Bert
 
 =

 ----- Original Message -----
 =
From: 
 Benoit Claise <mailto:bclaise@cisco.com>
 
 To: ops-dir@ietf.org ; MIB =
Doctors
 (E-mail) <mailto:mib-doctors@ietf.org><=
/a>
 Cc: adslmib-chairs@ietf.org ; =
Lynne
 Bartholomew <mailto:lbartholomew@amsl.com>=
; ; Edward Beili
<mailto:EdwardB@actelis.com> ; Moti Morgenstern
<mailto:Moti.Morgenstern@=
ecitele.com>
 Sent: Wednesday, January 02, =
2013 12:33
 PM
 Subject: =
[MIB-DOCTORS] Security
 Guidelines for IETF MIB =
Modules: normative or informative references?
 =

Dear =
all,
 
In the AUTH48 =
process for
 =
draft-ietf-adslmib-gbond-mib-11.txt
(https://datatracker.ietf.org/doc/search/?name=3Ddraft-ietf-ad=
slmib-gbond-mi
b&rfcs=3Don&activeDrafts=3D=
on&author=3D&group=3D&area=3D&ad=3D&state=3D&subS=
tate=3D),
 we discussed with the RFC editor whether =
the following RFCs should be
 normative or =
informative:
  Implementations MUST provide =
the security features described by the
  =
SNMPv3 framework (see [RFC3410]), including full support =
for
  authentication and privacy via the =
User-based Security Model (USM)
  [RFC3414] =
with the AES cipher algorithm [RFC3826].I thought that =
they
 should be normative, based on the =
justification at
ht=
tp://www.ietf.org/iesg/statement/normative-informative.html
 Normative references specify documents that must be read =
to
   understand or implement the =
technology in the new RFC, or whose
technology =

   must be present for the =
technology in the new RFC to =
work.
 
The =

 RFC editors answered:
 =

   Thank you for the email.  =
We see your point and agree that it
   =
makes sense that the references would be listed as normative, but =
we
do not =

   make calls on which documents =
are listed as informative vs =
normative.
    We note that =

https=
://svn.tools.ietf.org/area/ops/trac/wiki/mib-security =
lists
   the six references in question =
-- RFCs 3410, 3414, 3826, 5591, 5592,
and 6353 -- =
as informative. Please request that the =
wiki
   be
updated, =
if =
necessary.
 
 
So normative or informative
 =
references?
Shall I update the =
WIKI?
 
Regards, =
Benoit
 
 =

 
 =

 
_______________________=
_________________
 
 =
_______________________________________________
MIB-=
DOCTORS mailing
 list
MIB-DOCTORS@ietf.org<=
/pre>
https://www.ie=
tf.org/mailman/listinfo/mib-doctors
 <=
/o:p>
 
_____________________________=
__________________
OPS-DIR mailing =
list
OPS-DIR@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/ops-dir
&n=
bsp;
 
 
<=
/blockquote>
 
------=_NextPart_000_0251_01CDEDBA.D1395D70-- From bclaise@cisco.com Wed Jan 9 05:52:29 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E93621F8480; Wed, 9 Jan 2013 05:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.412 X-Spam-Level: X-Spam-Status: No, score=-10.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Bjheyo89-kkx; Wed, 9 Jan 2013 05:52:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD0821F858A; Wed, 9 Jan 2013 05:52:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r09DoSDW025364; Wed, 9 Jan 2013 14:50:28 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r09DoRrH006414; Wed, 9 Jan 2013 14:50:27 +0100 (CET) Message-ID: <50ED75A3.30605@cisco.com> Date: Wed, 09 Jan 2013 14:50:27 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ietfdbh References: <50EC3ACB.8050100@cisco.com> <025001cdede4$ba097200$2e1c5600$@comcast.net> In-Reply-To: <025001cdede4$ba097200$2e1c5600$@comcast.net> Content-Type: multipart/alternative; boundary="------------000002010000050100020601" Cc: "'MIB Doctors \(E-mail\)'" , ops-dir@ietf.org, 'Bert Wijnen' Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:52:29 -0000 This is a multi-part message in MIME format. --------------000002010000050100020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, > > Hi Benoit, > > Unless it is an SNMPv3-specific MIB module, a MIB module will usually > not be broken by using SNMPv1 or SNMPv2. > > And, a MIB module typically will not be broken by the use of SNMPv3 > with a security model other than USM with AES. > > And, a MIB module will not be broken by using a protocol other than SNMP. > > Hence, I think that MUST is being used inappropriately when the > boilerplate says SNMPv3 MUST be supported for a particular MIB module. > > I think what we really want to say is that we RECOMMEND SNMPv3 -- for > purposes of security -- with USM/AES for purposes of interoperability. > > I recommend the text read: > > Implementations_SHOULD_ provide the security features described by the > SNMPv3 framework (see [RFC3410]),_and implementations claiming compliance to the SNMPv3 standard_ MUST include full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. That would be in the spirit of your proposition. Fine with me. Regards, Benoit > > Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB. > If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well? > > > As one of the developers of SNMPv3, I certainly would like to see it > implemented, but I think this boilerplate is being heavy handed by > saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST > be supported. > > The original MIB boilerplate combination said SNMP was typically used > for carrying MIB data, and version 3 of SNMP was RECOMMENDED because > of its security properties. That makes sense to me. The MUST does not. > > That said, I am fine with the current boilerplate if that's what the > IESG wants; I just think it's not very accurate. > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Tuesday, January 08, 2013 10:27 AM > *To:* David Harrington > *Cc:* Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne > Bartholomew > *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF > MIB Modules: normative or informative references? > > Hi Dave, > > I understand your argument, and I tend to agree with you. > > The problem statement is: the following sentence is kind of broken , > because RFC 3414 and RFC 3826 are informative references; > > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. > > > There are two things we can do > > 1. do nothing, because it's not worth it. > > 2. Correct the sentence > > OLD (the 3 paragraphs are copied for completeness, while only the > second and third one are changed): > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module. > > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations > MAY also provide support for the Transport Security Model (TSM) > [RFC5591] in combination with a secure transport such as SSH > [RFC5592] or TLS/DTLS [RFC6353]. > > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module is properly configured to give access to > the objects only to those principals (users) that have legitimate > rights to indeed GET or SET (change/create/delete) them. > > NEW: > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module. > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410])._When implementing SNMPv3, full support for_ > _ authentication and privacy via the User-based Security Model (USM)_ > _ [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._ > Implementations MAY also provide support for the Transport Security Model (TSM) > [RFC5591] in combination with a secure transport such as SSH > [RFC5592] or TLS/DTLS [RFC6353]. > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module is properly configured to give access to > the objects only to those principals (users) that have legitimate > rights to indeed GET or SET (change/create/delete) them. > > And we move the following references from informative to normative > > [RFC3414] Blumenthal, U., and B. Wijnen, > "User-based Security Model (USM) for version 3 of the > Simple Network Management Protocol (SNMPv3)", RFC 3414, > December 2002. > > [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, > "The Advanced Encryption Standard (AES) Cipher > Algorithm in the SNMP User-based Security Model", > RFC 3826, June 2004. > [RFC5591] Harrington, D., and W. Hardaker, > "Transport Security Model for the Simple Network > Management Protocol (SNMP)", June 2009. > > [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, > "Secure Shell Transport Model for the Simple Network > Management Protocol (SNMP)", June 2009. > > [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport > Model for the Simple Network Management Protocol (SNMP)", > July 2011. > > > I want to go for solution 2. If we redo the full discussion, and the > discussion goes nowhere, I'll go for solution 1 (I have a few > documents in AUTH48 waiting on this) > > Feedback? > Unless I hear otherwise, I will apply the changes in a week from now. > > Thanks Dan for helping on this issue. > > Regards, Benoit > > Hi, > > > > The mib security boilerplate changed in December of 2011, following > > discussion between the OPS and Security ADs and the MIB Doctors. > > > > IIRC, we always made implementation of SNMPv3 recommended but not required. > > No MIB module (except those specifically related to managing SNMPv3) > > should require SNMPv3 to work. > > Any MIB theoretically should work with any version of SNMP (given known > > interoperability issues of SNMPv1 vs SMIv2, etc.). > > Theoretically (and according to IAB recommendations in RFC1052), the MIB > > should also be able to work with protocols other than SNMP, since "The > > MIB" is just a database that (theoretically) is independent of the > > protocol used to access it. > > So no MIB module (with exceptions) should REQUIRE a specific protocol or > > protocol version to access it. > > (yawn. I'm sure you guys are tired of hearing this from me ;-) > > > > We deliberately made RFC3410 Informational to avoid downrefs. > > IIRC, you cannot implement RFC3410 because it doesn't define a protocol; > > it's just a roadmap. > > > > SNMPv3 was designed as something of a framework that could be built from > > multiple pieces - a messaging model, a security model, an ACM model, etc. > > RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it > > was definitely an SNMPv3 WG decision that this was AN architecture, not > > THE architecture for SNMPv3, to allow for alternative approaches (such as > > ISMS work on transport models) and to allow for implementation-specific > > decisions that would not affect the on-the-wire protocol. > > > > The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would > > make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which > > RFCs actually make up SNMPv3, and are MUST implement). > > But that seems to fly in the face of the SNMPv3 WG intention to NOT make a > > certain set of RFCs **THE** SNMPv3 definition. > > (Of course, the IESG approved an IETF Standard called SNMPv3, which > > contained the RFC34xx series as a set of RFCs within the somewhat-abstract > > SNMPv3 Standard, to ensure base interoperability.) > > > > I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs > > MUST be implemented, and make those references normative. > > I.e., what you would be doing is defining THE set of RFCs that define > > SNMPv3. > > > > I personally think it best not to require a specific version of SNMP as > > part of the boilerplate for a MIB module. > > > > > > -- > > David Harrington > > Ietfdbh@comcast.net > > +1-603-828-1401 > > > > > > > > > > > > On 1/2/13 7:52 AM, "Bert Wijnen" wrote: > > > > RFC3410 is an informational document and has ALWAYS been > > listed as informational. > > So... if you make it Normative, you have a > > downref. > > The 3414 and 3826 might be listed as Normative. > > > > The otehr 3 are only listed as MAY implement. So would it then > > have to be normative? > > > > For me the most important thing is that the pointers to all > > this > > documents are listed, so you can quickly find > > them. > > > > Bert > > > > > > ----- Original Message ----- > > From: > > Benoit Claise > > > > To:ops-dir@ietf.org ; MIB Doctors > > (E-mail) > > Cc:adslmib-chairs@ietf.org ; Lynne > > Bartholomew ; Edward Beili > > ; Moti Morgenstern > > > > Sent: Wednesday, January 02, 2013 12:33 > > PM > > Subject: [MIB-DOCTORS] Security > > Guidelines for IETF MIB Modules: normative or informative references? > > > > Dear all, > > > > In the AUTH48 process for > > draft-ietf-adslmib-gbond-mib-11.txt > > (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi > > b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), > > we discussed with the RFC editor whether the following RFCs should be > > normative or informative: > > Implementations MUST provide the security features described by the > > SNMPv3 framework (see [RFC3410]), including full support for > > authentication and privacy via the User-based Security Model (USM) > > [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they > > should be normative, based on the justification at > > http://www.ietf.org/iesg/statement/normative-informative.html > > Normative references specify documents that must be read to > > understand or implement the technology in the new RFC, or whose > > technology > > must be present for the technology in the new RFC to work. > > > > The > > RFC editors answered: > > > > Thank you for the email. We see your point and agree that it > > makes sense that the references would be listed as normative, but we > > do not > > make calls on which documents are listed as informative vs normative. > > We note that > > https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists > > the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, > > and 6353 -- as informative. Please request that the wiki > > be > > updated, if necessary. > > > > > > So normative or informative > > references? > > Shall I update the WIKI? > > > > Regards, Benoit > > > > > > > > > > > > ________________________________________ > > > > _______________________________________________ > > MIB-DOCTORS mailing > > list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > > > > > > > --------------000002010000050100020601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi David,

Hi Benoit,

 

Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be broken by using SNMPv1 or SNMPv2.

And, a MIB module typically will not be broken by the use of SNMPv3 with a security model other than USM with AES.

And, a MIB module will not be broken by using a protocol other than SNMP.

 

Hence, I think that MUST is being used inappropriately when the boilerplate says SNMPv3 MUST be supported for a particular MIB module.

 

I think what we really want to say is that we RECOMMEND SNMPv3 – for purposes of security – with USM/AES for purposes of interoperability.

I recommend the text read:

   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].
That would be in the spirit of your proposition. Fine with me.

Regards, Benoit
 
Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB.
If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well?
 

As one of the developers of SNMPv3, I certainly would like to see it implemented, but I think this boilerplate is being heavy handed by saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported.

The original MIB boilerplate combination said SNMP was typically used for carrying MIB data, and version 3 of SNMP was RECOMMENDED because of its security properties. That makes sense to me. The MUST does not.

 

That said, I am fine with the current boilerplate if that’s what the IESG wants; I just think it’s not very accurate.

 

David Harrington

ietfdbh@comcast.net

+1-603-828-1401

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 08, 2013 10:27 AM
To: David Harrington
Cc: Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne Bartholomew
Subject: Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references?

 

Hi Dave,

I understand your argument, and I tend to agree with you.

The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references;

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].


There are two things we can do

1. do nothing, because it's not worth it.

2. Correct the sentence

OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed):

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.
 
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].
 
   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

NEW: 

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED.
   Implementations MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].
   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

And we move the following references from informative to normative

   [RFC3414] Blumenthal, U., and B. Wijnen, 
             "User-based Security Model (USM) for version 3 of the
             Simple Network Management Protocol (SNMPv3)", RFC 3414,
             December 2002.
 
   [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie,
             "The Advanced Encryption Standard (AES) Cipher 
             Algorithm in the SNMP User-based Security Model",
             RFC 3826, June 2004.
   [RFC5591] Harrington, D., and W. Hardaker,
             "Transport Security Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.
 
   [RFC5592] Harrington, D., Saloway, J., and W. Hardaker,
             "Secure Shell Transport Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.
 
   [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport 
             Model for the Simple Network Management Protocol (SNMP)",
             July 2011.


I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a few documents in AUTH48 waiting on this)

Feedback?
Unless I hear otherwise, I will apply the changes in a week from now.

Thanks Dan for helping on this issue.

Regards, Benoit

Hi,
 
The mib security boilerplate changed in December of 2011, following
discussion between the OPS and Security ADs and the MIB Doctors.
 
IIRC, we always made implementation of SNMPv3 recommended but not required.
No MIB module (except those specifically related to managing SNMPv3)
should require SNMPv3 to work.
Any MIB theoretically should work with any version of SNMP (given known
interoperability issues of SNMPv1 vs SMIv2, etc.).
Theoretically (and according to IAB recommendations in RFC1052), the MIB
should also be able to work with protocols other than SNMP, since "The
MIB" is just a database that (theoretically) is independent of the
protocol used to access it.
So no MIB module (with exceptions) should REQUIRE a specific protocol or
protocol version to access it.
(yawn. I'm sure you guys are tired of hearing this from me ;-)
 
We deliberately made RFC3410 Informational to avoid downrefs.
IIRC, you cannot implement RFC3410 because it doesn't define a protocol;
it's just a roadmap.
 
SNMPv3 was designed as something of a framework that could be built from
multiple pieces - a messaging model, a security model, an ACM model, etc.
RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it
was definitely an SNMPv3 WG decision that this was AN architecture, not
THE architecture for SNMPv3, to allow for alternative approaches (such as
ISMS work on transport models) and to allow for implementation-specific
decisions that would not affect the on-the-wire protocol.
 
The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would
make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which
RFCs actually make up SNMPv3, and are MUST implement).
But that seems to fly in the face of the SNMPv3 WG intention to NOT make a
certain set of RFCs **THE** SNMPv3 definition.
(Of course, the IESG approved an IETF Standard called SNMPv3, which
contained the RFC34xx series as a set of RFCs within the somewhat-abstract
SNMPv3 Standard, to ensure base interoperability.)
 
I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs
MUST be implemented, and make those references normative.
I.e., what you would be doing is defining THE set of RFCs that define
SNMPv3.
 
I personally think it best not to require a specific version of SNMP as
part of the boilerplate for a MIB module.
 
 
--
David Harrington
Ietfdbh@comcast.net
+1-603-828-1401
 
 
 
 
 
On 1/2/13 7:52 AM, "Bert Wijnen" <bwijnen@bwijnen.net> wrote:
 
RFC3410 is an informational document and has ALWAYS been
listed as informational.
So... if you make it Normative, you have a
downref.
The 3414 and 3826 might be listed as Normative.
 
The otehr 3 are only listed as MAY implement. So would it then
have to be normative?
 
For me the most important thing is that the pointers to all
this
documents are listed, so you can quickly find
them.
 
Bert
 
 
 ----- Original Message -----
 From: 
 Benoit Claise <mailto:bclaise@cisco.com>
 
 To: ops-dir@ietf.org ; MIB Doctors
 (E-mail) <mailto:mib-doctors@ietf.org>
 Cc: adslmib-chairs@ietf.org ; Lynne
 Bartholomew <mailto:lbartholomew@amsl.com> ; Edward Beili
<mailto:EdwardB@actelis.com> ; Moti Morgenstern
<mailto:Moti.Morgenstern@ecitele.com>
 Sent: Wednesday, January 02, 2013 12:33
 PM
 Subject: [MIB-DOCTORS] Security
 Guidelines for IETF MIB Modules: normative or informative references?
 
Dear all,
 
In the AUTH48 process for
 draft-ietf-adslmib-gbond-mib-11.txt
(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi
b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=),
 we discussed with the RFC editor whether the following RFCs should be
 normative or informative:
  Implementations MUST provide the security features described by the
  SNMPv3 framework (see [RFC3410]), including full support for
  authentication and privacy via the User-based Security Model (USM)
  [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they
 should be normative, based on the justification at
http://www.ietf.org/iesg/statement/normative-informative.html
 Normative references specify documents that must be read to
   understand or implement the technology in the new RFC, or whose
technology 
   must be present for the technology in the new RFC to work.
 
The 
 RFC editors answered:
 
   Thank you for the email.  We see your point and agree that it
   makes sense that the references would be listed as normative, but we
do not 
   make calls on which documents are listed as informative vs normative.
    We note that 
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists
   the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592,
and 6353 -- as informative. Please request that the wiki
   be
updated, if necessary.
 
 
So normative or informative
 references?
Shall I update the WIKI?
 
Regards, Benoit
 
 
 
 
 
________________________________________
 
 _______________________________________________
MIB-DOCTORS mailing
 list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
 
 
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
 
 

 


--------------000002010000050100020601-- From bclaise@cisco.com Thu Jan 10 10:01:35 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63DE21F8A53 for ; Thu, 10 Jan 2013 10:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TkX3Tmya75R8 for ; Thu, 10 Jan 2013 10:01:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F33E121F8967 for ; Thu, 10 Jan 2013 10:01:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0AI1Xgc014215; Thu, 10 Jan 2013 19:01:33 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0AI1WKi022953; Thu, 10 Jan 2013 19:01:32 +0100 (CET) Message-ID: <50EF01FC.4010403@cisco.com> Date: Thu, 10 Jan 2013 19:01:32 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" , Harrie Hazewinkel References: <50EEFE26.2030405@cisco.com> In-Reply-To: <50EEFE26.2030405@cisco.com> X-Forwarded-Message-Id: <50EEFE26.2030405@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Brian Haberman' Subject: [MIB-DOCTORS] LISP MIB in IETF Last Call: needs a review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:01:35 -0000 MIB doctors, Harrie, LISP MIB in IETF Last Call: https://www.ietf.org/mail-archive/web/ietf-announce/current/msg11050.html Harrie, you did a quick scan around June Would you be willing to review it? Regards, Benoit From j.schoenwaelder@jacobs-university.de Mon Jan 14 01:55:13 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C0F21F888E; Mon, 14 Jan 2013 01:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2E1ZhONgQYwL; Mon, 14 Jan 2013 01:55:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED65521F8570; Mon, 14 Jan 2013 01:55:04 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DEF620BEF; Mon, 14 Jan 2013 10:55:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UsgGGDpPXFDi; Mon, 14 Jan 2013 10:55:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D275820BCD; Mon, 14 Jan 2013 10:55:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8DC2B23F44C0; Mon, 14 Jan 2013 10:55:05 +0100 (CET) Date: Mon, 14 Jan 2013 10:55:05 +0100 From: Juergen Schoenwaelder To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org Message-ID: <20130114095505.GA18424@elstar.local> Mail-Followup-To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org, ops-ads@tools.ietf.org, eman@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: eman@ietf.org, ops-ads@tools.ietf.org Subject: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:55:13 -0000 I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB doctors efforts to review all documents containing MIB modules. See 4181 for some more details. This document has a number of serious issues that need to be resolved before it is ready to be brought to the IESG. I appreciate a quick turn around and in particular if some of the more senior co-editors can make sure issues mentioned below are properly addressed. a) The compliance definitions must be updated to follow SMIv2 rules. This was already mentioned on the list. In short, it is not appropriate to rewrite existing compliance or group definitions. Instead, new ones must be created as needed. b) Move the RFC 2119 requirements language paragraph at the end of section 1 where it belongs (right now it sits at the end of the I-D boilerplate which gets replaced, not in the body of the document) c) The overview states "This is presently true for at least 3 standard MIBs". Did someone check whether this is still accurate? Or better, as an alternative, rephrase this sentence to get rid of "presently"? d) Section 2 provides a high-level overview over the changes of ENTITY-MIB version 2 and 3. There is unfortunately no such text for the version 4. e) I think a paragraph should be added to section 2.12.1 to describe the addition made by version 4 - and if it is just for document consistency. Version 4 of the Entity MIB provides [...] This would also be a good place to explain whether UUIDs are supposed to also be represented as URIs (and why or why not). f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] method of context identification"? For example, "an SnmpEngineID and ContextName pair [RFC3411] for context identification". g) Overall, replace MIBs with MIB modules. h) Section 2.16.2 needs to be updated once the conformance mess has been fixed. i) Proposal for a rewording of 2.16.1: Over time, there is the need to add new enumerated values to the PhysicalClass textual convention. To allow for such additions without requiring to re-issue this MIB module, a new MIB module called IANA-ENTITY-MIB has been created which provides the IANA-maintained textual convention IANAPhysicalClass. The PhysicalClass TC has been deprecated. j) The PhysicalClass TC has been removed from the document, which is another violation of SMIv2 update rules. The TC must be put back and the status of the TC should be changed to deprecated and an explanation added why this was done (see RFC 2579 section 5). k) RFC 4122 is listed both as normative and informative. I think it is normative, no? j) The EMAN example (section 4.3) is full of Cisco details, I think it is more suitable to follow the vendor neutral ACME style of the other examples. Furthermore, it appears to me that the UUID values shown are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please avoid all vendor specific terms. The indexing of the line card slot in the example also seems to be all messed up. And should the line card slot not be contained in the chassis? l) Security considerations: Anything to say about entPhysicalUris and entPhysicalUUID concerning the sensitivity of the data the carry? m) Since this document obsoletes older ENTITY-MIB definitions, are the old definitions still normative references? I would expect not. Note that the document header also does not state that this document obsoletes RFC 4133 - only the abstract does. n) The description of revision 201212110000Z of the ENTITY-MIB has an incomplete sentence... And there is no point in changing previous revision statements (in particular revision 200508100000Z). This also needs to be reverted back. o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible change since entPhysicalUris used to contain a whitespace separated list of URIs. Interestingly, this change is not mentioned anywhere in the changes text. As this change is not compatible, you have to revert it back. p) The description of ianaEntityMIB is not even a complete sentence. q) Proposed rewrite for the description of 'energyObject': OLD The enumeration ?energyObject? is applicable if the physical entity is some sort of a energy object i.e. a piece of equipment that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. NEW The enumeration 'energyObject' is applicable if the physical entity class is some sort of a energy object, i.e., a piece of equipment that is part of or attached to a communications network that is monitored, controlled, or aids in the management of another device for Energy Management. Putting energyObject in single quotes etc. for consistency. r) Proposed rewrite for the description of 'battery': OLD The enumeration 'battery' is applicable of the physical entity class is some sort of an energy battery device. " NEW The enumeration 'battery' is applicable if the physical entity class is some sort of a battery." (Fixing of->if, avoiding 'device', removing useless 'energy'.) s) The description of uuidTCMIB is not even a complete sentence. (The indentation of the SYNTAX clause is somewhat unusual but syntactically valid.) t) The last three paragraphs of the security considerations should be updated to match the new boilerplate text posted here: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Jan 14 02:32:06 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792AA21F8906; Mon, 14 Jan 2013 02:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2UqFFzcaIHv6; Mon, 14 Jan 2013 02:32:05 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1CB21F8925; Mon, 14 Jan 2013 02:32:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EAW2YU010369; Mon, 14 Jan 2013 11:32:02 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EAVfZT025358; Mon, 14 Jan 2013 11:31:51 +0100 (CET) Message-ID: <50F3DE8D.2030202@cisco.com> Date: Mon, 14 Jan 2013 11:31:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mib-doctors@ietf.org, draft-ietf-eman-rfc4133bis@tools.ietf.org, ops-ads@tools.ietf.org, eman@ietf.org References: <20130114095505.GA18424@elstar.local> In-Reply-To: <20130114095505.GA18424@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 10:32:06 -0000 Juergen, draft-ietf-eman-rfc4133bis authors, I did the AD review and the IETF LC started. Juergen, based on AD review email, discovered an important problem with the MIB. Then I proposed to quickly post a new version, before the actual MIB doctor job started (*) Looking at the list of requested changes from Juergen, it's better to wait for the end of the IETF LC to post the next version. However, in the mean time, I advice the draft-ietf-eman-rfc4133bis authors to work on temp version to get Juergen's green light on the new text. Btw, I agree with Juergen's comments. (*) I made a process mistake with this draft: mea culpa. Normally, the MIB doctor review is done between the WG LC and the start the IETF LC. So I sent this draft to IETF LC too fast. So thanks to Juergen for his quick review. Regards, Benoit > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. > > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick > turn around and in particular if some of the more senior co-editors > can make sure issues mentioned below are properly addressed. > > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. > > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) > > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? > > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. > > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. > > Version 4 of the Entity MIB provides [...] > > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". > > g) Overall, replace MIBs with MIB modules. > > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. > > i) Proposal for a rewording of 2.16.1: > > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. > > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an explanation > added why this was done (see RFC 2579 section 5). > > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? > > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? > > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. > > p) The description of ianaEntityMIB is not even a complete sentence. > > q) Proposed rewrite for the description of 'energyObject': > > OLD > > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > NEW > > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > Putting energyObject in single quotes etc. for consistency. > > r) Proposed rewrite for the description of 'battery': > > OLD > > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " > > NEW > > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." > > (Fixing of->if, avoiding 'device', removing useless 'energy'.) > > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) > > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > /js > From moulchan@cisco.com Mon Jan 14 02:44:19 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF821F8931; Mon, 14 Jan 2013 02:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sm0e65j+bGKZ; Mon, 14 Jan 2013 02:44:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 712B821F88E1; Mon, 14 Jan 2013 02:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7705; q=dns/txt; s=iport; t=1358160258; x=1359369858; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xY0XVHThOwFlBwZitYlZIwkzquLrM8+LVxj451kLYKQ=; b=dCauBaV6pxi9V0mhvNOKUJKtBt2R4PKwrDiapz97hpOb6rH+pbljBbur +90VTKhAFJkoueUcANNwHslQhvuMxOJjuKSb4oW+AZ4/B2yysCaCSBbHf rVOz8pwsOHBe3nF69IPfJSO2ZFgbHxCT9efrZ6uh66lGuwGVHZN9tSgn8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFABvh81CtJV2Z/2dsb2JhbAA+BrYWh2YWc4IeAQEBBAEBASQTNBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiBEMtAGMcAYcgzthA4tSi1WFPolvgnWBbzU X-IronPort-AV: E=Sophos;i="4.84,466,1355097600"; d="scan'208";a="162111393" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jan 2013 10:44:18 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0EAiHQa017145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 10:44:17 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 04:44:17 -0600 From: "Mouli Chandramouli (moulchan)" To: "Benoit Claise (bclaise)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" Thread-Topic: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j09YUnlfJCpFUmUM5SweCXWsZhJBMmA//+eVqA= Date: Mon, 14 Jan 2013 10:44:16 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA42867EBA0@xmb-rcd-x08.cisco.com> References: <20130114095505.GA18424@elstar.local> <50F3DE8D.2030202@cisco.com> In-Reply-To: <50F3DE8D.2030202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.82.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MIB-DOCTORS] [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 10:44:19 -0000 Benoit, As you have suggested we shall submit an interim version to address the com= ments of Juergen Schoenwaelder.=20 Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Ben= oit Claise (bclaise) Sent: Monday, January 14, 2013 4:02 PM To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org; ops-ad= s@tools.ietf.org; eman@ietf.org Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Juergen, draft-ietf-eman-rfc4133bis authors, I did the AD review and the IETF LC started. Juergen, based on AD review=20 email, discovered an important problem with the MIB. Then I proposed to=20 quickly post a new version, before the actual MIB doctor job started (*) Looking at the list of requested changes from Juergen, it's better to=20 wait for the end of the IETF LC to post the next version. However, in the mean time, I advice the draft-ietf-eman-rfc4133bis=20 authors to work on temp version to get Juergen's green light on the new=20 text. Btw, I agree with Juergen's comments. (*) I made a process mistake with this draft: mea culpa. Normally, the=20 MIB doctor review is done between the WG LC and the start the IETF LC.=20 So I sent this draft to IETF LC too fast. So thanks to Juergen for his=20 quick review. Regards, Benoit > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. > > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick > turn around and in particular if some of the more senior co-editors > can make sure issues mentioned below are properly addressed. > > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. > > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) > > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? > > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. > > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. > > Version 4 of the Entity MIB provides [...] > > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". > > g) Overall, replace MIBs with MIB modules. > > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. > > i) Proposal for a rewording of 2.16.1: > > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. > > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an explanati= on > added why this was done (see RFC 2579 section 5). > > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? > > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? > > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. > > p) The description of ianaEntityMIB is not even a complete sentence. > > q) Proposed rewrite for the description of 'energyObject': > > OLD > > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > NEW > > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. > > Putting energyObject in single quotes etc. for consistency. > > r) Proposed rewrite for the description of 'battery': > =20 > OLD > > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " > > NEW > > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." > > (Fixing of->if, avoiding 'device', removing useless 'energy'.) > > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) > > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > > /js > _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From bclaise@cisco.com Mon Jan 14 03:26:07 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207521F84DD for ; Mon, 14 Jan 2013 03:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 rtgXbVv99UJV for ; Mon, 14 Jan 2013 03:26:06 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1112E21F84D0 for ; Mon, 14 Jan 2013 03:26:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EBQ4ZH016669; Mon, 14 Jan 2013 12:26:04 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EBPHXV008544; Mon, 14 Jan 2013 12:25:32 +0100 (CET) Message-ID: <50F3EB1D.1040801@cisco.com> Date: Mon, 14 Jan 2013 12:25:17 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Stiemerling , Michael MacFaden References: <50758E1C.6070706@neclab.eu> <50759DA6.9020900@cisco.com> <50C858A9.6080905@neclab.eu> In-Reply-To: <50C858A9.6080905@neclab.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , "storm-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [MIB-DOCTORS] Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 11:26:07 -0000 Hi Mike, Can you please have a look to see if this latest version addresses your points at http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt Regards, Benoit > Benoit, MIB Doctors, > > Did anybody have time to check the updated iSCSI MIB? > > I would like to progress the draft to the IESG soon. > > Thank you in advance, > > Martin > > On 10/10/2012 06:09 PM, Benoit Claise wrote: >> Hi Mike, >> >> As far as I know, you did the review of draft-ietf-storm-iscsimib >> Can you please have a look to see if this latest version addresses your >> points at http://www.macfaden.com/ietf/iscsi-mib-1-reviewed.txt >> >> Regards, Benoit >>> Hi Ron and Benoit, >>> >>> The MIB doctors did a review of draft-ietf-storm-iscsimib a while back >>> and did comment on the text, but also on the MIB module itself. >>> (https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib) >>> >>> The STORM working group has gone through the review and updated the >>> draft to address these. >>> >>> Can you please ask the MIB doctors to review the ISCSI MIB module >>> again? >>> >>> Thanks in advance, >>> >>> Martin >>> >> > From bclaise@cisco.com Mon Jan 14 04:01:19 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D921F8607 for ; Mon, 14 Jan 2013 04:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sVOR29hUiFev for ; Mon, 14 Jan 2013 04:01:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D5A1321F85C2 for ; Mon, 14 Jan 2013 04:01:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EC1CmM020781; Mon, 14 Jan 2013 13:01:12 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EC0QTk007272; Mon, 14 Jan 2013 13:00:37 +0100 (CET) Message-ID: <50F3F35A.6010005@cisco.com> Date: Mon, 14 Jan 2013 13:00:26 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary="------------000302000809000309060004" Cc: 'Brian Haberman' , Stewart Bryant Subject: [MIB-DOCTORS] MIB doctors: need your help. X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:01:19 -0000 This is a multi-part message in MIME format. --------------000302000809000309060004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear MIB doctors, We have two MIB modules that need a review. - draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt is on the IESG telechat for Jan 24th, and looking for a MIB doctor (*) This one should be easy, since Bert Wijnen is an author, and checked many things already If we can't find a MIB doctor, we will have to remove this draft from the telechat - draft-ietf-lisp-mib-08.txt is in IETF LC till Jan 21st, and looking for a MIB doctor (*) Harrie, you did a quick scan around June Would you be willing to review it? (*) I made a process mistake with the drafts above: mea culpa. Normally, the MIB doctor review is done between the WG LC and the start the IETF LC. So I sent the two drafts progressed without a MIB doctor review. Note that https://svn.tools.ietf.org/area/ops/trac/wiki/Directorates has been updated with The MIB doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include MIB documents should ask the OPS ADs for a MIB review as soon as the document completed WGLC. We had a couple of reviews lately (or still in progress): * draft-ietf-eman-rfc4133bis done by Juergen Schoenwaelder * draft-ietf-storm-iscsimib, done by Mike MacFaden * draft-ietf-mpls-te-tp-mib, done by Joan Cucchiara * draft-ietf-ccamp-gmpls-ted-mib, done by Joan Cucchiara * draft-ietf-mpls-tp-oam-id-mib-01.txt, done by Joan Cucchiara * MEF UNIV-EVC MIB, by Bob Cole * probably, I missed some. Sorry. I would appreciate if the other MIB doctors would volunteer for the two MIB module reviews above. Regards, Benoit --------------000302000809000309060004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear MIB doctors,

We have two MIB modules that need a review.

- draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt is on the IESG telechat for Jan 24th, and looking for a MIB doctor (*)
    This one should be easy, since Bert Wijnen is an author, and checked many things already
    If we can't find a MIB doctor, we will have to remove this draft from the telechat

- draft-ietf-lisp-mib-08.txt is in IETF LC till Jan 21st, and looking for a MIB doctor (*)
    Harrie, you did a quick scan around June
    Would you be willing to review it?

(*) I made a process mistake with the drafts above: mea culpa. Normally, the MIB doctor review is done between the WG LC and the start the IETF LC. So I sent the two drafts progressed without a MIB doctor review.
Note that https://svn.tools.ietf.org/area/ops/trac/wiki/Directorates has been updated with
The MIB doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include MIB documents should ask the OPS ADs for a MIB review as soon as the document completed WGLC.
We had a couple of reviews lately (or still in progress):
    * draft-ietf-eman-rfc4133bis done by Juergen Schoenwaelder
    * draft-ietf-storm-iscsimib, done by Mike MacFaden
    * draft-ietf-mpls-te-tp-mib, done by Joan Cucchiara
    * draft-ietf-ccamp-gmpls-ted-mib, done by Joan Cucchiara
    * draft-ietf-mpls-tp-oam-id-mib-01.txt, done by Joan Cucchiara
    * MEF UNIV-EVC MIB, by Bob Cole
    * probably, I missed some. Sorry.

I would appreciate if the other MIB doctors would volunteer for the two MIB module reviews above.

Regards, Benoit
--------------000302000809000309060004-- From hhazewinkel@gmail.com Mon Jan 14 04:08:18 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB021F8525 for ; Mon, 14 Jan 2013 04:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vLvGnV0ip7zB for ; Mon, 14 Jan 2013 04:08:18 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6421F8506 for ; Mon, 14 Jan 2013 04:08:17 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id z53so2019750wey.20 for ; Mon, 14 Jan 2013 04:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=pjbYiAK2n0Vl0WuUBfcesMtoXSFyzxn5YPenL1ExDqY=; b=NROTA5dRVmPTqly79QiJLCVGba8fNvTbHzig+fVZvpfOQeCGKZa0zJhxQ4PUxiSjXJ E4zkzbWatEpUBbB9yypCjlU/Cst0z1AVKgACsAc9RffmnmAbruQB8bnVFG0V5Brp1h2r PnVHH/m0tcrzixQ9bYBcWFtAC5wPyK2DIQUB6MEwlC+VQM3l+d44rr1QvkdSfjHXWudw SJk7nyan6zICJuaZ/zUulXk79DC4EINg2BrbUiQN5shwePJbU/9/WffOurCk0UgxM/83 ONMjCFtJhgOhbn8k0TZcFWyNZt92JihjZVdyLH9GYipFIBZWLDV95o9iYGKZnY8RlfYg 4vbA== X-Received: by 10.181.13.195 with SMTP id fa3mr11991092wid.8.1358165297220; Mon, 14 Jan 2013 04:08:17 -0800 (PST) Received: from [192.168.178.73] (53559558.cm-6-6c.dynamic.ziggo.nl. [83.85.149.88]) by mx.google.com with ESMTPS id ew4sm13732644wid.11.2013.01.14.04.08.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 04:08:16 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Harrie Hazewinkel In-Reply-To: <50F3F35A.6010005@cisco.com> Date: Mon, 14 Jan 2013 13:08:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F3F35A.6010005@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1499) Cc: "MIB Doctors \(E-mail\)" , 'Brian Haberman' , Stewart Bryant Subject: Re: [MIB-DOCTORS] MIB doctors: need your help. X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:08:19 -0000 Hello, On Jan 14, 2013, at 1:00 PM, Benoit Claise wrote: > - draft-ietf-lisp-mib-08.txt is in IETF LC till Jan 21st, and looking = for a MIB doctor (*) > Harrie, you did a quick scan around June=20 > Would you be willing to review it?=20 I am willing to do this, but I am not sure if I will make a full review = before 21st. Is that a hard deadline? Harrie hhazewinkel@gmail.com From brian@innovationslab.net Mon Jan 14 05:12:51 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158DD21F856D for ; Mon, 14 Jan 2013 05:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KznAvfJdhQHC for ; Mon, 14 Jan 2013 05:12:50 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 274EA21F84D3 for ; Mon, 14 Jan 2013 05:12:50 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D748A88153; Mon, 14 Jan 2013 05:12:49 -0800 (PST) Received: from 1025265105.rude1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 84469130019; Mon, 14 Jan 2013 05:12:53 -0800 (PST) Message-ID: <50F40459.6010603@innovationslab.net> Date: Mon, 14 Jan 2013 08:12:57 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Harrie Hazewinkel References: <50F3F35A.6010005@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , Stewart Bryant Subject: Re: [MIB-DOCTORS] MIB doctors: need your help. X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 13:12:51 -0000 Hi Harrie, On 1/14/13 7:08 AM, Harrie Hazewinkel wrote: > Hello, > > On Jan 14, 2013, at 1:00 PM, Benoit Claise wrote: >> - draft-ietf-lisp-mib-08.txt is in IETF LC till Jan 21st, and looking for a MIB doctor (*) >> Harrie, you did a quick scan around June >> Would you be willing to review it? > > I am willing to do this, but I am not sure if I will make a full review before 21st. > Is that a hard deadline? > That is the end of IETF Last Call. I have not scheduled this draft for an IESG telechat, as of yet. The next possible telechat would be 1/24, but it could also be pushed off to 2/7. I would like a MIB Doctor review before IESG review, so if 1/24 is not feasible just let me know. Thanks, Brian From dromasca@avaya.com Mon Jan 14 08:05:22 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921F21F87BA; Mon, 14 Jan 2013 08:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.395 X-Spam-Level: X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 E+8-i9qsw4Es; Mon, 14 Jan 2013 08:05:20 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 869B521F8738; Mon, 14 Jan 2013 08:05:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAIbQt1CHCzI1/2dsb2JhbAA6BAMDgX9ttU6HSxZzgh4BAQEBAgESFRM/BQcCAgIBCA0BAgEEAQELFAkHGxcUCQgCBAENBQgTB4doBgELoXudDASMPAUMBBJugkthA4tNi1CEcUyJa4JygWM+ X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="384361863" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jan 2013 10:55:35 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jan 2013 10:39:51 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 11:05:21 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j1HkH9GpL6Iw0undeMeNNuIRZhI4EuA Date: Mon, 14 Jan 2013 16:05:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> In-Reply-To: <20130114095505.GA18424@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "eman@ietf.org" , "ops-ads@tools.ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:05:22 -0000 Hi Juergen,=20 Thanks for the detailed review.=20 Please see in-line the responses and proposals for update.=20 For a couple of points I am waiting for answers from Mouli.=20 Please let us know if the proposed resolutions answer your concerns. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 11:55 AM > To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org > Cc: ops-ads@tools.ietf.org; eman@ietf.org > Subject: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 > I have reviewed draft-ietf-eman-rfc4133bis-05.txt as part of the MIB > doctors efforts to review all documents containing MIB modules. See > 4181 for some more details. >=20 > This document has a number of serious issues that need to be resolved > before it is ready to be brought to the IESG. I appreciate a quick turn > around and in particular if some of the more senior co-editors can make > sure issues mentioned below are properly addressed. >=20 > a) The compliance definitions must be updated to follow SMIv2 rules. > This was already mentioned on the list. In short, it is not > appropriate to rewrite existing compliance or group definitions. > Instead, new ones must be created as needed. >=20 [[DR]] Right. The existing compliance and group definitions will be kept as= in RFC4133 today and we shall create two new compliance groups entity4Comp= liance and entity4CRCompliance.=20 =20 > b) Move the RFC 2119 requirements language paragraph at the end of > section 1 where it belongs (right now it sits at the end of the I-D > boilerplate which gets replaced, not in the body of the document) >=20 [[DR]] Actually I believe that this document does not need any reference to= RFC 2119 at all, so we can take out that paragraph and the reference to [2= 119] out completely.=20 > c) The overview states "This is presently true for at least 3 standard > MIBs". Did someone check whether this is still accurate? Or better, > as an alternative, rephrase this sentence to get rid of > "presently"? >=20 [[DR]] This text is taken 'as is' from RFC 4133. None of the three example = MIB modules was deprecated. So it's still true.=20 In general we avoided making changes in the document unless necessary. > d) Section 2 provides a high-level overview over the changes of > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > the version 4. >=20 [[DR]] Proposed Solution:=20 Add at the end of Section 2 the following text:=20 Version 3 of this MIB addresses new requirements, which have emerged since the publication of the third Entity MIB (RFC 4133 [RFC4133]). There is a need to add new enumerated values for physical classes, a=20 need to provide identification information for entity objects in=20 a Universal Unique Identifier (UUID) formats, and a need to describe Constrained Resources (CR) entities. The PhysicalClass Textual=20 Convention (TC) was deprecated and a new IANAPhysicalClass TC was=20 created. A new TC UUIDorZero was created to represent a UUID and a new object was added to the entPhysicalTable to identify the UUID.=20 > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. >=20 > Version 4 of the Entity MIB provides [...] >=20 > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). >=20 [[DR]] I will let Mouli address this, as I am not sure 100% about the respo= nse to the issue of representation.=20 > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > method of context identification"? For example, "an SnmpEngineID > and ContextName pair [RFC3411] for context identification". >=20 [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a bug I= suggest to avoid such changes.=20 > g) Overall, replace MIBs with MIB modules. >=20 [[DR]] Same as the previous point.=20 > h) Section 2.16.2 needs to be updated once the conformance mess has been > fixed. >=20 [[DR]]=20 OLD:=20 Creation of a new MODULE-COMPLIANCE module entity4CRCompliance for devices with constrained resources like batteries, which might require a limited number of objects to be supported (entPhysicalClass, entPhysicalName, entPhysicalUUID)=20 NEW:=20 Creation of two new MODULE-COMPLIANCE modules entity4Compliance for full compliance with version 4 of the Entity MIB and=20 entity4CRCompliance for devices with constrained resources like batteries, which might require a limited number of objects to be supported (entPhysicalClass, entPhysicalName, entPhysicalUUID)=20 > i) Proposal for a rewording of 2.16.1: >=20 > Over time, there is the need to add new enumerated values to the > PhysicalClass textual convention. To allow for such additions > without requiring to re-issue this MIB module, a new MIB module > called IANA-ENTITY-MIB has been created which provides the > IANA-maintained textual convention IANAPhysicalClass. The > PhysicalClass TC has been deprecated. >=20 [[DR]] OK > j) The PhysicalClass TC has been removed from the document, which is > another violation of SMIv2 update rules. The TC must be put back and > the status of the TC should be changed to deprecated and an > explanation > added why this was done (see RFC 2579 section 5). >=20 [[DR]] OK - we shall change the status to deprecated and add text clarifyin= g=20 that starting with version 4 of the MIB module the use of the IANAPhysicalC= lass TC is recommended instead.=20 > k) RFC 4122 is listed both as normative and informative. I think it is > normative, no? >=20 [[DR]] yes. > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? >=20 [[DR]] Mouli - can you please look at these?=20 > l) Security considerations: Anything to say about entPhysicalUris and > entPhysicalUUID concerning the sensitivity of the data the carry? >=20 [[DR]] good point, although entPhysicalUri was not listed previously as sen= sitive. I would suggest to add the two objects to the list of objects that = expose information about the physical entities within a managed system, whi= ch may be used to identify the vendor, model, and version information of ea= ch system component.=20 > m) Since this document obsoletes older ENTITY-MIB definitions, are the > old definitions still normative references? I would expect not. Note > that the document header also does not state that this document > obsoletes RFC 4133 - only the abstract does. >=20 [[DR]] The header should be updated.=20 > n) The description of revision 201212110000Z of the ENTITY-MIB has an > incomplete sentence... And there is no point in changing previous > revision statements (in particular revision 200508100000Z). This > also needs to be reverted back. >=20 [[DR]] OK. Actually the 2012... revision will not be mentioned any longer.= =20 > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > change since entPhysicalUris used to contain a whitespace separated > list of URIs. Interestingly, this change is not mentioned anywhere > in the changes text. As this change is not compatible, you have to > revert it back. [[DR]] It's the first time this comment is made (as a few other as well). S= ure, if the change is not backwards compatible, this needs to be reversed.= =20 >=20 > p) The description of ianaEntityMIB is not even a complete sentence. >=20 [[DR]] s/This MIB module/This MIB Module defines a Textual Convention that = provides an indication of the general hardware type of a particular physica= l entity./ > q) Proposed rewrite for the description of 'energyObject': >=20 > OLD >=20 > The enumeration ?energyObject? is applicable if the > physical entity is some sort of a energy object i.e. > a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. >=20 > NEW >=20 > The enumeration 'energyObject' is applicable if the > physical entity class is some sort of a energy object, > i.e., a piece of equipment that is part of or attached to > a communications network that is monitored, controlled, > or aids in the management of another device for Energy > Management. >=20 > Putting energyObject in single quotes etc. for consistency. >=20 [[DR]] OK.=20 > r) Proposed rewrite for the description of 'battery': >=20 > OLD >=20 > The enumeration 'battery' is applicable of the physical > entity class is some sort of an energy battery device. " >=20 > NEW >=20 > The enumeration 'battery' is applicable if the physical > entity class is some sort of a battery." >=20 > (Fixing of->if, avoiding 'device', removing useless 'energy'.) >=20 [[DR]] OK.=20 > s) The description of uuidTCMIB is not even a complete sentence. (The > indentation of the SYNTAX clause is somewhat unusual but > syntactically valid.) >=20 [[DR]] s/This MIB module/This MIB module defines a Textual Convention that = provides an indication of the general hardware type of a particular physica= l entity./ > t) The last three paragraphs of the security considerations should > be updated to match the new boilerplate text posted here: >=20 > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security >=20 [[DR]] OK.=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From aldrin.ietf@gmail.com Mon Jan 14 08:43:15 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C521F86B8 for ; Mon, 14 Jan 2013 08:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 3sT4qdZtPugo for ; Mon, 14 Jan 2013 08:43:14 -0800 (PST) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 191A621F8546 for ; Mon, 14 Jan 2013 08:43:04 -0800 (PST) Received: by mail-da0-f54.google.com with SMTP id n2so1902085dad.41 for ; Mon, 14 Jan 2013 08:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:message-id:mime-version:subject:date :references:cc:to:x-mailer; bh=3/afLcDQWAGETi/WcBH69BK/6KgJUTN8ICsa2I6RvDI=; b=rW6ilA9HT3K6jMhqkUMrKyYYwi9i2+UGgOs2knJDj9miXdSXIn7LNGfsUiFfhLK//h ocFC8kVj7JA3wanIkVztRCFZabH9K+/7o1azJ+B5TXYL0r6vRq3SSz8iEcsQXdWNbFN3 8gu7IFDpqkV2+5h6CNAhiQ3QL5VrLPYPg5R1c3Aie0a0MUwo1WG79ctw2ye/PYNV2vuO sWRzhVKwbV7lf5XK9opnc0tqxiJ3Ks/+gk8Bqq/OmXS2lqfX+4XNzkmGSQOqhODGocBJ Sbat+nwd1S9oew6F6aBABW7p17xNiYK/WE+Brmto3AyWIkrcgNXRF6H9ksRq9mXGUSKA uyYQ== X-Received: by 10.68.130.226 with SMTP id oh2mr213726193pbb.157.1358181783587; Mon, 14 Jan 2013 08:43:03 -0800 (PST) Received: from [192.168.1.5] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id wh8sm8464204pbc.75.2013.01.14.08.42.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:43:01 -0800 (PST) From: Sam Aldrin Content-Type: multipart/mixed; boundary="Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Mon, 14 Jan 2013 08:43:03 -0800 References: To: Joan Cucchiara , "MIB Doctors (E-mail)" , Randy Presuhn X-Mailer: Apple Mail (2.1499) Cc: Venkatesan Mahalingam , Thomas Nadeau , Kannan Sampath , Loa Andersson Subject: [MIB-DOCTORS] MPLS TP TE MIB - Edited for review comments X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:43:15 -0000 --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Joan, et al, We have submitted a new version of the draft for MPLS TP TE MIB, as the = existing revision is going to expire today. Most, if not all, of the comments have been addressed. If we have not = addressed any comments, it could be oversight and not intentional. All the comments we have received are being tracked via excel sheet. Could you kindly review the updated MIB (diffs are attached as well) and = let us know if there is something we need to change/fix/not addressed? Apologize as it took a while to update, due to holidays etc. Thanks in advance -sam >=20 --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Disposition: attachment; filename=draft-ietf-mpls-tp-te-mib-05.txt Content-Type: text/plain; name="draft-ietf-mpls-tp-te-mib-05.txt" Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D Network Working Group =0D= INTERNET-DRAFT M.Venkatesan=0D= Intended Status: Standards Track Dell Inc.=0D= Expires: July 18, 2013 Kannan KV Sampath=0D= Redeem=0D= Sam K. Aldrin=0D= Huawei Technologies=0D= Thomas D. Nadeau=0D= Juniper Networks=0D= =0D January 14, 2013=0D= =0D =0D MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)=0D draft-ietf-mpls-tp-te-mib-05.txt=0D =0D =0D Abstract=0D =0D This memo defines a portion of the Management Information Base (MIB)=0D= for use with network management protocols in the Internet community.=0D= In particular, it describes managed objects of Tunnels, Identifiers,=0D= Label Switch Router and Textual conventions for Multiprotocol Label=0D= Switching (MPLS) based Transport Profile (TP).=0D =0D Status of this Memo=0D =0D This Internet-Draft is submitted to IETF in full conformance with the=0D= provisions of BCP 78 and BCP 79.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than as "work in progress."=0D =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/ietf/1id-abstracts.txt.=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html.=0D =0D This Internet-Draft will expire on July 18, 2013.=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 1]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D Copyright and License Notice=0D =0D Copyright (c) 2013 IETF Trust and the persons identified as the=0D document authors. All rights reserved.=0D =0D This document is subject to BCP 78 and the IETF Trust's Legal=0D Provisions Relating to IETF Documents=0D (http://trustee.ietf.org/license-info) in effect on the date of=0D publication of this document. Please review these documents=0D carefully, as they describe your rights and restrictions with respect=0D= to this document. Code Components extracted from this document must=0D= include Simplified BSD License text as described in Section 4.e of=0D the Trust Legal Provisions and are provided without warranty as=0D described in the Simplified BSD License.=0D =0D =0D =0D =0D Table of Contents=0D =0D 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 2. The Internet-Standard Management Framework . . . . . . . . . . 4=0D= 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 3.1. Conventions used in this document . . . . . . . . . . . . . 4=0D= 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 3.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5=0D= 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0D= 5. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 5=0D= 6. Brief description of MIB Objects . . . . . . . . . . . . . . . 5=0D= 6.1. mplsTunnelExtNodeConfigTable . . . . . . . . . . . . . . . 6=0D= 6.2. mplsTunnelExtNodeIpMapTable . . . . . . . . . . . . . . . . 6=0D= 6.3. mplsTunnelExtNodeIccMapTable . . . . . . . . . . . . . . . 7=0D= 6.4. mplsTunnelExtTable . . . . . . . . . . . . . . . . . . . . 7=0D= 6.5. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . . . 7=0D= 7. MIB Module Interdependencies . . . . . . . . . . . . . . . . . 7=0D= 8. Dependencies between MIB Module Tables . . . . . . . . . . . . 9=0D= 9. Example of MPLS-TP Tunnel Setup . . . . . . . . . . . . . . . . 9=0D= 9.1. Example of MPLS-TP static co-routed bidirectional tunnel=0D setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 10=0D= 9.1.1. mplsTunnelEntry . . . . . . . . . . . . . . . . . . . . 10=0D= 9.1.2. mplsTunnelExtEntry . . . . . . . . . . . . . . . . . . 11=0D= 9.1.3. Forward direction mplsOutSegmentEntry . . . . . . . . . 12=0D= 9.1.4. Reverse direction mplsInSegmentEntry . . . . . . . . . 12=0D= 9.1.5. Forward direction mplsXCEntry . . . . . . . . . . . . . 12=0D= 9.1.6. Reverse direction mplsXCEntry . . . . . . . . . . . . . 13=0D= 9.1.7. Forward direction mplsXCExtEntry . . . . . . . . . . . 13=0D= 9.1.8. Reverse direction mplsXCExtEntry . . . . . . . . . . . 13=0D= 9.1.9. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . 13=0D= =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 2]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 9.2. Example of MPLS-TP static associated bidirectional tunnel=0D setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 14=0D= 9.2.1. Forward direction mplsTunnelEntry . . . . . . . . . . . 14=0D= 9.2.2. Forward direction mplsTunnelExtEntry . . . . . . . . . 15=0D= 9.2.3. Forward direction mplsOutSegmentTable . . . . . . . . . 15=0D= 9.2.4. Forward direction mplsXCEntry . . . . . . . . . . . . . 15=0D= 9.2.5. Forward direction mplsXCExtEntry . . . . . . . . . . . 16=0D= 9.2.6. Reverse direction mplsTunnelEntry . . . . . . . . . . . 16=0D= 9.2.7. Reverse direction mplsTunnelExtEntry . . . . . . . . . 17=0D= 9.2.8. Reverse direction mplsInSegmentEntry . . . . . . . . . 17=0D= 9.2.9. Reverse direction mplsXCEntry . . . . . . . . . . . . . 17=0D= 9.2.10. Reverse direction mplsXCExtEntry . . . . . . . . . . . 18=0D= 9.3. Example of MPLS-TP signaling co-routed bidirectional=0D tunnel setup . . . . . . . . . . . . . . . . . . . . . . . 18=0D= 9.3.1. mplsTunnelEntry . . . . . . . . . . . . . . . . . . . . 18=0D= 9.3.2. mplsTunnelExtEntry . . . . . . . . . . . . . . . . . . 19=0D= 9.3.3. Forward direction mplsOutSegmentEntry . . . . . . . . . 19=0D= 9.3.4. Reverse direction mplsInSegmentEntry . . . . . . . . . 19=0D= 9.3.5. Forward direction mplsXCEntry . . . . . . . . . . . . . 20=0D= 9.3.6. Reverse direction mplsXCEntry . . . . . . . . . . . . . 20=0D= 9.3.7. Forward direction mplsXCExtEntry . . . . . . . . . . . 20=0D= 9.3.8. Reverse direction mplsXCExtEntry . . . . . . . . . . . 20=0D= 9.3.9. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . 20=0D= 10. MPLS Textual Convention Extension MIB definitions . . . . . . 20=0D= 11. MPLS Identifier MIB definitions . . . . . . . . . . . . . . . 23=0D= 12. MPLS LSR Extension MIB definitions . . . . . . . . . . . . . . 27=0D= 13. MPLS Tunnel Extension MIB definitions . . . . . . . . . . . . 31=0D= 14. Security Consideration . . . . . . . . . . . . . . . . . . . . 49=0D= 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50=0D= 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50=0D= 16.1. Normative References . . . . . . . . . . . . . . . . . . . 50=0D= 16.2. Informative References . . . . . . . . . . . . . . . . . 50=0D= 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51=0D= 18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 3]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 1. Introduction=0D =0D This memo defines a portion of the Management Information Base (MIB) for=0D= use with network management protocols in the Internet community. In=0D particular, it describes managed objects of Tunnels, Identifiers, Label=0D= Switch Router and Textual conventions for Multiprotocol Label Switching=0D= (MPLS) based Transport Profile (TP). This draft extends the existing=0D MPLS MIB objects for both MPLS-TP and Non-MPLS-TP operations, so the=0D MPLS-TP name is not included in the MIB module name.=0D =0D The existing Multiprotocol Label Switching (MPLS) Traffic Engineering=0D (TE) Management Information Base (MIB) [RFC3812] and Generalized=0D Multiprotocol Label Switching (GMPLS) Traffic Engineering Management=0D Information Base [RFC4802] do not support the transport network=0D requirements of NON-IP based management and static bidirectional=0D tunnels. This MIB module should be used in conjunction with [RFC3812]=0D and companion document [RFC3813] for MPLS based traffic engineering=0D configuration and management.=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be=0D= interpreted as described in BCP 14, RFC2119.=0D =0D 2. The Internet-Standard Management Framework=0D =0D For a detailed overview of the documents that describe the current=0D Internet-Standard Management Framework, please refer to section 7 of=0D RFC3410 [RFC3410].=0D =0D Managed objects are accessed via a virtual information store, termed the=0D= Management Information Base or MIB. MIB objects are generally accessed=0D= through the Simple Network Management Protocol (SNMP). Objects in the=0D MIB are defined using the mechanisms defined in the Structure of=0D Management Information (SMI). This memo specifies a MIB module that is=0D= compliant to the SMIv2, which is described in STD 58, RFC2578, STD 58,=0D= RFC2579 and STD58, RFC2580.=0D =0D =0D 3. Overview=0D =0D 3.1. Conventions used in this document=0D =0D The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D document are to be interpreted as described in [RFC2119].=0D =0D 3.2. Terminology=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 4]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D This document uses terminology from the Multiprotocol Label Switching=0D Architecture [RFC3031], Multiprotocol Label Switching (MPLS) Traffic=0D Engineering (TE) Management Information Base (MIB) [RFC3812],=0D Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)=0D Management Information Base (MIB) [RFC3813] and MPLS Transport Profile=0D= (MPLS-TP) Identifiers [RFC6370].=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 5]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 3.3. Acronyms=0D =0D GMPLS: Generalized Multi-Protocol Label Switching=0D ICC: ITU Carrier Code=0D IP: Internet Protocol=0D LSP: Label Switching Path=0D LSR: Label Switching Router=0D MIB: Management Information Base=0D MPLS: Multi-Protocol Label Switching=0D MPLS-TP: MPLS Transport Profile=0D OSPF: Open Shortest Path First=0D PW: Pseudowire=0D TE: Traffic Engineering=0D TP: Transport Profile=0D =0D 4. Motivations=0D =0D Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management=0D= Information Base (MIB) [RFC3812] provides support for Traffic=0D Engineering tunnels. However, with MPLS-TP, the characteristics of=0D Tunnels were enhanced. For example, MPLS-TP tunnels are bidirectional in=0D= nature and could be used in non-IP environment. As the existing MPLS-TE-=0D= STD-MIB is not sufficient to capture all the characteristics of the=0D tunnels, enhancing the MIB to support MPLS TP tunnels is required. As=0D most of the attributes of MPLS Traffic Engineering tunnels are also=0D applicable to MPLS-TP tunnels, it is optimal to re-use the existing MIB=0D= definition instead of a new MIB.=0D =0D This MIB also defines three other MIB modules within this document. As=0D= these new MIB modules are small in size, MPLS-TC-EXT-STD-MIB, MPLS-ID-=0D= STD-MIB and MPLS-LSR-EXT-STD-MIB are retained in the same document,=0D instead of a separate document.=0D =0D 5. Feature List=0D =0D The MPLS transport profile MIB module is designed to satisfy the=0D following requirements and constraints:=0D =0D The MIB module supports static and signaling point-to-point, co-routed=0D= bi-directional and associated bi-directional tunnels.=0D =0D - The MPLS tunnels need not be interfaces, but it is possible=0D to configure a TP tunnel as an interface.=0D =0D - The mplsTunnelTable [RFC3812] to be also used for MPLS-TP=0D tunnels=0D =0D - The mplsTunnelTable is extended to support MPLS-TP specific=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 6]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D objects.=0D =0D - A node configuration table (mplsTunnelExtNodeConfigTable)=0D is used to translate the Global_Node_ID or ICC to the local=0D identifier in order to index mplsTunnelTable.=0D =0D - The MIB module supports persistent, as well as non-persistent=0D= tunnels.=0D =0D =0D 6. Brief description of MIB Objects=0D =0D =0D The objects described in this section support the functionality=0D described in documents [RFC5654] and [RFC6370]. The tables support=0D= both IP compatible and ICC based tunnel configurations.=0D =0D 6.1. mplsTunnelExtNodeConfigTable=0D =0D The mplsTunnelExtNodeConfigTable is used to assign a local identifier=0D= for a given ICC or Global_Node_ID combination as defined in=0D [RFC6370]. An ICC is a string of one to six characters, each=0D character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9)=0D characters. Alphabetic characters in the ICC should be represented=0D with upper case letters. In the IP compatible mode,=0D Global_Node_ID, is used to uniquely identify a node.=0D =0D Each ICC or Global_Node_ID contains one unique entry in the=0D table representing a node. Every node is assigned a local identifier=0D= within a range of 0 to 16777215. This local identifier is used for=0D indexing into mplsTunnelTable as mplsTunnelIngressLSRId and=0D mplsTunnelEgressLSRId.=0D =0D For IP compatible environment, MPLS-TP tunnel is indexed by Tunnel=0D Index, Tunnel Instance, Source Global_ID, Source Node_ID, Destination=0D= Global_ID and Destination Node_ID.=0D =0D For ICC based environment, MPLS-TP tunnel is indexed by Tunnel Index,=0D= Tunnel Instance, Source ICC and Destination ICC.=0D =0D As mplsTunnelTable is indexed by mplsTunnelIndex,=0D mplsTunnelInstance, mplsTunnelIngressLSRId, and=0D mplsTunnelEgressLSRId, the MPLS-TP tunnel identifiers cannot be=0D used directly.=0D =0D The mplsTunnelExtNodeConfigTable will be used to store an entry for=0D= ICC or Global_Node_ID with a local identifier to be used as LSR ID in=0D= mplsTunnelTable. As the regular TE tunnels use IP address as LSR ID,=0D= =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 7]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D the local identifier should be below the first valid IP address,=0D which is 16777216[1.0.0.0].=0D =0D 6.2. mplsTunnelExtNodeIpMapTable=0D =0D The read-only mplsTunnelExtNodeIpMaptable is used to query the local=0D= identifier assigned and stored in mplsTunnelExtNodeConfigTable for=0D a given Global_Node_ID. In order to query the local identifier,=0D in the IP compatible mode, this table is indexed with Global_Node_ID.=0D= In the IP compatible mode for a TP tunnel, Global_Node_ID=0D is used.=0D =0D A separate query is made to get the local identifier of both=0D Ingress and Egress Global_Node_ID identifiers. These local=0D identifiers are used as mplsTunnelIngressLSRId and=0D mplsTunnelEgressLSRId, while indexing mplsTunnelTable.=0D =0D =0D 6.3. mplsTunnelExtNodeIccMapTable=0D =0D The read-only mplsTunnelExtNodeIccMapTable is used to query the local=0D= identifier assigned and stored in the mplsTunnelExtNodeConfigTable=0D for a given ICC.=0D =0D A separate query is made to get the local identifier of both=0D Ingress and Egress ICC. These local identifiers are used as=0D mplsTunnelIngressLSRId and mplsTunnelEgressLSRId,=0D while indexing mplsTunnelTable.=0D =0D 6.4. mplsTunnelExtTable=0D =0D mplsTunnelExtTable extends the mplsTunnelTable in order to support=0D MPLS-TP tunnels with additional objects. All the additional=0D attributes specific to supporting TP tunnel are contained in this=0D extended table and could be accessed with the mplsTunnelTable=0D indices.=0D =0D 6.5. mplsTunnelExtReversePerfTable=0D =0D This table augments the mplsTunnelTable to provide per-tunnel packet=0D= performance information for the reverse direction of a bidirectional=0D= tunnel. It can be seen as supplementing the mplsTunnelPerfTable,=0D which augments the mplsTunnelTable.=0D =0D 7. MIB Module Interdependencies=0D =0D This section provides an overview of the relationship between the=0D MPLS-TP TE MIB module and other MPLS MIB modules.=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 8]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D The arrows in the following diagram show a 'depends on'=0D relationship. A relationship "MIB module A depends on MIB module B"=0D= means that MIB module A uses an object, object identifier, or=0D textual convention defined in MIB module B, or that MIB module A=0D contains a pointer (index or RowPointer) to an object in=0D MIB module B.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 9]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D MPLS-TC-EXT-STD-MIB=0D ^=0D |=0D |=0D +<---- MPLS-ID-STD-MIB=0D ^=0D | |=0D +<---- MPLS-TE-EXT-STD-MIB=0D | |=0D | V=0D | MPLS-TE-STD-MIB=0D | |=0D | |=0D | V=0D | MPLS-LSR-STD-MIB=0D | ^=0D | |=0D | |=0D +------MPLS-LSR-EXT-STD-MIB=0D =0D Thus:=0D =0D - All the new MPLS extension MIB modules depend on=0D MPLS-TC-EXT-STD-MIB.=0D =0D - MPLS-ID-STD-MIB contains references to objects in=0D MPLS-TE-STD-MIB [RFC3812].=0D =0D - MPLS-TE-EXT-STD-MIB contains references to objects in=0D MPLS-TE-STD-MIB [RFC3812].=0D =0D - MPLS-LSR-EXT-STD-MIB contains references to objects in=0D MPLS-LSR-STD-MIB [RFC3813].=0D =0D MPLS-TE-STD-MIB [RFC3812] is extended by MPLS-TE-EXT-STD-MIB=0D MIB module for associating the reverse direction tunnel=0D information.=0D =0D Note that the nature of the 'extends' relationship=0D is a sparse augmentation so that the entry in the=0D mplsTunnelExtTable has the same index values as the in the=0D mplsTunnelTable.=0D =0D MPLS-LSR-STD-MIB [RFC3813] is extended by MPLS-LSR-EXT-STD-MIB=0D MIB module for pointing back to the tunnel entry for easy tunnel=0D access from XC entry.=0D =0D Note that the nature of the 'extends' relationship=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 10]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D is a sparse augmentation so that the entry in the=0D mplsXCExtTable has the same index values as the in the mplsXCTable.=0D= =0D 8. Dependencies between MIB Module Tables=0D =0D The tables in MPLS-TE-EXT-STD-MIB are related as shown on the diagram=0D= below. The arrows indicate a reference from one table to another.=0D =0D mplsTunnelExtNodeConfigTable=0D ^ mplsXCExtTable=0D | | ^=0D | +---------+ |=0D | | |=0D | V V=0D mplsTunnelTable ---->mplsXCTable=0D ^=0D |=0D |=0D mplsTunnelExtTable=0D =0D An existing mplsTunnelTable uses the mplsTunnelExtNodeConfigTable=0D table to map the Global_Node_ID and/or ICC with the local number in=0D= order to accommodate in the existing tunnel table's ingress/egress=0D LSR-id.=0D =0D New mplsTunnelExtTable table provides the reverse direction LSP=0D information for the existing tunnel table in order to achieve=0D bidirectional LSPs.=0D =0D mplsXCExtTable is extended from mplsLsrXCTable to provide=0D backward reference to tunnel entry.=0D =0D 9. Example of MPLS-TP Tunnel Setup=0D In this section, we provide an example of the IP based MPLS-TP=0D bidirectional tunnel setup. This example provides the usage of=0D MPLS-TP Tunnel MIB along with the extended new MIB modules introduced=0D= in this document.=0D =0D Do note that a MPLS-TP tunnel could be setup statically as well as=0D signaled via control plane. This example considers accessing MIB=0D objects on a head-end for a static and signaling MPLS-TP tunnels.=0D Only relevant objects which are applicable for MPLS-TP tunnel are=0D illustrated here.=0D =0D In mplsTunnelExtNodeConfigTable:=0D =0D {=0D -- Non-IP Ingress LSR-Id (Index to the table)=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 11]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelExtNodeConfigLocalId =3D 1,=0D =0D mplsTunnelExtNodeConfigGlobalId =3D 1234,=0D mplsTunnelExtNodeConfigNodeId =3D 10,=0D -- Mandatory parameters needed to activate the row go here=0D mplsTunnelExtNodeConfigRowStatus =3D createAndGo (4)=0D =0D -- Non-IP Egress LSR-Id (Index to the table)=0D mplsTunnelExtNodeConfigLocalId =3D 2,=0D mplsTunnelExtNodeConfigGlobalId =3D 1234,=0D mplsTunnelExtNodeConfigNodeId =3D 20,=0D -- Mandatory parameters needed to activate the row go here=0D mplsTunnelExtNodeConfigRowStatus =3D createAndGo (4)=0D }=0D =0D This will create an entry in the mplsTunnelExtNodeConfigTable for a=0D= Global_Node_ID. A separate entry is made for both Ingress LSR=0D and Egress LSR.=0D =0D The following read-only mplsTunnelExtNodeIpMapTable table is=0D populated automatically upon creating an entry in=0D mplsTunnelExtNodeConfigTable and this table is used to retrieve=0D the local identifier for the given Global_Node_ID.=0D =0D In mplsTunnelExtNodeIpMapTable:=0D =0D {=0D -- Global_ID (Index to the table)=0D mplsTunnelExtNodeIpMapGlobalId =3D 1234,=0D -- Node Identifier (Index to the table)=0D mplsTunnelExtNodeIpMapNodeId =3D 10,=0D mplsTunnelExtNodeIpMapLocalId =3D 1=0D =0D -- Global_ID (Index to the table)=0D mplsTunnelExtNodeIpMapGlobalId =3D 1234,=0D -- Node Identifier (Index to the table)=0D mplsTunnelExtNodeIpMapNodeId =3D 20,=0D mplsTunnelExtNodeIpMapLocalId =3D 2=0D }=0D =0D 9.1. Example of MPLS-TP static co-routed bidirectional tunnel setup=0D =0D The following denotes the configured co-routed bidirectional=0D tunnel "head" entry:=0D =0D 9.1.1. mplsTunnelEntry=0D =0D In mplsTunnelTable:=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 12]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D {=0D mplsTunnelIndex =3D 1,=0D mplsTunnelInstance =3D 1,=0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Ingress LSR-Id=0D mplsTunnelIngressLSRId =3D 1,=0D =0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Egress LSR-Id=0D mplsTunnelEgressLSRId =3D 2,=0D mplsTunnelName =3D "TP co-routed bidirectional LSP",=0D= mplsTunnelDescr =3D "East to West",=0D mplsTunnelIsIf =3D true (1),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelXCPointer =3D=0D mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D mplsTunnelSignallingProto =3D none (1),=0D mplsTunnelSetupPrio =3D 0,=0D mplsTunnelHoldingPrio =3D 0,=0D mplsTunnelSessionAttributes =3D 0,=0D mplsTunnelLocalProtectInUse =3D false (0),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelResourcePointer =3D mplsTunnelResourceMaxRate.5,=0D mplsTunnelInstancePriority =3D 1,=0D mplsTunnelHopTableIndex =3D 1,=0D mplsTunnelIncludeAnyAffinity =3D 0,=0D mplsTunnelIncludeAllAffinity =3D 0,=0D mplsTunnelExcludeAnyAffinity =3D 0,=0D mplsTunnelRole =3D head (1),=0D -- Mandatory parameters needed to activate the row go here=0D mplsTunnelRowStatus =3D createAndGo (4)=0D }=0D =0D 9.1.2. mplsTunnelExtEntry=0D =0D -- An MPLS extension table=0D In mplsTunnelExtTable:=0D {=0D -- This opposite direction tunnel pointer MAY be point to 0.0=0D -- if co-routed bidirectional tunnel is managed by single tunnel=0D -- entry=0D mplsTunnelExtOppositeDirTnlPtr =3D 0.0=0D -- Set both the Ingress and Egress LocalId objects to TRUE as=0D -- this tunnel entry uses the local identifiers.=0D mplsTunnelExtIngressLSRLocalIdValid =3D true,=0D mplsTunnelExtEgressLSRLocalIdValid =3D true=0D =0D }=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 13]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D We must next create the appropriate in-segment and out-segment=0D entries. These are done in [RFC3813] using the mplsInSegmentTable and=0D= mplsOutSegmentTable.=0D =0D 9.1.3. Forward direction mplsOutSegmentEntry=0D =0D For the forward direction.=0D =0D In mplsOutSegmentTable:=0D {=0D mplsOutSegmentIndex =3D 0x0000001,=0D mplsOutSegmentInterface =3D 13, -- outgoing interface=0D mplsOutSegmentPushTopLabel =3D true(1),=0D mplsOutSegmentTopLabel =3D 22, -- outgoing label=0D =0D -- RowPointer MUST point to the first accessible column.=0D mplsOutSegmentTrafficParamPtr =3D 0.0,=0D mplsOutSegmentRowStatus =3D createAndGo (4)=0D }=0D =0D 9.1.4. Reverse direction mplsInSegmentEntry=0D =0D For the reverse direction.=0D =0D In mplsInSegmentTable:=0D {=0D mplsInSegmentIndex =3D 0x0000001=0D mplsInSegmentLabel =3D 21, -- incoming label=0D mplsInSegmentNPop =3D 1,=0D mplsInSegmentInterface =3D 13, -- incoming interface=0D =0D -- RowPointer MUST point to the first accessible column.=0D mplsInSegmentTrafficParamPtr =3D 0.0,=0D mplsInSegmentRowStatus =3D createAndGo (4)=0D }=0D =0D Next, two cross-connect entries are created in the mplsXCTable of the=0D= MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created=0D segments together.=0D =0D 9.1.5. Forward direction mplsXCEntry=0D =0D In mplsXCTable:=0D {=0D mplsXCIndex =3D 0x01,=0D mplsXCInSegmentIndex =3D 0x00000000,=0D mplsXCOutSegmentIndex =3D 0x00000001,=0D mplsXCLspId =3D 0x0102 -- unique ID=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 14]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D -- only a single outgoing label=0D mplsXCLabelStackIndex =3D 0x00,=0D mplsXCRowStatus =3D createAndGo(4)=0D =0D }=0D =0D 9.1.6. Reverse direction mplsXCEntry=0D =0D In mplsXCTable:=0D {=0D mplsXCIndex =3D 0x01,=0D mplsXCInSegmentIndex =3D 0x00000001,=0D mplsXCOutSegmentIndex =3D 0x00000000,=0D mplsXCLspId =3D 0x0102 -- unique ID=0D -- only a single outgoing label=0D mplsXCLabelStackIndex =3D 0x00,=0D mplsXCRowStatus =3D createAndGo(4)=0D }=0D =0D This table entry is extended by entry in the=0D mplsXCExtTable. Note that the nature of the 'extends'=0D relationship is a sparse augmentation so that the entry in the=0D mplsXCExtTable has the same index values as the entry in=0D the mplsXCTable.=0D =0D 9.1.7. Forward direction mplsXCExtEntry=0D =0D In mplsXCExtTable (0x01, 0x00000000, 0x00000001)=0D {=0D -- Back pointer from XC table to Tunnel table=0D mplsXCExtTunnelPointer =3D mplsTunnelName.1.1.1.2=0D mplsXCExtOppositeDirXCPtr =3D=0D mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0=0D }=0D =0D 9.1.8. Reverse direction mplsXCExtEntry=0D =0D Next for the reverse direction:=0D =0D In mplsXCExtTable (0x01, 0x00000001, 0x00000000)=0D {=0D -- Back pointer from XC table to Tunnel table=0D mplsXCExtTunnelPointer =3D mplsTunnelName.1.1.1.2=0D mplsXCExtOppositeDirXCPtr =3D=0D mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1=0D }=0D =0D 9.1.9. mplsTunnelExtReversePerfTable=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 15]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D The mplsTunnelExtReversePerfTable SHOULD be populated incase=0D the single tunnel entry is used for co-routed bidirectional tunnel=0D setup. The mplsTunnelPerfTable will have the forward direction=0D LSP performance counters and mplsTunnelExtReversePerfTable will have=0D= the reverse direction LSP performance counters.=0D =0D 9.2. Example of MPLS-TP static associated bidirectional tunnel setup=0D =0D The MPLS-TP associated bidirectional tunnel has two different=0D direction tunnels[Forward and Reverse LSPs] and these are=0D associated together using mplsTunnelExtTable. Two different=0D tunnel entries for both forward and reverse direction MAY be used=0D for co-routed bidirectional tunnel as well.=0D =0D The following denotes the configured associated bidirectional forward=0D= tunnel "head" entry:=0D =0D 9.2.1. Forward direction mplsTunnelEntry=0D =0D In mplsTunnelTable:=0D =0D {=0D mplsTunnelIndex =3D 1,=0D mplsTunnelInstance =3D 1,=0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Ingress LSR-Id=0D mplsTunnelIngressLSRId =3D 1,=0D =0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Egress LSR-Id=0D mplsTunnelEgressLSRId =3D 2,=0D mplsTunnelName =3D "TP associated bi-directional=0D forward LSP",=0D mplsTunnelDescr =3D "East to West",=0D mplsTunnelIsIf =3D true (1),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelXCPointer =3D=0D mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D mplsTunnelSignallingProto =3D none (1),=0D mplsTunnelSetupPrio =3D 0,=0D mplsTunnelHoldingPrio =3D 0,=0D mplsTunnelSessionAttributes =3D 0,=0D mplsTunnelLocalProtectInUse =3D false (0),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelResourcePointer =3D mplsTunnelResourceMaxRate.5,=0D mplsTunnelInstancePriority =3D 1,=0D mplsTunnelHopTableIndex =3D 1,=0D mplsTunnelIncludeAnyAffinity =3D 0,=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 16]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelIncludeAllAffinity =3D 0,=0D mplsTunnelExcludeAnyAffinity =3D 0,=0D mplsTunnelRole =3D head (1),=0D -- Mandatory parameters needed to activate the row go here=0D mplsTunnelRowStatus =3D createAndGo (4)=0D }=0D =0D 9.2.2. Forward direction mplsTunnelExtEntry=0D =0D For Associated bidirectional forward LSP,=0D In mplsTunnelExtTable:=0D {=0D mplsTunnelExtOppositeDirPtr =3D mplsTunnelName.2.1.2.1=0D -- Set both the Ingress and Egress LocalId objects to TRUE as=0D -- this tunnel entry uses the local identifiers.=0D mplsTunnelExtIngressLSRLocalIdValid =3D true,=0D mplsTunnelExtEgressLSRLocalIdValid =3D true=0D }=0D =0D 9.2.3. Forward direction mplsOutSegmentTable=0D =0D For the forward direction.=0D =0D In mplsOutSegmentTable:=0D {=0D mplsOutSegmentIndex =3D 0x0000001,=0D mplsOutSegmentInterface =3D 13, -- outgoing interface=0D mplsOutSegmentPushTopLabel =3D true(1),=0D mplsOutSegmentTopLabel =3D 22, -- outgoing label=0D =0D -- RowPointer MUST point to the first accessible column.=0D mplsOutSegmentTrafficParamPtr =3D 0.0,=0D mplsOutSegmentRowStatus =3D createAndGo (4)=0D }=0D =0D 9.2.4. Forward direction mplsXCEntry=0D =0D In mplsXCTable:=0D {=0D mplsXCIndex =3D 0x01,=0D mplsXCInSegmentIndex =3D 0x00000000,=0D mplsXCOutSegmentIndex =3D 0x00000001,=0D mplsXCLspId =3D 0x0102 -- unique ID=0D -- only a single outgoing label=0D mplsXCLabelStackIndex =3D 0x00,=0D mplsXCRowStatus =3D createAndGo(4)=0D =0D }=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 17]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 9.2.5. Forward direction mplsXCExtEntry=0D =0D In mplsXCExtTable (0x01, 0x00000000, 0x00000001)=0D {=0D -- Back pointer from XC table to Tunnel table=0D mplsXCExtTunnelPointer =3D mplsTunnelName.1.1.1.2=0D mplsXCExtOppositeDirXCPtr =3D=0D mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0=0D }=0D =0D 9.2.6. Reverse direction mplsTunnelEntry=0D =0D The following denotes the configured associated bidirectional reverse=0D= tunnel "tail" entry:=0D =0D In mplsTunnelTable:=0D =0D {=0D mplsTunnelIndex =3D 2,=0D mplsTunnelInstance =3D 1,=0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Ingress LSR-Id=0D mplsTunnelIngressLSRId =3D 2,=0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Egress LSR-Id=0D mplsTunnelEgressLSRId =3D 1,=0D mplsTunnelName =3D "TP associated bi-directional=0D reverse LSP",=0D mplsTunnelDescr =3D "West to East",=0D mplsTunnelIsIf =3D true (1),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelXCPointer =3D=0D mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0,=0D mplsTunnelSignallingProto =3D none (1),=0D mplsTunnelSetupPrio =3D 0,=0D mplsTunnelHoldingPrio =3D 0,=0D mplsTunnelSessionAttributes =3D 0,=0D mplsTunnelLocalProtectInUse =3D false (0),=0D =0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelResourcePointer =3D mplsTunnelResourceMaxRate.5,=0D mplsTunnelInstancePriority =3D 1,=0D mplsTunnelHopTableIndex =3D 1,=0D mplsTunnelIncludeAnyAffinity =3D 0,=0D mplsTunnelIncludeAllAffinity =3D 0,=0D mplsTunnelExcludeAnyAffinity =3D 0,=0D mplsTunnelRole =3D head (1),=0D -- Mandatory parameters needed to activate the row go here=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 18]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelRowStatus =3D createAndGo (4)=0D }=0D =0D 9.2.7. Reverse direction mplsTunnelExtEntry=0D =0D For Associated bidirectional reverse LSP,=0D In mplsTunnelExtTable:=0D {=0D mplsTunnelExtOppositeDirPtr =3D mplsTunnelName.1.1.1.2=0D -- Set both the Ingress and Egress LocalId objects to TRUE as=0D -- this tunnel entry uses the local identifiers.=0D mplsTunnelExtIngressLSRLocalIdValid =3D true,=0D mplsTunnelExtEgressLSRLocalIdValid =3D true=0D }=0D =0D 9.2.8. Reverse direction mplsInSegmentEntry=0D =0D We must next create the appropriate in-segment and out-segment=0D entries. These are done in [RFC3813] using the mplsInSegmentTable and=0D= mplsOutSegmentTable.=0D =0D In mplsInSegmentTable:=0D {=0D mplsInSegmentIndex =3D 0x0000001=0D mplsInSegmentLabel =3D 21, -- incoming label=0D mplsInSegmentNPop =3D 1,=0D mplsInSegmentInterface =3D 13, -- incoming interface=0D =0D -- RowPointer MUST point to the first accessible column.=0D mplsInSegmentTrafficParamPtr =3D 0.0,=0D mplsInSegmentRowStatus =3D createAndGo (4)=0D }=0D =0D Next, two cross-connect entries are created in the mplsXCTable of the=0D= MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created=0D segments together.=0D =0D 9.2.9. Reverse direction mplsXCEntry=0D =0D =0D In mplsXCTable:=0D {=0D mplsXCIndex =3D 0x01,=0D mplsXCInSegmentIndex =3D 0x00000001,=0D mplsXCOutSegmentIndex =3D 0x00000000,=0D mplsXCLspId =3D 0x0102 -- unique ID=0D -- only a single outgoing label=0D mplsXCLabelStackIndex =3D 0x00,=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 19]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsXCRowStatus =3D createAndGo(4)=0D }=0D =0D This table entry is extended by entry in the=0D mplsXCExtTable. Note that the nature of the 'extends'=0D relationship is a sparse augmentation so that the entry in the=0D mplsXCExtTable has the same index values as the entry in=0D the mplsXCTable.=0D =0D 9.2.10. Reverse direction mplsXCExtEntry=0D =0D Next for the reverse direction:=0D =0D In mplsXCExtTable (0x01, 0x00000001, 0x00000000)=0D {=0D -- Back pointer from XC table to Tunnel table=0D mplsXCExtTunnelPointer =3D mplsTunnelName.2.1.2.1=0D mplsXCExtOppositeDirXCPtr =3D=0D mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1=0D }=0D =0D 9.3. Example of MPLS-TP signaling co-routed bidirectional tunnel setup=0D= =0D The following denotes the configured co-routed bidirectional=0D tunnel "head" entry and in intermediate and tail-end nodes,=0D the tunnel table and its associated tables are created=0D by the local management subsystem (e.g. agent) when the MPLS TP=0D tunnel is signaled successfully. Refer [RFC3812] and [RFC4802]=0D for signaling tunnel table configuration examples.=0D =0D 9.3.1. mplsTunnelEntry=0D =0D In mplsTunnelTable:=0D =0D {=0D mplsTunnelIndex =3D 1,=0D mplsTunnelInstance =3D 0,=0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Ingress LSR-Id, for the intermediate and tail-end nodes,=0D -- the local management entity is expected to pick a first available=0D= -- local identifier which is not used in mplsTunnelTable.=0D mplsTunnelIngressLSRId =3D 1,=0D =0D -- Local map number created in mplsTunnelExtNodeConfigTable for=0D -- Egress LSR-Id=0D mplsTunnelEgressLSRId =3D 2,=0D mplsTunnelName =3D "TP co-routed bidirectional LSP",=0D= mplsTunnelDescr =3D "East to West",=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 20]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelIsIf =3D true (1),=0D =0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelXCPointer =3D=0D mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D mplsTunnelSignallingProto =3D none (1),=0D mplsTunnelSetupPrio =3D 0,=0D mplsTunnelHoldingPrio =3D 0,=0D mplsTunnelSessionAttributes =3D 0,=0D mplsTunnelLocalProtectInUse =3D false (0),=0D -- RowPointer MUST point to the first accessible column=0D mplsTunnelResourcePointer =3D mplsTunnelResourceMaxRate.5,=0D mplsTunnelInstancePriority =3D 1,=0D mplsTunnelHopTableIndex =3D 1,=0D mplsTunnelIncludeAnyAffinity =3D 0,=0D mplsTunnelIncludeAllAffinity =3D 0,=0D mplsTunnelExcludeAnyAffinity =3D 0,=0D mplsTunnelRole =3D head (1),=0D -- Mandatory parameters needed to activate the row go here=0D mplsTunnelRowStatus =3D createAndGo (4)=0D }=0D =0D 9.3.2. mplsTunnelExtEntry=0D =0D -- An MPLS extension table=0D In mplsTunnelExtTable:=0D {=0D -- This opposite direction tunnel pointer MAY be point to 0.0=0D -- if co-routed bidirectional tunnel is managed by single tunnel=0D -- entry=0D mplsTunnelExtOppositeDirTnlPtr =3D 0.0=0D -- Set both the Ingress and Egress LocalId objects to TRUE as=0D -- this tunnel entry uses the local identifiers.=0D mplsTunnelExtIngressLSRLocalIdValid =3D true,=0D mplsTunnelExtEgressLSRLocalIdValid =3D true=0D }=0D =0D We must next create the appropriate in-segment and out-segment=0D entries. These are done in [RFC3813] using the mplsInSegmentTable and=0D= mplsOutSegmentTable.=0D =0D 9.3.3. Forward direction mplsOutSegmentEntry=0D =0D The forward direction mplsOutSegmentTable will be populated=0D automatically based on the information received from the signaling=0D protocol.=0D =0D 9.3.4. Reverse direction mplsInSegmentEntry=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 21]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D The reverse direction mplsOutSegmentTable will be populated=0D automatically based on the information received from the signaling=0D protocol.=0D =0D Next, two cross-connect entries are created in the mplsXCTable of the=0D= MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created=0D segments together.=0D =0D 9.3.5. Forward direction mplsXCEntry=0D =0D The forward direction mplsXCEntry will be populated as soon as the=0D forward path label information is available.=0D =0D 9.3.6. Reverse direction mplsXCEntry=0D =0D The reverse direction mplsXCEntry will be populated as soon as the=0D reverse path label information is available.=0D =0D This table entry is extended by entry in the mplsXCExtTable. Note=0D that the nature of the 'extends' relationship is a sparse=0D augmentation so that the entry in the mplsXCExtTable has the same=0D index values as the entry in the mplsXCTable.=0D =0D 9.3.7. Forward direction mplsXCExtEntry=0D =0D Once the forward path information is negotiated using signaling=0D protocol, the forward direction mplsXCExtEntry will be created for=0D associating the opposite direction XC entry and tunnel table entry.=0D= =0D 9.3.8. Reverse direction mplsXCExtEntry=0D =0D Once the reverse path information is negotiated using signaling=0D protocol, the reverse direction mplsXCExtEntry will be created for=0D associating the opposite direction XC entry and tunnel table entry.=0D= =0D 9.3.9. mplsTunnelExtReversePerfTable=0D =0D The mplsTunnelExtReversePerfTable SHOULD be populated incase the=0D single tunnel entry is used for co-routed bidirectional tunnel setup.=0D= The mplsTunnelPerfTable will have the forward direction LSP=0D performance counters and mplsTunnelExtReversePerfTable will have the=0D= reverse direction LSP performance counters.=0D =0D 10. MPLS Textual Convention Extension MIB definitions=0D MPLS-TC-EXT-STD-MIB DEFINITIONS ::=3D BEGIN=0D =0D IMPORTS=0D MODULE-IDENTITY, Unsigned32=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 22]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D FROM SNMPv2-SMI -- [RFC2578]=0D =0D TEXTUAL-CONVENTION=0D FROM SNMPv2-TC -- [RFC2579]=0D =0D mplsStdMIB=0D FROM MPLS-TC-STD-MIB -- [RFC3811]=0D =0D ;=0D =0D mplsTcExtStdMIB MODULE-IDENTITY=0D =0D LAST-UPDATED=0D "201301140000Z" -- January 14, 2013=0D ORGANIZATION=0D "Multiprotocol Label Switching (MPLS) Working Group"=0D CONTACT-INFO=0D "=0D Venkatesan Mahalingam=0D Dell Inc,=0D 350 Holger way, San Jose, CA, USA=0D Email: venkat.mahalingams@gmail.com=0D =0D Kannan KV Sampath=0D Redeem,=0D India=0D Email: kannankvs@gmail.com=0D =0D Sam Aldrin=0D Huawei Technologies=0D 2330 Central Express Way,=0D Santa Clara, CA 95051, USA=0D Email: aldrin.ietf@gmail.com=0D =0D Thomas D. Nadeau=0D Juniper Networks=0D 10 Technology Park Drive,=0D Westford, MA 01886=0D Email: tnadeau@juniper.net=0D "=0D DESCRIPTION=0D "Copyright (c) 2013 IETF Trust and the persons identified=0D as the document authors. All rights reserved.=0D =0D This MIB module contains Textual Conventions for=0D MPLS based transport networks."=0D =0D -- Revision history.=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 23]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D REVISION=0D =0D "201301140000Z" -- January 14, 2013=0D DESCRIPTION=0D "MPLS Textual Convention Extensions"=0D =0D ::=3D { mplsStdMIB xxx } -- xxx to be replaced with correct value=0D= =0D MplsGlobalId ::=3D TEXTUAL-CONVENTION=0D =0D STATUS current=0D DESCRIPTION=0D "This object contains the Textual Convention of IP based=0D operator unique identifier (Global_ID), the Global_ID can=0D contain the 2-octet or 4-octet value of the operator's=0D Autonomous System Number (ASN).=0D =0D It is expected that the Global_ID will be derived from=0D the globally unique ASN of the autonomous system hosting=0D the PEs containing the actual AIIs.=0D The presence of a Global_ID based on the operator's=0D ASN ensures that the AII will be globally unique.=0D =0D When the Global_ID is derived from a 2-octet AS number,=0D =0D =0D =0D the two high-order octets of this 4-octet identifier=0D MUST be set to zero.=0D Further ASN 0 is reserved. A Global_ID of zero means=0D that no Global_ID is present. Note that a Global_ID of=0D zero is limited to entities contained within a single=0D operator and MUST NOT be used across an NNI.=0D A non-zero Global_ID MUST be derived from an ASN owned by=0D the operator."=0D REFERENCE=0D "MPLS Transport Profile (MPLS-TP) Identifiers, [RFC6370] =0D Section 3 Uniquely Identifying an Operator - the Global_ID"=0D= SYNTAX OCTET STRING (SIZE (4))=0D =0D MplsNodeId ::=3D TEXTUAL-CONVENTION=0D DISPLAY-HINT "d"=0D STATUS current=0D DESCRIPTION=0D "The Node_ID is assigned within the scope of the Global_ID.=0D The value 0(or 0.0.0.0 in dotted decimal notation) is=0D reserved and MUST NOT be used.=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 24]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D When IPv4 addresses are in use, the value of this object=0D can be derived from the LSR's IPv4 loop back address.=0D When IPv6 addresses are in use, the value of this object=0D can be a 32-bit value unique within the scope of=0D a Global_ID.=0D =0D Note that, when IP reach ability is not needed, the 32-bit=0D Node_ID is not required to have any association=0D with the IPv4 address space."=0D REFERENCE=0D "MPLS Transport Profile (MPLS-TP) Identifiers, [RFC6370], =0D Section 4. Node and Interface Identifiers"=0D SYNTAX Unsigned32 -- the default range: (0..4294967295)=0D =0D MplsIccId ::=3D TEXTUAL-CONVENTION=0D STATUS current=0D DESCRIPTION=0D "The ICC is a string of one to six characters, each=0D character being either alphabetic (i.e. A-Z) or=0D numeric (i.e. 0-9) characters.=0D Alphabetic characters in the ICC SHOULD be represented=0D with upper case letters."=0D REFERENCE=0D "MPLS-TP Identifiers Following ITU-T Conventions, =0D [I-D.ietf-mpls-tp-itu-t-identifiers], Section 3. =0D Uniquely Identifying an Operator - the ICC_Operator_ID"=0D SYNTAX OCTET STRING (SIZE (1..6))=0D =0D -- MPLS-TC-EXT-STD-MIB module ends=0D END=0D =0D 11. MPLS Identifier MIB definitions=0D =0D MPLS-ID-STD-MIB DEFINITIONS ::=3D BEGIN=0D =0D IMPORTS=0D MODULE-IDENTITY, OBJECT-TYPE=0D FROM SNMPv2-SMI -- [RFC2578]=0D MODULE-COMPLIANCE, OBJECT-GROUP=0D FROM SNMPv2-CONF -- [RFC2580]=0D mplsStdMIB=0D FROM MPLS-TC-STD-MIB -- [RFC3811]=0D MplsGlobalId, MplsIccId, MplsNodeId=0D FROM MPLS-TC-EXT-STD-MIB=0D ;=0D =0D mplsIdStdMIB MODULE-IDENTITY=0D LAST-UPDATED=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 25]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D "201301140000Z" -- January 14, 2013=0D ORGANIZATION=0D "Multiprotocol Label Switching (MPLS) Working Group"=0D =0D CONTACT-INFO=0D "=0D Venkatesan Mahalingam=0D Dell Inc,=0D 350 Holger way, San Jose, CA, USA=0D Email: venkat.mahalingams@gmail.com=0D =0D Kannan KV Sampath=0D =0D Redeem,=0D India=0D Email: kannankvs@gmail.com=0D =0D =0D Sam Aldrin=0D Huawei Technologies=0D 2330 Central Express Way,=0D Santa Clara, CA 95051, USA=0D Email: aldrin.ietf@gmail.com=0D =0D Thomas D. Nadeau=0D Juniper Networks=0D 10 Technology Park Drive,=0D Westford, MA 01886=0D Email: tnadeau@juniper.net=0D "=0D DESCRIPTION=0D "Copyright (c) 2013 IETF Trust and the persons identified=0D as the document authors. All rights reserved.=0D =0D This MIB module contains generic object definitions for=0D MPLS Traffic Engineering in transport networks."=0D =0D -- Revision history.=0D =0D REVISION=0D "201301140000Z" -- January 14, 2013=0D DESCRIPTION=0D "This MIB modules defines the MIB objects for MPLS-TP=0D identifiers"=0D =0D ::=3D { mplsStdMIB xxx } -- xxx to be replaced with correct value=0D= =0D -- Notifications=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 26]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsIdNotifications OBJECT IDENTIFIER ::=3D { mplsIdStdMIB 0 }=0D -- tables, scalars=0D mplsIdObjects OBJECT IDENTIFIER ::=3D { mplsIdStdMIB 1 }=0D -- conformance=0D mplsIdConformance OBJECT IDENTIFIER ::=3D { mplsIdStdMIB 2 }=0D =0D =0D -- MPLS common objects=0D =0D mplsIdGlobalId OBJECT-TYPE=0D SYNTAX MplsGlobalId=0D MAX-ACCESS read-write=0D STATUS current=0D DESCRIPTION=0D =0D "This object allows the operator to assign a unique=0D operator identifier also called MPLS-TP Global_ID."=0D ::=3D { mplsIdObjects 1 }=0D =0D mplsIdIcc OBJECT-TYPE=0D SYNTAX MplsIccId=0D MAX-ACCESS read-write=0D STATUS current=0D DESCRIPTION=0D "This object allows the operator or service provider to=0D assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a=0D network."=0D ::=3D { mplsIdObjects 2 }=0D =0D mplsIdNodeId OBJECT-TYPE=0D SYNTAX MplsNodeId=0D MAX-ACCESS read-write=0D STATUS current=0D DESCRIPTION=0D "This object allows the operator or service provider to=0D assign a unique MPLS-TP Node_ID.=0D =0D The Node_ID is assigned within the scope of=0D the Global_ID."=0D ::=3D { mplsIdObjects 3 }=0D =0D -- Module compliance.=0D =0D mplsIdGroups=0D OBJECT IDENTIFIER ::=3D { mplsIdConformance 1 }=0D =0D =0D mplsIdCompliances=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 27]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D OBJECT IDENTIFIER ::=3D { mplsIdConformance 2 }=0D =0D -- Compliance requirement for fully compliant implementations.=0D =0D mplsIdModuleFullCompliance MODULE-COMPLIANCE=0D STATUS current=0D DESCRIPTION=0D "Compliance statement for agents that provide full=0D support the MPLS-ID-STD-MIB module."=0D =0D MODULE -- this module=0D =0D =0D -- The mandatory group has to be implemented by all=0D -- LSRs that originate/terminate MPLS-TP paths.=0D =0D MANDATORY-GROUPS {=0D mplsIdScalarGroup=0D }=0D =0D ::=3D { mplsIdCompliances 1 }=0D =0D -- Compliance requirement for read-only implementations.=0D =0D mplsIdModuleReadOnlyCompliance MODULE-COMPLIANCE=0D STATUS current=0D DESCRIPTION=0D "Compliance statement for agents that provide full=0D support the MPLS-ID-STD-MIB module."=0D =0D MODULE -- this module=0D =0D -- The mandatory group has to be implemented by all=0D -- LSRs that originate/terminate MPLS-TP paths.=0D =0D MANDATORY-GROUPS {=0D mplsIdScalarGroup=0D }=0D =0D ::=3D { mplsIdCompliances 2 }=0D =0D -- Units of conformance.=0D =0D mplsIdScalarGroup OBJECT-GROUP=0D OBJECTS { mplsIdGlobalId,=0D mplsIdNodeId,=0D mplsIdIcc=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 28]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D }=0D STATUS current=0D DESCRIPTION=0D "Scalar object needed to implement MPLS TP path."=0D ::=3D { mplsIdGroups 1 }=0D =0D -- MPLS-ID-STD-MIB module ends=0D END=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 29]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 12. MPLS LSR Extension MIB definitions=0D =0D MPLS-LSR-EXT-STD-MIB DEFINITIONS ::=3D BEGIN=0D =0D IMPORTS=0D MODULE-IDENTITY, OBJECT-TYPE=0D FROM SNMPv2-SMI -- [RFC2578]=0D MODULE-COMPLIANCE, OBJECT-GROUP=0D FROM SNMPv2-CONF -- [RFC2580]=0D mplsStdMIB=0D FROM MPLS-TC-STD-MIB -- [RFC3811]=0D RowPointer=0D FROM SNMPv2-TC -- [RFC2579]=0D mplsXCIndex, mplsXCInSegmentIndex, mplsXCOutSegmentIndex,=0D mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup, =0D mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup=0D FROM MPLS-LSR-STD-MIB; -- [RFC3813]=0D =0D mplsLsrExtStdMIB MODULE-IDENTITY=0D LAST-UPDATED=0D "201301140000Z" -- January 14, 2013=0D ORGANIZATION=0D "Multiprotocol Label Switching (MPLS) Working Group"=0D CONTACT-INFO=0D "=0D Venkatesan Mahalingam=0D Dell Inc,=0D 350 Holger way, San Jose, CA, USA=0D Email: venkat.mahalingams@gmail.com=0D =0D Kannan KV Sampath=0D Redeem,=0D India=0D Email: kannankvs@gmail.com=0D =0D Sam Aldrin=0D Huawei Technologies=0D 2330 Central Express Way,=0D Santa Clara, CA 95051, USA=0D =0D Email: aldrin.ietf@gmail.com=0D =0D Thomas D. Nadeau=0D Juniper Networks=0D 10 Technology Park Drive, Westford, MA 01886=0D Email: tnadeau@juniper.net=0D "=0D DESCRIPTION=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 30]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D "Copyright (c) 2013 IETF Trust and the persons identified=0D as the document authors. All rights reserved.=0D =0D This MIB module contains generic object definitions for=0D =0D =0D MPLS LSR in transport networks."=0D =0D =0D -- Revision history.=0D =0D REVISION=0D "201301140000Z" -- January 14, 2013=0D DESCRIPTION=0D "MPLS LSR specific MIB objects extension"=0D =0D ::=3D { mplsStdMIB xxx } -- xxx to be replaced with correct value=0D= =0D -- Notifications=0D mplsLsrExtNotifications OBJECT IDENTIFIER=0D ::=3D { mplsLsrExtStdMIB 0 }=0D -- tables, scalars=0D mplsLsrExtObjects OBJECT IDENTIFIER=0D ::=3D { mplsLsrExtStdMIB 1 }=0D -- conformance=0D mplsLsrExtConformance OBJECT IDENTIFIER=0D ::=3D { mplsLsrExtStdMIB 2 }=0D =0D -- MPLS LSR common objects=0D mplsXCExtTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsXCExtEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This table sparse augments the mplsXCTable of=0D MPLS-LSR-STD-MIB [RFC3813] to provide MPLS-TP specific=0D information about associated tunnel information"=0D REFERENCE=0D "1. Multiprotocol Label Switching (MPLS) Label Switching=0D Router (LSR) Management Information Base (MIB), RFC 3813,=0D Section 5.7. mplsXCTable"=0D ::=3D { mplsLsrExtObjects 1 }=0D =0D mplsXCExtEntry OBJECT-TYPE=0D SYNTAX MplsXCExtEntry=0D MAX-ACCESS not-accessible=0D =0D STATUS current=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 31]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D DESCRIPTION=0D =0D "An entry in this table extends the cross connect=0D information represented by an entry in=0D the mplsXCTable in MPLS-LSR-STD-MIB [RFC3813] through=0D a sparse augmentation. An entry can be created by=0D a network operator via SNMP SET commands, or in=0D response to signaling protocol events."=0D REFERENCE=0D "1. Multiprotocol Label Switching (MPLS) Label Switching=0D Router (LSR) Management Information Base (MIB), RFC 3813,=0D Section 10. mplsXCTable"=0D =0D =0D INDEX { mplsXCIndex, mplsXCInSegmentIndex,=0D mplsXCOutSegmentIndex }=0D ::=3D { mplsXCExtTable 1 }=0D =0D MplsXCExtEntry ::=3D SEQUENCE {=0D mplsXCExtTunnelPointer RowPointer,=0D mplsXCExtOppositeDirXCPtr RowPointer=0D }=0D =0D mplsXCExtTunnelPointer OBJECT-TYPE=0D SYNTAX RowPointer=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "This read-only object indicates the back pointer to=0D the tunnel entry segment."=0D REFERENCE=0D "1. Multiprotocol Label Switching (MPLS) Label Switching=0D Router (LSR) Management Information Base (MIB), RFC 3813,=0D Section 10. mplsXCTable"=0D ::=3D { mplsXCExtEntry 1 }=0D =0D mplsXCExtOppositeDirXCPtr OBJECT-TYPE=0D SYNTAX RowPointer=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object indicates the pointer to the opposite=0D direction XC entry. This object cannot be modified if=0D mplsXCRowStatus for the corresponding entry in the=0D mplsXCTable is active(1)."=0D REFERENCE=0D "1. Multiprotocol Label Switching (MPLS) Label Switching=0D Router (LSR) Management Information Base (MIB), RFC 3813,=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 32]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D Section 10. mplsXCTable"=0D ::=3D { mplsXCExtEntry 2 }=0D =0D mplsLsrExtGroups=0D OBJECT IDENTIFIER ::=3D { mplsLsrExtConformance 1 }=0D =0D mplsLsrExtCompliances=0D OBJECT IDENTIFIER ::=3D { mplsLsrExtConformance 2 }=0D =0D -- Compliance requirement for fully compliant implementations.=0D =0D mplsLsrExtModuleFullCompliance MODULE-COMPLIANCE=0D STATUS current=0D DESCRIPTION=0D "Compliance statement for agents that provide full support=0D for MPLS-LSR-EXT-STD-MIB.=0D The mandatory group has to be implemented by all LSRs=0D that originate, terminate, or act as transit for=0D TE-LSPs/tunnels.=0D In addition, depending on the type of tunnels supported,=0D other groups become mandatory as explained below."=0D =0D MODULE MPLS-LSR-STD-MIB -- The MPLS-LSR-STD-MIB, RFC3813=0D =0D MANDATORY-GROUPS {=0D mplsInSegmentGroup,=0D mplsOutSegmentGroup,=0D mplsXCGroup,=0D mplsPerfGroup,=0D mplsLsrNotificationGroup=0D }=0D =0D MODULE -- this module=0D =0D =0D =0D =0D MANDATORY-GROUPS {=0D mplsXCExtGroup=0D }=0D =0D ::=3D { mplsLsrExtCompliances 1 }=0D =0D -- Compliance requirement for implementations that provide=0D -- read-only access.=0D =0D mplsLsrExtModuleReadOnlyCompliance MODULE-COMPLIANCE=0D STATUS current=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 33]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D DESCRIPTION=0D "Compliance requirement for implementations that only=0D provide read-only support for MPLS-LSR-EXT-STD-MIB.=0D Such devices can then be monitored but cannot be=0D configured using this MIB module."=0D =0D =0D MODULE MPLS-LSR-STD-MIB=0D =0D MANDATORY-GROUPS {=0D mplsInterfaceGroup,=0D mplsInSegmentGroup,=0D mplsOutSegmentGroup,=0D mplsXCGroup,=0D mplsPerfGroup=0D }=0D =0D MODULE -- this module=0D =0D MANDATORY-GROUPS {=0D mplsXCExtGroup=0D }=0D =0D OBJECT mplsXCExtTunnelPointer=0D SYNTAX RowPointer=0D MIN-ACCESS read-only=0D DESCRIPTION=0D "The only valid value for Tunnel Pointer is =0D mplsTunnelTable entry."=0D =0D OBJECT mplsXCExtOppositeDirXCPtr=0D SYNTAX RowPointer=0D MIN-ACCESS read-only=0D DESCRIPTION=0D "The only valid value for XC Pointer is =0D mplsXCTable entry."=0D =0D ::=3D { mplsLsrExtCompliances 2 }=0D =0D mplsXCExtGroup OBJECT-GROUP=0D OBJECTS {=0D mplsXCExtTunnelPointer,=0D mplsXCExtOppositeDirXCPtr=0D }=0D STATUS current=0D DESCRIPTION=0D "This object should be supported in order to access=0D the tunnel entry from XC entry."=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 34]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D ::=3D { mplsLsrExtGroups 1 }=0D =0D -- MPLS-LSR-EXT-STD-MIB module ends=0D END=0D =0D =0D 13. MPLS Tunnel Extension MIB definitions=0D =0D MPLS-TE-EXT-STD-MIB DEFINITIONS ::=3D BEGIN=0D =0D IMPORTS=0D MODULE-IDENTITY, OBJECT-TYPE, Counter32,=0D Counter64, zeroDotZero=0D =0D FROM SNMPv2-SMI -- [RFC2578]=0D MODULE-COMPLIANCE, OBJECT-GROUP=0D FROM SNMPv2-CONF -- [RFC2580]=0D TruthValue, RowStatus, RowPointer, StorageType=0D FROM SNMPv2-TC -- [RFC2579]=0D MplsGlobalId, MplsNodeId, MplsIccId=0D FROM MPLS-TC-EXT-STD-MIB=0D mplsStdMIB, MplsTunnelIndex, MplsTunnelInstanceIndex,=0D MplsExtendedTunnelId=0D FROM MPLS-TC-STD-MIB -- [RFC3811]=0D mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId,=0D mplsTunnelEgressLSRId=0D FROM MPLS-TE-STD-MIB -- [RFC3812]=0D ;=0D =0D mplsTeExtStdMIB MODULE-IDENTITY=0D LAST-UPDATED=0D "201301140000Z" -- January 14, 2013=0D ORGANIZATION=0D "Multiprotocol Label Switching (MPLS) Working Group"=0D CONTACT-INFO=0D "=0D Venkatesan Mahalingam=0D Dell Inc,=0D 350 Holger way, San Jose, CA, USA=0D Email: venkat.mahalingams@gmail.com=0D =0D Kannan KV Sampath=0D Redeem,=0D India=0D Email: kannankvs@gmail.com=0D =0D Sam Aldrin=0D Huawei Technologies=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 35]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 2330 Central Express Way,=0D Santa Clara, CA 95051, USA=0D Email: aldrin.ietf@gmail.com=0D =0D Thomas D. Nadeau=0D Juniper Networks=0D 10 Technology Park Drive, Westford, MA 01886=0D Email: tnadeau@juniper.net=0D "=0D DESCRIPTION=0D "Copyright (c) 2013 IETF Trust and the persons identified=0D as the document authors. All rights reserved.=0D =0D This MIB module contains generic object definitions for=0D MPLS Traffic Engineering in transport networks."=0D =0D =0D -- Revision history.=0D =0D REVISION=0D "201301140000Z" -- January 14, 2013=0D =0D DESCRIPTION=0D "MPLS TE MIB objects extension"=0D =0D ::=3D { mplsStdMIB xxx } -- xxx to be replaced=0D -- with correct value=0D =0D -- Top level components of this MIB module.=0D =0D -- Notifications=0D mplsTeExtNotifications OBJECT IDENTIFIER=0D ::=3D { mplsTeExtStdMIB 0 }=0D -- tables, scalars=0D mplsTeExtObjects OBJECT IDENTIFIER=0D ::=3D { mplsTeExtStdMIB 1 }=0D -- conformance=0D mplsTeExtConformance OBJECT IDENTIFIER=0D ::=3D { mplsTeExtStdMIB 2 }=0D =0D -- Start of MPLS Transport Profile Node configuration table=0D mplsTunnelExtNodeConfigTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsTunnelExtNodeConfigEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This table allows the operator to map a node or=0D LSR Identifier (IP compatible [Global_Node_ID] or ICC)=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 36]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D with a local identifier.=0D =0D =0D This table is created to reuse the existing=0D mplsTunnelTable for MPLS based transport network=0D tunnels also.=0D Since the MPLS tunnel's Ingress/Egress LSR identifiers'=0D size (Unsigned32) value is not compatible for=0D MPLS-TP tunnel i.e. Global_Node_Id of size 8 bytes and=0D ICC of size 6 bytes, there exists a need to map the=0D Global_Node_ID or ICC with the local identifier of size=0D 4 bytes (Unsigned32) value in order=0D to index (Ingress/Egress LSR identifier)=0D the existing mplsTunnelTable."=0D =0D ::=3D { mplsTeExtObjects 1 }=0D =0D mplsTunnelExtNodeConfigEntry OBJECT-TYPE=0D SYNTAX MplsTunnelExtNodeConfigEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D =0D =0D "An entry in this table represents a mapping=0D identification for the operator or service provider=0D with node or LSR.=0D =0D As per [RFC6370], this mapping is=0D =0D represented as Global_Node_ID or ICC.=0D =0D Note: Each entry in this table should have a unique=0D Global_ID and Node_ID combination."=0D INDEX { mplsTunnelExtNodeConfigLocalId }=0D ::=3D { mplsTunnelExtNodeConfigTable 1 }=0D =0D MplsTunnelExtNodeConfigEntry ::=3D SEQUENCE {=0D mplsTunnelExtNodeConfigLocalId MplsExtendedTunnelId,=0D mplsTunnelExtNodeConfigGlobalId MplsGlobalId,=0D mplsTunnelExtNodeConfigNodeId MplsNodeId,=0D mplsTunnelExtNodeConfigIccId MplsIccId,=0D mplsTunnelExtNodeConfigRowStatus RowStatus,=0D mplsTunnelExtNodeConfigStorageType StorageType=0D =0D }=0D =0D mplsTunnelExtNodeConfigLocalId OBJECT-TYPE=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 37]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D SYNTAX MplsExtendedTunnelId=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This object is used in accommodating the bigger=0D size Global_Node_ID and/or ICC with lower size LSR=0D identifier in order to index the mplsTunnelTable.=0D =0D The Local Identifier is configured between 0 and 16777215,=0D= as valid IP address range starts from 16777216(01.00.00.00).=0D= This range is chosen to identify the mplsTunnelTable's=0D Ingress/Egress LSR-id is IP address or Local identifier,=0D if the configured range is not IP address, operator is=0D expected to retrieve the complete information=0D (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable.=0D= This way, existing mplsTunnelTable is reused for=0D bidirectional tunnel extensions for MPLS based transport=0D networks.=0D =0D This Local Identifier allows the operator to assign=0D a unique identifier to map Global_Node_ID and/or ICC.=0D As this Local Identifier is unique within the node and=0D the same syntax of this object can be used for MPLS TE=0D tunnel also, it is up to the operator/local management=0D entity to choose the non-conflicting value for indexing =0D the MPLS and MPLS-TP tunnel entries."=0D ::=3D { mplsTunnelExtNodeConfigEntry 1 }=0D =0D =0D mplsTunnelExtNodeConfigGlobalId OBJECT-TYPE=0D SYNTAX MplsGlobalId=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object indicates the Global Operator Identifier.=0D This object value should be zero when=0D mplsTunnelExtNodeConfigIccId is configured with non-null=0D value."=0D REFERENCE=0D "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370]=0D= Section 3. Uniquely Identifying an Operator -=0D the Global_ID"=0D ::=3D { mplsTunnelExtNodeConfigEntry 2 }=0D =0D mplsTunnelExtNodeConfigNodeId OBJECT-TYPE=0D SYNTAX MplsNodeId=0D MAX-ACCESS read-create=0D STATUS current=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 38]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D DESCRIPTION=0D "This object indicates the Node_ID within the operator.=0D This object value should be zero when=0D mplsTunnelExtNodeConfigIccId is configured with non-null=0D value."=0D REFERENCE=0D "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370]=0D Section 4, Node and Interface Identifiers"=0D ::=3D { mplsTunnelExtNodeConfigEntry 3 }=0D =0D mplsTunnelExtNodeConfigIccId OBJECT-TYPE=0D SYNTAX MplsIccId=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object allows the operator or service provider to=0D configure a unique MPLS-TP ITU-T Carrier Code (ICC)=0D either for Ingress ID or Egress ID.=0D =0D This object value should be zero when=0D mplsTunnelExtNodeConfigGlobalId and=0D mplsTunnelExtNodeConfigNodeId are assigned with non-zero=0D= value."=0D REFERENCE=0D "MPLS-TP Identifiers Following ITU-T Conventions, =0D [I-D.ietf-mpls-tp-itu-t-identifiers], August 2012,=0D Section 3. Uniquely Identifying an Operator - the=0D ICC_Operator_ID"=0D ::=3D { mplsTunnelExtNodeConfigEntry 4 }=0D =0D mplsTunnelExtNodeConfigRowStatus OBJECT-TYPE=0D SYNTAX RowStatus=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object allows the operator to create, modify,=0D and/or delete a row in this table."=0D ::=3D { mplsTunnelExtNodeConfigEntry 5 }=0D =0D =0D mplsTunnelExtNodeConfigStorageType OBJECT-TYPE=0D SYNTAX StorageType=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This variable indicates the storage type for this=0D object.=0D Conceptual rows having the value 'permanent'=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 39]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D need not allow write-access to any columnar=0D objects in the row."=0D DEFVAL { volatile }=0D ::=3D { mplsTunnelExtNodeConfigEntry 6 }=0D =0D =0D -- End of MPLS Transport Profile Node configuration table=0D =0D -- Start of MPLS Transport Profile Node IP compatible=0D -- mapping table=0D =0D mplsTunnelExtNodeIpMapTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsTunnelExtNodeIpMapEntry=0D =0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This read-only table allows the operator to retrieve=0D the local identifier for a given Global_Node_ID in an IP=0D compatible operator environment.=0D =0D This table MAY be used in on-demand and/or proactive=0D =0D OAM operations to get the Ingress/Egress LSR identifier=0D (Local Identifier) from Src-Global_Node_ID=0D or Dst-Global_Node_ID and the Ingress and Egress LSR=0D identifiers are used to retrieve the tunnel entry.=0D =0D This table returns nothing when the associated entry=0D is not defined in mplsTunnelExtNodeConfigTable."=0D ::=3D { mplsTeExtObjects 2 }=0D =0D mplsTunnelExtNodeIpMapEntry OBJECT-TYPE=0D SYNTAX MplsTunnelExtNodeIpMapEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "An entry in this table represents a mapping of=0D Global_Node_ID with the local identifier.=0D =0D An entry in this table is created automatically when=0D the Local identifier is associated with Global_ID and=0D Node_Id in the mplsTunnelExtNodeConfigTable.=0D =0D Note: Each entry in this table should have a unique=0D Global_ID and Node_ID combination."=0D INDEX { mplsTunnelExtNodeIpMapGlobalId,=0D mplsTunnelExtNodeIpMapNodeId=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 40]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D }=0D ::=3D { mplsTunnelExtNodeIpMapTable 1 }=0D =0D MplsTunnelExtNodeIpMapEntry ::=3D SEQUENCE {=0D mplsTunnelExtNodeIpMapGlobalId MplsGlobalId,=0D mplsTunnelExtNodeIpMapNodeId MplsNodeId,=0D mplsTunnelExtNodeIpMapLocalId MplsExtendedTunnelId=0D }=0D =0D mplsTunnelExtNodeIpMapGlobalId OBJECT-TYPE=0D SYNTAX MplsGlobalId=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This object indicates the Global_ID."=0D ::=3D { mplsTunnelExtNodeIpMapEntry 1 }=0D =0D mplsTunnelExtNodeIpMapNodeId OBJECT-TYPE=0D SYNTAX MplsNodeId=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This object indicates the Node_ID within the=0D =0D operator."=0D ::=3D { mplsTunnelExtNodeIpMapEntry 2 }=0D =0D mplsTunnelExtNodeIpMapLocalId OBJECT-TYPE=0D SYNTAX MplsExtendedTunnelId=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "This object contains an IP compatible local identifier=0D which is defined in mplsTunnelExtNodeConfigTable."=0D ::=3D { mplsTunnelExtNodeIpMapEntry 3 }=0D =0D -- End MPLS Transport Profile Node IP compatible table=0D =0D -- Start of MPLS Transport Profile Node ICC based table=0D =0D mplsTunnelExtNodeIccMapTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsTunnelExtNodeIccMapEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This read-only table allows the operator to retrieve=0D the local identifier for a given ICC operator in an ICC=0D operator environment.=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 41]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D This table MAY be used in on-demand and/or proactive=0D OAM operations to get the Ingress/Egress LSR=0D identifier (Local Identifier) from Src-ICC=0D or Dst-ICC and the Ingress and Egress LSR=0D identifiers are used to retrieve the tunnel entry.=0D This table returns nothing when the associated entry=0D is not defined in mplsTunnelExtNodeConfigTable."=0D ::=3D { mplsTeExtObjects 3 }=0D =0D mplsTunnelExtNodeIccMapEntry OBJECT-TYPE=0D SYNTAX MplsTunnelExtNodeIccMapEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "An entry in this table represents a mapping of ICC with=0D the local identifier.=0D =0D An entry in this table is created automatically when=0D the Local identifier is associated with ICC in=0D the mplsTunnelExtNodeConfigTable."=0D INDEX { mplsTunnelExtNodeIccMapIccId }=0D ::=3D { mplsTunnelExtNodeIccMapTable 1 }=0D =0D =0D MplsTunnelExtNodeIccMapEntry ::=3D SEQUENCE {=0D mplsTunnelExtNodeIccMapIccId MplsIccId,=0D mplsTunnelExtNodeIccMapLocalId MplsExtendedTunnelId=0D }=0D =0D mplsTunnelExtNodeIccMapIccId OBJECT-TYPE=0D SYNTAX MplsIccId=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This object allows the operator or service provider to=0D configure a unique MPLS-TP ITU-T Carrier Code (ICC)=0D either for Ingress or Egress LSR ID.=0D =0D The ICC is a string of one to six characters, each=0D character being either alphabetic (i.e. A-Z) or=0D numeric (i.e. 0-9) characters. Alphabetic characters=0D in the ICC should be represented with upper case=0D letters."=0D ::=3D { mplsTunnelExtNodeIccMapEntry 1 }=0D =0D mplsTunnelExtNodeIccMapLocalId OBJECT-TYPE=0D SYNTAX MplsExtendedTunnelId=0D MAX-ACCESS read-only=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 42]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D STATUS current=0D DESCRIPTION=0D "This object contains an ICC based local identifier=0D which is defined in mplsTunnelExtNodeConfigTable."=0D =0D =0D =0D ::=3D { mplsTunnelExtNodeIccMapEntry 2 }=0D =0D -- End MPLS Transport Profile Node ICC based table=0D =0D -- Start of MPLS Tunnel table extension=0D =0D mplsTunnelExtTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsTunnelExtEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This table represents extensions to mplsTunnelTable =0D in order to support MPLS-TP tunnels.=0D =0D As per MPLS-TP Identifiers [RFC6370], LSP_ID for IP based=0D co-routed bidirectional tunnel,=0D =0D =0D A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::=0D Node_ID::Tunnel_Num}::LSP_Num=0D =0D LSP_ID for IP based associated bidirectional tunnel,=0D A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::=0D Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}=0D =0D mplsTunnelTable is reused for forming the LSP_ID=0D as follows,=0D =0D Source Tunnel_Num is mapped with mplsTunnelIndex,=0D Source Node_ID is mapped with=0D mplsTunnelIngressLSRId, Destination Node_ID is=0D mapped with mplsTunnelEgressLSRId LSP_Num is mapped with=0D mplsTunnelInstance.=0D =0D Source Global_Node_ID and/or ICC and Destination=0D Global_Node_ID and/or ICC are maintained in the=0D mplsTunnelExtNodeConfigTable and=0D mplsTunnelExtNodeConfigLocalId is used to create an entry=0D in mplsTunnelTable."=0D REFERENCE=0D "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370],=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 43]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D Section 3 and 4."=0D ::=3D { mplsTeExtObjects 4 }=0D =0D mplsTunnelExtEntry OBJECT-TYPE=0D SYNTAX MplsTunnelExtEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "An entry in this table represents MPLS-TP=0D specific additional tunnel configurations."=0D INDEX {=0D mplsTunnelIndex,=0D mplsTunnelInstance,=0D mplsTunnelIngressLSRId,=0D mplsTunnelEgressLSRId=0D }=0D ::=3D { mplsTunnelExtTable 1 }=0D =0D MplsTunnelExtEntry ::=3D SEQUENCE {=0D mplsTunnelExtOppositeDirPtr RowPointer,=0D mplsTunnelExtOppositeDirTnlValid TruthValue,=0D mplsTunnelExtDestTnlIndex MplsTunnelIndex,=0D mplsTunnelExtDestTnlLspIndex MplsTunnelInstanceIndex,=0D mplsTunnelExtDestTnlValid TruthValue,=0D mplsTunnelExtIngressLSRLocalIdValid TruthValue,=0D mplsTunnelExtEgressLSRLocalIdValid TruthValue=0D =0D }=0D =0D mplsTunnelExtOppositeDirPtr OBJECT-TYPE=0D SYNTAX RowPointer=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object is applicable only for the bidirectional=0D tunnel that has the forward and reverse LSPs in the=0D same tunnel or in the different tunnels.=0D =0D This object holds the opposite direction tunnel entry=0D if the bidirectional tunnel is setup by configuring two=0D tunnel entries in mplsTunnelTable.=0D =0D Note that there are two different ways to represent the=0D opposite direction tunnel entry. One method is to use this=0D= object mplsTunnelExtOppositeDirPtr as RowPointer and make=0D= it point to the other direction tunnel. Other method is to=0D= use the mplsTunnelExtDestTnlIndex and=0D mplsTunnelExtDestTnlLspIndex instead of using this=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 44]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelExtOppositeDirPtr. Implementation can choose=0D either one of the method to represent the opposite=0D direction tunnel. Duplicate methods are provided to provide=0D= easy ways for different implementations.=0D =0D The value of zeroDotZero indicates single tunnel entry=0D is used for bidirectional tunnel setup."=0D =0D DEFVAL { zeroDotZero }=0D ::=3D { mplsTunnelExtEntry 1 }=0D =0D mplsTunnelExtOppositeDirTnlValid OBJECT-TYPE=0D SYNTAX TruthValue=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "Denotes whether or not this tunnel uses=0D mplsTunnelExtOppositeDirPtr for identifying the opposite=0D direction tunnel information. Note that if this variable=0D is set to true then the mplsTunnelExtOppositeDirPtr should=0D= point to the first accessible row of the opposite=0D direction tunnel."=0D DEFVAL { false }=0D ::=3D { mplsTunnelExtEntry 2 }=0D =0D mplsTunnelExtDestTnlIndex OBJECT-TYPE=0D SYNTAX MplsTunnelIndex=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object is applicable only for the bidirectional=0D tunnel that has the forward and reverse LSPs in the=0D same tunnel or in the different tunnels.=0D =0D This object holds the same value as that of the=0D mplsTunnelIndex of mplsTunnelEntry if the forward and=0D reverse LSPs are in the same tunnel. Otherwise,=0D this object holds the value of the other direction=0D associated LSP's mplsTunnelIndex from a different=0D =0D tunnel.=0D =0D The values of this object and the=0D mplsTunnelExtDestTnlLspIndex object together can be used=0D to identify an opposite direction LSP i.e. if the=0D mplsTunnelIndex and mplsTunnelInstance hold the value=0D for forward LSP, this object and=0D mplsTunnelExtDestTnlLspIndex can be used to retrieve=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 45]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D the reverse direction LSP and vice versa.=0D =0D This object and mplsTunnelExtDestTnlLspIndex values=0D provide the first two indices of tunnel entry and=0D the remaining indices can be derived as follows,=0D if both the forward and reverse LSPs are present in=0D the same tunnel, the opposite direction LSP's Ingress=0D and Egress Identifier will be same for both the LSPs,=0D else the Ingress and Egress Identifiers should be=0D swapped in order to index the other direction tunnel."=0D =0D ::=3D { mplsTunnelExtEntry 3 }=0D =0D mplsTunnelExtDestTnlLspIndex OBJECT-TYPE=0D SYNTAX MplsTunnelInstanceIndex=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object is applicable only for the bidirectional=0D tunnel that has the forward and reverse LSPs in the=0D same tunnel or in the different tunnels.=0D =0D This object should contain different value if both the=0D forward and reverse LSPs present in the same tunnel.=0D =0D This object can contain same value or different values=0D if the forward and reverse LSPs present in the different=0D tunnels."=0D =0D ::=3D { mplsTunnelExtEntry 4 }=0D =0D mplsTunnelExtDestTnlValid OBJECT-TYPE=0D SYNTAX TruthValue=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "Denotes whether or not this tunnel uses=0D mplsTunnelExtDestTnlIndex and=0D mplsTunnelExtDestTnlLspIndex for identifying=0D the opposite direction tunnel information. Note that if=0D this variable is set to true then the=0D mplsTunnelExtDestTnlIndex and=0D mplsTunnelExtDestTnlLspIndex objects should have=0D the valid opposite direction tunnel indices."=0D DEFVAL { false }=0D ::=3D { mplsTunnelExtEntry 5 }=0D =0D mplsTunnelExtIngressLSRLocalIdValid OBJECT-TYPE=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 46]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D SYNTAX TruthValue=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object denotes whether the mplsTunnelIngressLSRId=0D contains the local value, which is used to reference=0D the complete Ingress Global_ID::Node_ID or ICC from=0D the mplsTunnelExtNodeConfigTable."=0D REFERENCE=0D "MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelIngressLSRId=0D= object in mplsTunnelTable. =0D =0D If this object is set to FALSE, mplsTunnelExtNodeConfigTable=0D= will not contain an entry to reference local identifier with=0D= Global_ID::Node_ID or ICC value.=0D =0D This object is set to FALSE for legacy implementations like=0D= MPLS TE tunnels where mplsTunnelIngressId itself provides=0D complete Ingress LSRId."=0D DEFVAL { false }=0D ::=3D { mplsTunnelExtEntry 6 }=0D =0D mplsTunnelExtEgressLSRLocalIdValid OBJECT-TYPE=0D SYNTAX TruthValue=0D MAX-ACCESS read-create=0D STATUS current=0D DESCRIPTION=0D "This object denotes whether the mplsTunnelEgressLSRId=0D contains the local value, which is used to reference=0D the complete Egress Global_ID::Node_ID or ICC from=0D the mplsTunnelExtNodeConfigTable."=0D REFERENCE=0D "MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelEgressLSRId=0D= object in mplsTunnelTable.=0D =0D If this object is set to FALSE, mplsTunnelExtNodeConfigTable=0D= will not contain an entry to reference local identifier with=0D= Global_ID::Node_ID or ICC value.=0D =0D This object is set to FALSE for legacy implementations like=0D= MPLS TE tunnels where mplsTunnelEgressId itself provides=0D complete Egress LSRId."=0D DEFVAL { false }=0D ::=3D { mplsTunnelExtEntry 7 }=0D =0D -- End of MPLS Tunnel table extension=0D mplsTunnelExtReversePerfTable OBJECT-TYPE=0D SYNTAX SEQUENCE OF MplsTunnelExtReversePerfEntry=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 47]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "This table extends the mplsTunnelTable to provide=0D per-tunnel packet performance information for the reverse=0D direction of a bidirectional tunnel. It can be seen as=0D supplementing the mplsTunnelPerfTable, which augments the=0D mplsTunnelTable.=0D =0D For links that do not transport packets, these packet=0D counters cannot be maintained. For such links, attempts=0D to read the objects in this table will return=0D noSuchInstance."=0D REFERENCE=0D "1. Multiprotocol Label Switching (MPLS) Traffic=0D Engineering (TE)Management Information Base (MIB),=0D RFC 3812. Section 6.6. mplsTunnelPerfTable"=0D ::=3D { mplsTeExtObjects 5 }=0D =0D mplsTunnelExtReversePerfEntry OBJECT-TYPE=0D SYNTAX MplsTunnelExtReversePerfEntry=0D MAX-ACCESS not-accessible=0D STATUS current=0D DESCRIPTION=0D "An entry in this table is created by the LSR for every=0D bidirectional MPLS tunnel where packets are visible to the=0D LSR."=0D INDEX {=0D mplsTunnelIndex,=0D mplsTunnelInstance,=0D mplsTunnelIngressLSRId,=0D mplsTunnelEgressLSRId=0D }=0D ::=3D { mplsTunnelExtReversePerfTable 1 }=0D =0D MplsTunnelExtReversePerfEntry ::=3D SEQUENCE {=0D mplsTunnelExtReversePerfPackets Counter32,=0D mplsTunnelExtReversePerfHCPackets Counter64,=0D mplsTunnelExtReversePerfErrors Counter32,=0D mplsTunnelExtReversePerfBytes Counter32,=0D mplsTunnelExtReversePerfHCBytes Counter64=0D }=0D =0D mplsTunnelExtReversePerfPackets OBJECT-TYPE=0D SYNTAX Counter32=0D MAX-ACCESS read-only=0D =0D STATUS current=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 48]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D DESCRIPTION=0D "Number of packets forwarded on the tunnel in the reverse=0D direction if it is bidirectional.=0D =0D This object represents the 32-bit value of the least=0D significant part of the 64-bit value if both=0D mplsTunnelExtReversePerfHCPackets and this object=0D are returned.=0D =0D For links that do not transport packets, this packet=0D counter cannot be maintained. For such links, this value=0D will return noSuchInstance."=0D ::=3D { mplsTunnelExtReversePerfEntry 1 }=0D =0D mplsTunnelExtReversePerfHCPackets OBJECT-TYPE=0D SYNTAX Counter64=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "High-capacity counter for number of packets forwarded on=0D the tunnel in the reverse direction if it is=0D bidirectional.=0D =0D For links that do not transport packets, this packet=0D counter cannot be maintained. For such links, this value=0D will return noSuchInstance."=0D ::=3D { mplsTunnelExtReversePerfEntry 2 }=0D =0D mplsTunnelExtReversePerfErrors OBJECT-TYPE=0D SYNTAX Counter32=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "Number of errored packets received on the tunnel in=0D the reverse direction if it is bidirectional. For links=0D that do not transport packets, this packet counter cannot=0D be maintained. For such links, this value will return=0D noSuchInstance."=0D ::=3D { mplsTunnelExtReversePerfEntry 3 }=0D =0D mplsTunnelExtReversePerfBytes OBJECT-TYPE=0D SYNTAX Counter32=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "Number of bytes forwarded on the tunnel in the reverse=0D direction if it is bidirectional.=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 49]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D This object represents the 32-bit value of the least=0D significant part of the 64-bit value if both=0D mplsTunnelExtReversePerfHCBytes and this object are returned.=0D= =0D For links that do not transport packets, this packet=0D counter cannot be maintained. For such links, this value=0D will return noSuchInstance."=0D ::=3D { mplsTunnelExtReversePerfEntry 4 }=0D =0D mplsTunnelExtReversePerfHCBytes OBJECT-TYPE=0D SYNTAX Counter64=0D MAX-ACCESS read-only=0D STATUS current=0D DESCRIPTION=0D "High-capacity counter for number of bytes forwarded on the=0D tunnel in the reverse direction if it is bidirectional.=0D =0D For links that do not transport packets, this packet=0D counter cannot be maintained. For such links, this value=0D will return noSuchInstance."=0D ::=3D { mplsTunnelExtReversePerfEntry 5 }=0D =0D -- Notifications.=0D -- Notification objects need to be added here.=0D -- End of notifications.=0D =0D -- Module compliance.=0D =0D mplsTeExtGroups=0D OBJECT IDENTIFIER ::=3D { mplsTeExtConformance 1 }=0D =0D mplsTeExtCompliances=0D OBJECT IDENTIFIER ::=3D { mplsTeExtConformance 2 }=0D =0D -- Compliance requirement for fully compliant implementations.=0D =0D mplsTeExtModuleFullCompliance MODULE-COMPLIANCE=0D STATUS current=0D DESCRIPTION=0D "Compliance statement for agents that provide full=0D support the MPLS-TE-EXT-STD-MIB module."=0D =0D MODULE -- this module=0D =0D -- The mandatory group has to be implemented by all=0D -- LSRs that originate/terminate MPLS-TP tunnels.=0D -- In addition, depending on the type of tunnels=0D -- supported, other groups become mandatory as=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 50]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D -- explained below.=0D =0D MANDATORY-GROUPS {=0D mplsTunnelExtGroup=0D }=0D =0D GROUP mplsTunnelExtIpOperatorGroup=0D =0D DESCRIPTION=0D "This group is mandatory for devices which support=0D configuration of IP based identifier tunnels."=0D =0D GROUP mplsTunnelExtIccOperatorGroup=0D =0D =0D =0D DESCRIPTION=0D "This group is mandatory for devices which support=0D configuration of ICC based tunnels."=0D =0D ::=3D { mplsTeExtCompliances 1 }=0D =0D -- Compliance requirement for read-only implementations.=0D =0D mplsTeExtModuleReadOnlyCompliance MODULE-COMPLIANCE=0D STATUS current=0D DESCRIPTION=0D "Compliance statement for agents that provide full=0D support the MPLS-TE-EXT-STD-MIB module."=0D =0D MODULE -- this module=0D =0D -- The mandatory group has to be implemented by all=0D -- LSRs that originate/terminate MPLS-TP tunnels.=0D -- In addition, depending on the type of tunnels=0D -- supported, other groups become mandatory as=0D -- explained below.=0D =0D MANDATORY-GROUPS {=0D mplsTunnelExtGroup=0D }=0D =0D GROUP mplsTunnelExtIpOperatorGroup=0D DESCRIPTION=0D "This group is mandatory for devices which support=0D configuration of IP based identifier tunnels."=0D =0D GROUP mplsTunnelExtIccOperatorGroup=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 51]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D DESCRIPTION=0D "This group is mandatory for devices which support=0D configuration of ICC based tunnels."=0D =0D ::=3D { mplsTeExtCompliances 2 }=0D =0D -- Units of conformance.=0D =0D =0D mplsTunnelExtGroup OBJECT-GROUP=0D OBJECTS {=0D mplsTunnelExtOppositeDirPtr,=0D mplsTunnelExtOppositeDirTnlValid,=0D mplsTunnelExtDestTnlIndex,=0D mplsTunnelExtDestTnlLspIndex,=0D mplsTunnelExtDestTnlValid,=0D mplsTunnelExtIngressLSRLocalIdValid,=0D mplsTunnelExtEgressLSRLocalIdValid,=0D mplsTunnelExtReversePerfPackets,=0D mplsTunnelExtReversePerfHCPackets,=0D mplsTunnelExtReversePerfErrors,=0D mplsTunnelExtReversePerfBytes,=0D mplsTunnelExtReversePerfHCBytes=0D }=0D =0D STATUS current=0D DESCRIPTION=0D "Necessary, but not sufficient, set of objects to=0D implement tunnels. In addition, depending on the=0D operating environment, the following groups are=0D mandatory."=0D ::=3D { mplsTeExtGroups 1 }=0D =0D mplsTunnelExtIpOperatorGroup OBJECT-GROUP=0D OBJECTS { mplsTunnelExtNodeConfigGlobalId,=0D mplsTunnelExtNodeConfigNodeId,=0D mplsTunnelExtNodeConfigRowStatus,=0D mplsTunnelExtNodeConfigStorageType,=0D mplsTunnelExtNodeIpMapLocalId=0D }=0D STATUS current=0D DESCRIPTION=0D "Object(s) needed to implement IP compatible tunnels."=0D ::=3D { mplsTeExtGroups 2 }=0D =0D mplsTunnelExtIccOperatorGroup OBJECT-GROUP=0D OBJECTS { mplsTunnelExtNodeConfigIccId,=0D mplsTunnelExtNodeConfigRowStatus,=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 52]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D mplsTunnelExtNodeConfigStorageType,=0D mplsTunnelExtNodeIccMapLocalId=0D }=0D STATUS current=0D DESCRIPTION=0D "Object(s) needed to implement ICC based tunnels."=0D ::=3D { mplsTeExtGroups 3 }=0D =0D -- MPLS-TE-EXT-STD-MIB module ends=0D END=0D =0D 14. Security Consideration=0D =0D There is a number of management objects defined in this MIB module=0D= that has a MAX-ACCESS clause of read-write.. Such objects may be=0D= considered sensitive or vulnerable in some network environments.=0D= The support for SET operations in a non-secure environment without=0D= proper protection can have a negative effect on network=0D operations.=0D =0D Some of the readable objects in this MIB module (i.e., objects=0D with a MAX-ACCESS other than not-accessible) may be considered=0D sensitive or vulnerable in some network environments.=0D It is thus important to control even GET and/or NOTIFY access to=0D= these objects and possibly to even encrypt the values of these=0D objects when sending them over the network via SNMP. These are=0D the tables and objects and their sensitivity/vulnerability:=0D =0D SNMP versions prior to SNMPv3 did not include adequate security.=0D= Even if the network itself is secure (for example by using IPsec),=0D= even then, there is no control as to who on the secure network is=0D= allowed to access and GET/SET (read/change/create/delete)=0D the objects in this MIB module.=0D =0D It is recommended that implementers consider the security features=0D= as provided by the SNMPv3 framework (see [RFC3410], section 8),=0D including full supports for the SNMPv3 cryptographic mechanisms=0D (for authentication and privacy).=0D =0D Further, deployment of SNMP versions prior to SNMPv3 is not=0D recommended. Instead, it is recommended to deploy SNMPv3 and to=0D= enable cryptographic security. It is then a customer/operator=0D responsibility to ensure that the SNMP entity giving access to an=0D= instance of this MIB module is properly configured to give=0D access to the objects only to those principles (users) that=0D have legitimate rights to indeed GET or SET (change/create/delete)=0D= them.=0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 53]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D 15. IANA Considerations=0D =0D To be added in a later version of this document.=0D =0D 16. References=0D =0D 16.1. Normative References=0D =0D [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0D Requirement Levels", BCP 14, RFC 2119, March 1997.=0D =0D [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=0D "Structure of Management Information Version 2 (SMIv2)",=0D= STD 58, RFC 2578, April 1999.=0D =0D [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=0D "Textual Conventions for SMIv2", STD 58, RFC 2579, April=0D= 1999.=0D =0D [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=0D =0D "Conformance Statements for SMIv2", STD 58, RFC 2580,=0D April 1999.=0D =0D [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol=0D= Label Switching Architecture", RFC 3031, January 2001.=0D= =0D 16.2. Informative References=0D =0D [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,=0D "Multiprotocol Label Switching (MPLS) Traffic Engineering=0D= (TE) Management Information Base (MIB)", RFC 3812, June=0D= 2004.=0D =0D [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,=0D "Multiprotocol Label Switching (MPLS) Label Switching=0D (LSR) Router Management Information Base (MIB)", RFC 3813,=0D= June 2004.=0D =0D [RFC3410] J. Case, R. Mundy, D. pertain, B.Stewart, "Introduction=0D and Applicability Statement for Internet Standard=0D Management Framework", RFC 3410, December 2002.=0D =0D [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of=0D Textual Conventions (TCs) for Multiprotocol Label=0D Switching (MPLS) Management", RFC 3811, June 2004.=0D =0D [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized=0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 54]=0D= =0C=0D INTERNET DRAFT MPLS-TP MIB January 14, 2013=0D= =0D =0D Multiprotocol Label Switching (GMPLS) Traffic=0D Engineering Management Information Base", RFC=0D= 4802, February 2007.=0D [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,=0D= Sprecher, N., and S. Ueno, "Requirements of an MPLS=0D Transport Profile", RFC 5654, September 2009.=0D =0D [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport=0D Profile (MPLS-TP) Identifiers", RFC 6370, September=0D= 2011.=0D =0D [I-D.ietf-mpls-tp-itu-t-identifiers] Winter, R., Gray, E., Helvoort,=0D= H., and M. Betts, "MPLS-TP Identifiers Following ITU-T=0D Conventions", draft-ietf-mpls-tp-itu-t-identifiers-07=0D (work in progress), August 2012.=0D =0D 17. Acknowledgments=0D =0D The authors would like to thank Francesco Fondelli, Josh Littlefield,=0D= Agrahara Kiran Koushik, Metrri Jain, Muly Ilan, Joan Cucchiara and=0D Randy Presuhn for their valuable comments.=0D =0D 18. Authors' Addresses=0D =0D Sam Aldrin=0D Huawei Technologies=0D 2330 Central Express Way,=0D Santa Clara, CA 95051, USA=0D Email: aldrin.ietf@gmail.com=0D =0D Thomas D. Nadeau=0D Juniper Networks=0D 10 Technology Park Drive, Westford, MA 01886=0D Email: tnadeau@juniper.net=0D =0D Venkatesan Mahalingam=0D Dell Inc.=0D 350 Holger way, San Jose, CA, USA=0D Email: venkat.mahalingams@gmail.com=0D =0D Kannan KV Sampath=0D Redeem=0D India=0D Email: kannankvs@gmail.com=0D =0D =0D =0D =0D =0D =0D =0D Venkatesan, et al. Expires July 18, 2013 [Page 55]=0D= --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Disposition: attachment; filename*0="Diff draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-m"; filename*1=ib-05.txt.htm Content-Type: text/html; name="Diff draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-mib-05.txt.htm" Content-Transfer-Encoding: 7bit Diff: draft-ietf-mpls-tp-te-mib-04.txt - draft-ietf-mpls-tp-te-mib-05.txt
< draft-ietf-mpls-tp-te-mib-04.txt   draft-ietf-mpls-tp-te-mib-05.txt >
Network Working Group Network Working Group
INTERNET-DRAFT M.Venkatesan INTERNET-DRAFT M.Venkatesan
Intended Status: Standards Track Dell Inc. Intended Status: Standards Track Dell Inc.
Expires: January 16, 2013 Kannan KV Sampath Expires: July 18, 2013 Kannan KV Sampath
Aricent Redeem
Sam K. Aldrin Sam K. Aldrin
Huawei Technologies Huawei Technologies
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
July 15, 2012 January 14, 2013
MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)
draft-ietf-mpls-tp-te-mib-04.txt draft-ietf-mpls-tp-te-mib-05.txt
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes managed objects of Tunnels, Identifiers, In particular, it describes managed objects of Tunnels, Identifiers,
Label Switch Router and Textual conventions for Multiprotocol Label Label Switch Router and Textual conventions for Multiprotocol Label
Switching (MPLS) based Transport Profile (TP). Switching (MPLS) based Transport Profile (TP).
Status of this Memo Status of this Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on July 18, 2013.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet-Standard Management Framework . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Conventions used in this document . . . . . . . . . . . . . 3 3.1. Conventions used in this document . . . . . . . . . . . . . 4
3.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Feature List . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Brief description of MIB Objects . . . . . . . . . . . . . . . 4 6. Brief description of MIB Objects . . . . . . . . . . . . . . . 5
6.1. mplsTunnelExtNodeConfigTable . . . . . . . . . . . . . . 5 6.1. mplsTunnelExtNodeConfigTable . . . . . . . . . . . . . . . 6
6.2. mplsTunnelExtNodeIpMapTable . . . . . . . . . . . . . . . 5 6.2. mplsTunnelExtNodeIpMapTable . . . . . . . . . . . . . . . . 6
6.3. mplsTunnelExtNodeIccMapTable . . . . . . . . . . . . . . 6 6.3. mplsTunnelExtNodeIccMapTable . . . . . . . . . . . . . . . 7
6.4.mplsTunnelExtTable . . . . . . . . . . . . . . . . . . . . . 6 6.4. mplsTunnelExtTable . . . . . . . . . . . . . . . . . . . . 7
7. MIB Module Interdependencies . . . . . . . . . . . . . . . . . 6 6.5. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . . . 7
8. Dependencies between MIB Module Tables . . . . . . . . . . . . 8 7. MIB Module Interdependencies . . . . . . . . . . . . . . . . . 7
9. Example of MPLS-TP tunnel setup . . . . . . . . . . . . . . . . 8 8. Dependencies between MIB Module Tables . . . . . . . . . . . . 9
10. MPLS Textual Convention Extension MIB definitions . . . . . . 13 9. Example of MPLS-TP Tunnel Setup . . . . . . . . . . . . . . . . 9
11. MPLS Identifier MIB definitions . . . . . . . . . . . . . . . 16 9.1. Example of MPLS-TP static co-routed bidirectional tunnel
12. MPLS LSR Extension MIB definitions . . . . . . . . . . . . . . 20 setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
13. MPLS Tunnel Extension MIB definitions . . . . . . . . . . . . 24 9.1.1. mplsTunnelEntry . . . . . . . . . . . . . . . . . . . . 10
14. Security Consideration . . . . . . . . . . . . . . . . . . . . 36 9.1.2. mplsTunnelExtEntry . . . . . . . . . . . . . . . . . . 11
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9.1.3. Forward direction mplsOutSegmentEntry . . . . . . . . . 12
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1.4. Reverse direction mplsInSegmentEntry . . . . . . . . . 12
16.1 Normative References . . . . . . . . . . . . . . . . . . . 37 9.1.5. Forward direction mplsXCEntry . . . . . . . . . . . . . 12
16.2 Informative References . . . . . . . . . . . . . . . . . . 38 9.1.6. Reverse direction mplsXCEntry . . . . . . . . . . . . . 13
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 9.1.7. Forward direction mplsXCExtEntry . . . . . . . . . . . 13
18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38 9.1.8. Reverse direction mplsXCExtEntry . . . . . . . . . . . 13
9.1.9. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . 13
1 Introduction 9.2. Example of MPLS-TP static associated bidirectional tunnel
setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.1. Forward direction mplsTunnelEntry . . . . . . . . . . . 14
9.2.2. Forward direction mplsTunnelExtEntry . . . . . . . . . 15
9.2.3. Forward direction mplsOutSegmentTable . . . . . . . . . 15
9.2.4. Forward direction mplsXCEntry . . . . . . . . . . . . . 15
9.2.5. Forward direction mplsXCExtEntry . . . . . . . . . . . 16
9.2.6. Reverse direction mplsTunnelEntry . . . . . . . . . . . 16
9.2.7. Reverse direction mplsTunnelExtEntry . . . . . . . . . 17
9.2.8. Reverse direction mplsInSegmentEntry . . . . . . . . . 17
9.2.9. Reverse direction mplsXCEntry . . . . . . . . . . . . . 17
9.2.10. Reverse direction mplsXCExtEntry . . . . . . . . . . . 18
9.3. Example of MPLS-TP signaling co-routed bidirectional
tunnel setup . . . . . . . . . . . . . . . . . . . . . . . 18
9.3.1. mplsTunnelEntry . . . . . . . . . . . . . . . . . . . . 18
9.3.2. mplsTunnelExtEntry . . . . . . . . . . . . . . . . . . 19
9.3.3. Forward direction mplsOutSegmentEntry . . . . . . . . . 19
9.3.4. Reverse direction mplsInSegmentEntry . . . . . . . . . 19
9.3.5. Forward direction mplsXCEntry . . . . . . . . . . . . . 20
9.3.6. Reverse direction mplsXCEntry . . . . . . . . . . . . . 20
9.3.7. Forward direction mplsXCExtEntry . . . . . . . . . . . 20
9.3.8. Reverse direction mplsXCExtEntry . . . . . . . . . . . 20
9.3.9. mplsTunnelExtReversePerfTable . . . . . . . . . . . . . 20
10. MPLS Textual Convention Extension MIB definitions . . . . . . 20
11. MPLS Identifier MIB definitions . . . . . . . . . . . . . . . 23
12. MPLS LSR Extension MIB definitions . . . . . . . . . . . . . . 27
13. MPLS Tunnel Extension MIB definitions . . . . . . . . . . . . 31
14. Security Consideration . . . . . . . . . . . . . . . . . . . . 49
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
16.1. Normative References . . . . . . . . . . . . . . . . . . . 50
16.2. Informative References . . . . . . . . . . . . . . . . . 50
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
18. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51
This memo defines a portion of the Management Information Base (MIB) 1. Introduction
for use with network management protocols in the Internet community.
In particular, it describes managed objects of Tunnels, Identifiers,
Label Switch Router and Textual conventions for Multiprotocol Label
Switching (MPLS) based Transport Profile (TP).
The existing MPLS TE [RFC3812] and GMPLS MIBs [RFC4802] do not This memo defines a portion of the Management Information Base (MIB) for
support the transport network requirements of NON-IP based management use with network management protocols in the Internet community. In
and static bidirectional tunnels. This MIB module should be used in particular, it describes managed objects of Tunnels, Identifiers, Label
conjunction with the MPLS traffic Engineering MIB [RFC3812] and Switch Router and Textual conventions for Multiprotocol Label Switching
companion document MPLS Label Switch Router MIB [RFC3813] for MPLS (MPLS) based Transport Profile (TP). This draft extends the existing
based traffic engineering configuration and management. MPLS MIB objects for both MPLS-TP and Non-MPLS-TP operations, so the
MPLS-TP name is not included in the MIB module name.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The existing Multiprotocol Label Switching (MPLS) Traffic Engineering
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to (TE) Management Information Base (MIB) [RFC3812] and Generalized
be interpreted as described in BCP 14, RFC2119. Multiprotocol Label Switching (GMPLS) Traffic Engineering Management
Information Base [RFC4802] do not support the transport network
requirements of NON-IP based management and static bidirectional
tunnels. This MIB module should be used in conjunction with [RFC3812]
and companion document [RFC3813] for MPLS based traffic engineering
configuration and management.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14, RFC2119.
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC3410 [RFC3410]. RFC3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed the
the Management Information Base or MIB. MIB objects are generally Management Information Base or MIB. MIB objects are generally accessed
accessed through the Simple Network Management Protocol (SNMP). through the Simple Network Management Protocol (SNMP). Objects in the
Objects in the MIB are defined using the mechanisms defined in the MIB are defined using the mechanisms defined in the Structure of
Structure of Management Information (SMI). This memo specifies a MIB Management Information (SMI). This memo specifies a MIB module that is
module that is compliant to the SMIv2, which is described in STD 58, compliant to the SMIv2, which is described in STD 58, RFC2578, STD 58,
RFC2578, STD 58, RFC2579 and STD58, RFC2580. RFC2579 and STD58, RFC2580.
3. Overview 3. Overview
3.1 Conventions used in this document 3.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terminology from the MPLS architecture document 3.2. Terminology
[RFC3031], MPLS Traffic Engineering Management information [RFC3812], This document uses terminology from the Multiprotocol Label Switching
MPLS Label Switch Router MIB [RFC3813] and MPLS-TP Identifiers Architecture [RFC3031], Multiprotocol Label Switching (MPLS) Traffic
document [RFC6370]. Engineering (TE) Management Information Base (MIB) [RFC3812],
Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)
Management Information Base (MIB) [RFC3813] and MPLS Transport Profile
(MPLS-TP) Identifiers [RFC6370].
3.3 Acronyms 3.3. Acronyms
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
ICC: ITU Carrier Code ICC: ITU Carrier Code
IP: Internet Protocol IP: Internet Protocol
LSP: Label Switching Path LSP: Label Switching Path
LSR: Label Switching Router LSR: Label Switching Router
MIB: Management Information Base MIB: Management Information Base
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile MPLS-TP: MPLS Transport Profile
OSPF: Open Shortest Path First OSPF: Open Shortest Path First
PW: Pseudowire PW: Pseudowire
TE: Traffic Engineering TE: Traffic Engineering
TP: Transport Profile TP: Transport Profile
4. Motivations 4. Motivations
This document provide extensions to existing MPLS MIB modules in Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management
order to support configuration of MPLS-TP tunnels in IP and NON-IP Information Base (MIB) [RFC3812] provides support for Traffic
environments. Engineering tunnels. However, with MPLS-TP, the characteristics of
Tunnels were enhanced. For example, MPLS-TP tunnels are bidirectional in
nature and could be used in non-IP environment. As the existing MPLS-TE-
STD-MIB is not sufficient to capture all the characteristics of the
tunnels, enhancing the MIB to support MPLS TP tunnels is required. As
most of the attributes of MPLS Traffic Engineering tunnels are also
applicable to MPLS-TP tunnels, it is optimal to re-use the existing MIB
definition instead of a new MIB.
This MIB also defines three other MIB modules within this document. As
these new MIB modules are small in size, MPLS-TC-EXT-STD-MIB, MPLS-ID-
STD-MIB and MPLS-LSR-EXT-STD-MIB are retained in the same document,
instead of a separate document.
5. Feature List 5. Feature List
The MPLS transport profile MIB module is designed to satisfy the The MPLS transport profile MIB module is designed to satisfy the
following requirements and constraints: following requirements and constraints:
The MIB module supports point-to-point, co-routed bi-directional The MIB module supports static and signaling point-to-point, co-routed
associated bi-directional tunnels. bi-directional and associated bi-directional tunnels.
- The MPLS tunnels need not be interfaces, but it is possible - The MPLS tunnels need not be interfaces, but it is possible
to configure a TP tunnel as an interface. to configure a TP tunnel as an interface.
- The mplsTunnelTable [RFC3812] to be also used for MPLS-TP - The mplsTunnelTable [RFC3812] to be also used for MPLS-TP
tunnels tunnels
- The mplsTunnelTable is extended to support MPLS-TP specific - The mplsTunnelTable is extended to support MPLS-TP specific
objects. objects.
skipping to change at page 5, line 4 skipping to change at page 7, line 14
objects. objects.
- A node configuration table (mplsTunnelExtNodeConfigTable) - A node configuration table (mplsTunnelExtNodeConfigTable)
is used to translate the Global_Node_ID or ICC to the local is used to translate the Global_Node_ID or ICC to the local
identifier in order to index mplsTunnelTable. identifier in order to index mplsTunnelTable.
- The MIB module supports persistent, as well as non-persistent - The MIB module supports persistent, as well as non-persistent
tunnels. tunnels.
6. Brief description of MIB Objects 6. Brief description of MIB Objects
The objects described in this section support the functionality The objects described in this section support the functionality
described in documents [RFC5654] and [RFC6370]. The tables support described in documents [RFC5654] and [RFC6370]. The tables support
both IP compatible and ICC based tunnel configurations. both IP compatible and ICC based tunnel configurations.
6.1. mplsTunnelExtNodeConfigTable 6.1. mplsTunnelExtNodeConfigTable
The mplsTunnelExtNodeConfigTable is used to assign a local identifier The mplsTunnelExtNodeConfigTable is used to assign a local identifier
for a given ICC or Global_Node_ID combination as defined in for a given ICC or Global_Node_ID combination as defined in
[RFC6370]. An ICC is a string of one to six characters, each [RFC6370]. An ICC is a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9) character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9)
characters. Alphabetic characters in the ICC should be represented characters. Alphabetic characters in the ICC should be represented
with upper case letters. In the IP compatible mode, with upper case letters. In the IP compatible mode,
Global_Node_ID, is used to uniquely identify a node. Global_Node_ID, is used to uniquely identify a node.
Each ICC or Global_Node_ID contains one unique entry in the Each ICC or Global_Node_ID contains one unique entry in the
skipping to change at page 5, line 37 skipping to change at page 7, line 48
For ICC based environment, MPLS-TP tunnel is indexed by Tunnel Index, For ICC based environment, MPLS-TP tunnel is indexed by Tunnel Index,
Tunnel Instance, Source ICC and Destination ICC. Tunnel Instance, Source ICC and Destination ICC.
As mplsTunnelTable is indexed by mplsTunnelIndex, As mplsTunnelTable is indexed by mplsTunnelIndex,
mplsTunnelInstance, mplsTunnelIngressLSRId, and mplsTunnelInstance, mplsTunnelIngressLSRId, and
mplsTunnelEgressLSRId, the MPLS-TP tunnel identifiers cannot be mplsTunnelEgressLSRId, the MPLS-TP tunnel identifiers cannot be
used directly. used directly.
The mplsTunnelExtNodeConfigTable will be used to store an entry for The mplsTunnelExtNodeConfigTable will be used to store an entry for
ICC or Global_Node_ID with a local identifier to be used as LSR ID ICC or Global_Node_ID with a local identifier to be used as LSR ID in
in mplsTunnelTable. As the regular TE tunnels use IP address as LSR mplsTunnelTable. As the regular TE tunnels use IP address as LSR ID,
ID, the local identifier should be below the first valid IP address, the local identifier should be below the first valid IP address,
which is 16777216[1.0.0.0]. which is 16777216[1.0.0.0].
6.2. mplsTunnelExtNodeIpMapTable 6.2. mplsTunnelExtNodeIpMapTable
The read-only mplsTunnelExtNodeIpMaptable is used to query the local The read-only mplsTunnelExtNodeIpMaptable is used to query the local
identifier assigned and stored in mplsTunnelExtNodeConfigTable for identifier assigned and stored in mplsTunnelExtNodeConfigTable for
a given Global_Node_ID. In order to query the local identifier, a given Global_Node_ID. In order to query the local identifier,
in the IP compatible mode, this table is indexed with Global_Node_ID. in the IP compatible mode, this table is indexed with Global_Node_ID.
In the IP compatible mode for a TP tunnel, Global_Node_ID In the IP compatible mode for a TP tunnel, Global_Node_ID
is used. is used.
A separate query is made to get the local identifier of both A separate query is made to get the local identifier of both
Ingress and Egress Global_Node_ID identifiers. These local Ingress and Egress Global_Node_ID identifiers. These local
identifiers are used as mplsTunnelIngressLSRId and identifiers are used as mplsTunnelIngressLSRId and
mplsTunnelEgressLSRId, while indexing mplsTunnelTable. mplsTunnelEgressLSRId, while indexing mplsTunnelTable.
6.3. mplsTunnelExtNodeIccMapTable 6.3. mplsTunnelExtNodeIccMapTable
The read-only mplsTunnelExtNodeIccMapTable is used to query the local The read-only mplsTunnelExtNodeIccMapTable is used to query the local
identifier assigned and stored in the mplsTunnelExtNodeConfigTable identifier assigned and stored in the mplsTunnelExtNodeConfigTable
for a given ICC. for a given ICC.
A separate query is made to get the local identifier of both A separate query is made to get the local identifier of both
Ingress and Egress ICC. These local identifiers are used as Ingress and Egress ICC. These local identifiers are used as
mplsTunnelIngressLSRId and mplsTunnelEgressLSRId, mplsTunnelIngressLSRId and mplsTunnelEgressLSRId,
while indexing mplsTunnelTable. while indexing mplsTunnelTable.
6.4.mplsTunnelExtTable 6.4. mplsTunnelExtTable
mplsTunnelExtTable extends the mplsTunnelTable to add MPLS-TP tunnel mplsTunnelExtTable extends the mplsTunnelTable in order to support
specific additional objects. All the additional attributes specific MPLS-TP tunnels with additional objects. All the additional
to TP tunnel are contained in this extended table and could be attributes specific to supporting TP tunnel are contained in this
accessed with the mplsTunnelTable indices. extended table and could be accessed with the mplsTunnelTable
indices.
6.5 mplsTunnelExtReversePerfTable 6.5. mplsTunnelExtReversePerfTable
This table augments the mplsTunnelTable to provide per-tunnel packet This table augments the mplsTunnelTable to provide per-tunnel packet
performance information for the reverse direction of a bidirectional performance information for the reverse direction of a bidirectional
tunnel. It can be seen as supplementing the mplsTunnelPerfTable, tunnel. It can be seen as supplementing the mplsTunnelPerfTable,
which augments the mplsTunnelTable. which augments the mplsTunnelTable.
7. MIB Module Interdependencies 7. MIB Module Interdependencies
This section provides an overview of the relationship between the This section provides an overview of the relationship between the
MPLS-TP TE MIB module and other MPLS MIB modules. MPLS-TP TE MIB module and other MPLS MIB modules.
skipping to change at page 8, line 44 skipping to change at page 11, line 44
backward reference to tunnel entry. backward reference to tunnel entry.
9. Example of MPLS-TP Tunnel Setup 9. Example of MPLS-TP Tunnel Setup
In this section, we provide an example of the IP based MPLS-TP In this section, we provide an example of the IP based MPLS-TP
bidirectional tunnel setup. This example provides the usage of bidirectional tunnel setup. This example provides the usage of
MPLS-TP Tunnel MIB along with the extended new MIB modules introduced MPLS-TP Tunnel MIB along with the extended new MIB modules introduced
in this document. in this document.
Do note that a MPLS-TP tunnel could be setup statically as well as Do note that a MPLS-TP tunnel could be setup statically as well as
signaled via control plane. This example considers accessing MIB signaled via control plane. This example considers accessing MIB
objects on a head-end for a static MPLS-TP tunnel. objects on a head-end for a static and signaling MPLS-TP tunnels.
Only relevant objects which are applicable for MPLS-TP tunnel are Only relevant objects which are applicable for MPLS-TP tunnel are
illustrated here. illustrated here.
In mplsTunnelExtNodeConfigTable: In mplsTunnelExtNodeConfigTable:
{ {
-- Non-IP Ingress LSR-Id (Index to the table) -- Non-IP Ingress LSR-Id (Index to the table)
mplsTunnelExtNodeConfigLocalId = 1, mplsTunnelExtNodeConfigLocalId = 1,
mplsTunnelExtNodeConfigGlobalId = 1234, mplsTunnelExtNodeConfigGlobalId = 1234,
skipping to change at page 9, line 44 skipping to change at page 12, line 44
mplsTunnelExtNodeIpMapNodeId = 10, mplsTunnelExtNodeIpMapNodeId = 10,
mplsTunnelExtNodeIpMapLocalId = 1 mplsTunnelExtNodeIpMapLocalId = 1
-- Global_ID (Index to the table) -- Global_ID (Index to the table)
mplsTunnelExtNodeIpMapGlobalId = 1234, mplsTunnelExtNodeIpMapGlobalId = 1234,
-- Node Identifier (Index to the table) -- Node Identifier (Index to the table)
mplsTunnelExtNodeIpMapNodeId = 20, mplsTunnelExtNodeIpMapNodeId = 20,
mplsTunnelExtNodeIpMapLocalId = 2 mplsTunnelExtNodeIpMapLocalId = 2
} }
9.1 Example of MPLS-TP co-routed bidirectional tunnel setup 9.1. Example of MPLS-TP static co-routed bidirectional tunnel setup
The following denotes the configured co-routed bidirectional The following denotes the configured co-routed bidirectional
tunnel "head" entry: tunnel "head" entry:
9.1.1 mplsTunnelEntry 9.1.1. mplsTunnelEntry
In mplsTunnelTable: In mplsTunnelTable:
{ {
mplsTunnelIndex = 1, mplsTunnelIndex = 1,
mplsTunnelInstance = 1, mplsTunnelInstance = 1,
-- Local map number created in mplsTunnelExtNodeConfigTable for -- Local map number created in mplsTunnelExtNodeConfigTable for
-- Ingress LSR-Id -- Ingress LSR-Id
mplsTunnelIngressLSRId = 1, mplsTunnelIngressLSRId = 1,
skipping to change at page 10, line 38 skipping to change at page 13, line 38
mplsTunnelInstancePriority = 1, mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1, mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0, mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0, mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelRole = head (1), mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here -- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4) mplsTunnelRowStatus = createAndGo (4)
} }
9.1.2 mplsTunnelExtEntry 9.1.2. mplsTunnelExtEntry
-- An MPLS extension table -- An MPLS extension table
In mplsTunnelExtTable: In mplsTunnelExtTable:
{ {
-- This opposite direction tunnel pointer MAY be point to 0.0 -- This opposite direction tunnel pointer MAY be point to 0.0
-- if co-routed bidirectional tunnel is managed by single tunnel -- if co-routed bidirectional tunnel is managed by single tunnel
-- entry -- entry
mplsTunnelExtOppositeDirTnlPtr = 0.0 mplsTunnelExtOppositeDirTnlPtr = 0.0
} -- Set both the Ingress and Egress LocalId objects to TRUE as
-- this tunnel entry uses the local identifiers.
mplsTunnelExtIngressLSRLocalIdValid = true,
mplsTunnelExtEgressLSRLocalIdValid = true
}
We must next create the appropriate in-segment and out-segment We must next create the appropriate in-segment and out-segment
entries. These are done in [RFC3813] using the mplsInSegmentTable entries. These are done in [RFC3813] using the mplsInSegmentTable and
and mplsOutSegmentTable. mplsOutSegmentTable.
9.1.3 Forward direction mplsOutSegmentEntry 9.1.3. Forward direction mplsOutSegmentEntry
For the forward direction. For the forward direction.
In mplsOutSegmentTable: In mplsOutSegmentTable:
{ {
mplsOutSegmentIndex = 0x0000001, mplsOutSegmentIndex = 0x0000001,
mplsOutSegmentInterface = 13, -- outgoing interface mplsOutSegmentInterface = 13, -- outgoing interface
mplsOutSegmentPushTopLabel = true(1), mplsOutSegmentPushTopLabel = true(1),
mplsOutSegmentTopLabel = 22, -- outgoing label mplsOutSegmentTopLabel = 22, -- outgoing label
-- RowPointer MUST point to the first accessible column. -- RowPointer MUST point to the first accessible column.
mplsOutSegmentTrafficParamPtr = 0.0, mplsOutSegmentTrafficParamPtr = 0.0,
mplsOutSegmentRowStatus = createAndGo (4) mplsOutSegmentRowStatus = createAndGo (4)
} }
9.1.4 Reverse direction mplsInSegmentEntry 9.1.4. Reverse direction mplsInSegmentEntry
For the reverse direction. For the reverse direction.
In mplsInSegmentTable: In mplsInSegmentTable:
{ {
mplsInSegmentIndex = 0x0000001 mplsInSegmentIndex = 0x0000001
mplsInSegmentLabel = 21, -- incoming label mplsInSegmentLabel = 21, -- incoming label
mplsInSegmentNPop = 1, mplsInSegmentNPop = 1,
mplsInSegmentInterface = 13, -- incoming interface mplsInSegmentInterface = 13, -- incoming interface
-- RowPointer MUST point to the first accessible column. -- RowPointer MUST point to the first accessible column.
mplsInSegmentTrafficParamPtr = 0.0, mplsInSegmentTrafficParamPtr = 0.0,
mplsInSegmentRowStatus = createAndGo (4) mplsInSegmentRowStatus = createAndGo (4)
} }
Next, two cross-connect entries are created in the mplsXCTable of the Next, two cross-connect entries are created in the mplsXCTable of the
MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
segments together. segments together.
9.1.5 Forward direction mplsXCEntry 9.1.5. Forward direction mplsXCEntry
In mplsXCTable: In mplsXCTable:
{ {
mplsXCIndex = 0x01, mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000000, mplsXCInSegmentIndex = 0x00000000,
mplsXCOutSegmentIndex = 0x00000001, mplsXCOutSegmentIndex = 0x00000001,
mplsXCLspId = 0x0102 -- unique ID mplsXCLspId = 0x0102 -- unique ID
-- only a single outgoing label -- only a single outgoing label
mplsXCLabelStackIndex = 0x00, mplsXCLabelStackIndex = 0x00,
mplsXCRowStatus = createAndGo(4) mplsXCRowStatus = createAndGo(4)
} }
9.1.6 Reverse direction mplsXCEntry 9.1.6. Reverse direction mplsXCEntry
In mplsXCTable: In mplsXCTable:
{ {
mplsXCIndex = 0x01, mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000001, mplsXCInSegmentIndex = 0x00000001,
mplsXCOutSegmentIndex = 0x00000000, mplsXCOutSegmentIndex = 0x00000000,
mplsXCLspId = 0x0102 -- unique ID mplsXCLspId = 0x0102 -- unique ID
-- only a single outgoing label -- only a single outgoing label
mplsXCLabelStackIndex = 0x00, mplsXCLabelStackIndex = 0x00,
mplsXCRowStatus = createAndGo(4) mplsXCRowStatus = createAndGo(4)
} }
This table entry is extended by entry in the This table entry is extended by entry in the
mplsXCExtTable. Note that the nature of the 'extends' mplsXCExtTable. Note that the nature of the 'extends'
relationship is a sparse augmentation so that the entry in the relationship is a sparse augmentation so that the entry in the
mplsXCExtTable has the same index values as the entry in mplsXCExtTable has the same index values as the entry in
the mplsXCTable. the mplsXCTable.
9.1.5 Forward direction mplsXCExtEntry 9.1.7. Forward direction mplsXCExtEntry
In mplsXCExtTable (0x01, 0x00000000, 0x00000001) In mplsXCExtTable (0x01, 0x00000000, 0x00000001)
{ {
-- Back pointer from XC table to Tunnel table -- Back pointer from XC table to Tunnel table
mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2
mplsXCExtOppositeDirXCPtr = mplsXCExtOppositeDirXCPtr =
mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0 mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0
} }
9.1.6 Reverse direction mplsXCExtEntry 9.1.8. Reverse direction mplsXCExtEntry
Next for the reverse direction: Next for the reverse direction:
In mplsXCExtTable (0x01, 0x00000001, 0x00000000) In mplsXCExtTable (0x01, 0x00000001, 0x00000000)
{ {
-- Back pointer from XC table to Tunnel table -- Back pointer from XC table to Tunnel table
mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2
mplsXCExtOppositeDirXCPtr = mplsXCExtOppositeDirXCPtr =
mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1 mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1
} }
9.1.7 mplsTunnelExtReversePerfTable 9.1.9. mplsTunnelExtReversePerfTable
The mplsTunnelExtReversePerfTable SHOULD be populated incase The mplsTunnelExtReversePerfTable SHOULD be populated incase
the single tunnel entry is used for co-routed bidirectional tunnel the single tunnel entry is used for co-routed bidirectional tunnel
setup. The mplsTunnelPerfTable will have the forward direction setup. The mplsTunnelPerfTable will have the forward direction
LSP performance counters and mplsTunnelExtReversePerfTable will have LSP performance counters and mplsTunnelExtReversePerfTable will have
the reverse direction LSP performance counters. the reverse direction LSP performance counters.
9.2 Example of MPLS-TP associated bidirectional tunnel setup 9.2. Example of MPLS-TP static associated bidirectional tunnel setup
The MPLS-TP associated bidirectional tunnel has two different The MPLS-TP associated bidirectional tunnel has two different
direction tunnels[Forward and Reverse LSPs] and these are direction tunnels[Forward and Reverse LSPs] and these are
associated together using mplsTunnelExtTable. Two different associated together using mplsTunnelExtTable. Two different
tunnel entries for both forward and reverse direction MAY be used tunnel entries for both forward and reverse direction MAY be used
for co-routed bidirectional tunnel as well. for co-routed bidirectional tunnel as well.
The following denotes the configured associated bidirectional The following denotes the configured associated bidirectional forward
forward tunnel "head" entry: tunnel "head" entry:
9.2.1 Forward direction mplsTunnelEntry 9.2.1. Forward direction mplsTunnelEntry
In mplsTunnelTable: In mplsTunnelTable:
{ {
mplsTunnelIndex = 1, mplsTunnelIndex = 1,
mplsTunnelInstance = 1, mplsTunnelInstance = 1,
-- Local map number created in mplsTunnelExtNodeConfigTable for -- Local map number created in mplsTunnelExtNodeConfigTable for
-- Ingress LSR-Id -- Ingress LSR-Id
mplsTunnelIngressLSRId = 1, mplsTunnelIngressLSRId = 1,
skipping to change at page 14, line 4 skipping to change at page 17, line 7
mplsTunnelSessionAttributes = 0, mplsTunnelSessionAttributes = 0,
mplsTunnelLocalProtectInUse = false (0), mplsTunnelLocalProtectInUse = false (0),
-- RowPointer MUST point to the first accessible column -- RowPointer MUST point to the first accessible column
mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5, mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5,
mplsTunnelInstancePriority = 1, mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1, mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0, mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0, mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelRole = head (1), mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here -- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4) mplsTunnelRowStatus = createAndGo (4)
} }
9.2.2 Forward direction mplsTunnelExtEntry 9.2.2. Forward direction mplsTunnelExtEntry
For Associated bidirectional forward LSP, For Associated bidirectional forward LSP,
In mplsTunnelExtTable: In mplsTunnelExtTable:
{ {
mplsTunnelExtOppositeDirPtr.1.1.1.2 = mplsTunnelName.2.1.2.1 mplsTunnelExtOppositeDirPtr = mplsTunnelName.2.1.2.1
-- Set both the Ingress and Egress LocalId objects to TRUE as
-- this tunnel entry uses the local identifiers.
mplsTunnelExtIngressLSRLocalIdValid = true,
mplsTunnelExtEgressLSRLocalIdValid = true
} }
9.2.3 Forward direction mplsOutSegmentTable 9.2.3. Forward direction mplsOutSegmentTable
For the forward direction. For the forward direction.
In mplsOutSegmentTable: In mplsOutSegmentTable:
{ {
mplsOutSegmentIndex = 0x0000001, mplsOutSegmentIndex = 0x0000001,
mplsOutSegmentInterface = 13, -- outgoing interface mplsOutSegmentInterface = 13, -- outgoing interface
mplsOutSegmentPushTopLabel = true(1), mplsOutSegmentPushTopLabel = true(1),
mplsOutSegmentTopLabel = 22, -- outgoing label mplsOutSegmentTopLabel = 22, -- outgoing label
-- RowPointer MUST point to the first accessible column. -- RowPointer MUST point to the first accessible column.
mplsOutSegmentTrafficParamPtr = 0.0, mplsOutSegmentTrafficParamPtr = 0.0,
mplsOutSegmentRowStatus = createAndGo (4) mplsOutSegmentRowStatus = createAndGo (4)
} }
9.2.4 Forward direction mplsXCEntry 9.2.4. Forward direction mplsXCEntry
In mplsXCTable: In mplsXCTable:
{ {
mplsXCIndex = 0x01, mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000000, mplsXCInSegmentIndex = 0x00000000,
mplsXCOutSegmentIndex = 0x00000001, mplsXCOutSegmentIndex = 0x00000001,
mplsXCLspId = 0x0102 -- unique ID mplsXCLspId = 0x0102 -- unique ID
-- only a single outgoing label -- only a single outgoing label
mplsXCLabelStackIndex = 0x00, mplsXCLabelStackIndex = 0x00,
mplsXCRowStatus = createAndGo(4) mplsXCRowStatus = createAndGo(4)
} }
9.2.5 Forward direction mplsXCExtEntry 9.2.5. Forward direction mplsXCExtEntry
In mplsXCExtTable (0x01, 0x00000000, 0x00000001) In mplsXCExtTable (0x01, 0x00000000, 0x00000001)
{ {
-- Back pointer from XC table to Tunnel table -- Back pointer from XC table to Tunnel table
mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2
mplsXCExtOppositeDirXCPtr = mplsXCExtOppositeDirXCPtr =
mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0 mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0
} }
9.2.6 Forward direction mplsTunnelEntry 9.2.6. Reverse direction mplsTunnelEntry
The following denotes the configured associated bidirectional The following denotes the configured associated bidirectional reverse
reverse tunnel "tail" entry: tunnel "tail" entry:
In mplsTunnelTable: In mplsTunnelTable:
{ {
mplsTunnelIndex = 2, mplsTunnelIndex = 2,
mplsTunnelInstance = 1, mplsTunnelInstance = 1,
-- Local map number created in mplsTunnelExtNodeConfigTable for -- Local map number created in mplsTunnelExtNodeConfigTable for
-- Ingress LSR-Id -- Ingress LSR-Id
mplsTunnelIngressLSRId = 2, mplsTunnelIngressLSRId = 2,
-- Local map number created in mplsTunnelExtNodeConfigTable for -- Local map number created in mplsTunnelExtNodeConfigTable for
skipping to change at page 15, line 49 skipping to change at page 19, line 7
mplsTunnelInstancePriority = 1, mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1, mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0, mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0, mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0, mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelRole = head (1), mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here -- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4) mplsTunnelRowStatus = createAndGo (4)
} }
9.2.7 Reverse direction mplsTunnelExtEntry 9.2.7. Reverse direction mplsTunnelExtEntry
For Associated bidirectional reverse LSP, For Associated bidirectional reverse LSP,
In mplsTunnelExtTable: In mplsTunnelExtTable:
{ {
mplsTunnelExtOppositeDirPtr.2.1.2.1 = mplsTunnelName.1.1.1.2 mplsTunnelExtOppositeDirPtr = mplsTunnelName.1.1.1.2
-- Set both the Ingress and Egress LocalId objects to TRUE as
-- this tunnel entry uses the local identifiers.
mplsTunnelExtIngressLSRLocalIdValid = true,
mplsTunnelExtEgressLSRLocalIdValid = true
} }
9.2.8 Reverse direction mplsInSegmentEntry 9.2.8. Reverse direction mplsInSegmentEntry
We must next create the appropriate in-segment and out-segment We must next create the appropriate in-segment and out-segment
entries. These are done in [RFC3813] using the mplsInSegmentTable entries. These are done in [RFC3813] using the mplsInSegmentTable and
and mplsOutSegmentTable. mplsOutSegmentTable.
In mplsInSegmentTable: In mplsInSegmentTable:
{ {
mplsInSegmentIndex = 0x0000001 mplsInSegmentIndex = 0x0000001
mplsInSegmentLabel = 21, -- incoming label mplsInSegmentLabel = 21, -- incoming label
mplsInSegmentNPop = 1, mplsInSegmentNPop = 1,
mplsInSegmentInterface = 13, -- incoming interface mplsInSegmentInterface = 13, -- incoming interface
-- RowPointer MUST point to the first accessible column. -- RowPointer MUST point to the first accessible column.
mplsInSegmentTrafficParamPtr = 0.0, mplsInSegmentTrafficParamPtr = 0.0,
mplsInSegmentRowStatus = createAndGo (4) mplsInSegmentRowStatus = createAndGo (4)
} }
Next, two cross-connect entries are created in the mplsXCTable of the Next, two cross-connect entries are created in the mplsXCTable of the
MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
segments together. segments together.
9.2.9 Reverse direction mplsXCEntry 9.2.9. Reverse direction mplsXCEntry
In mplsXCTable: In mplsXCTable:
{ {
mplsXCIndex = 0x01, mplsXCIndex = 0x01,
mplsXCInSegmentIndex = 0x00000001, mplsXCInSegmentIndex = 0x00000001,
mplsXCOutSegmentIndex = 0x00000000, mplsXCOutSegmentIndex = 0x00000000,
mplsXCLspId = 0x0102 -- unique ID mplsXCLspId = 0x0102 -- unique ID
-- only a single outgoing label -- only a single outgoing label
mplsXCLabelStackIndex = 0x00, mplsXCLabelStackIndex = 0x00,
mplsXCRowStatus = createAndGo(4) mplsXCRowStatus = createAndGo(4)
} }
This table entry is extended by entry in the This table entry is extended by entry in the
mplsXCExtTable. Note that the nature of the 'extends' mplsXCExtTable. Note that the nature of the 'extends'
relationship is a sparse augmentation so that the entry in the relationship is a sparse augmentation so that the entry in the
mplsXCExtTable has the same index values as the entry in mplsXCExtTable has the same index values as the entry in
the mplsXCTable. the mplsXCTable.
9.2.10 Reverse direction mplsXCExtEntry 9.2.10. Reverse direction mplsXCExtEntry
Next for the reverse direction: Next for the reverse direction:
In mplsXCExtTable (0x01, 0x00000001, 0x00000000) In mplsXCExtTable (0x01, 0x00000001, 0x00000000)
{ {
-- Back pointer from XC table to Tunnel table -- Back pointer from XC table to Tunnel table
mplsXCExtTunnelPointer = mplsTunnelName.1.1.1.2 mplsXCExtTunnelPointer = mplsTunnelName.2.1.2.1
mplsXCExtOppositeDirXCPtr = mplsXCExtOppositeDirXCPtr =
mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1 mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1
} }
9.3. Example of MPLS-TP signaling co-routed bidirectional tunnel setup
The following denotes the configured co-routed bidirectional
tunnel "head" entry and in intermediate and tail-end nodes,
the tunnel table and its associated tables are created
by the local management subsystem (e.g. agent) when the MPLS TP
tunnel is signaled successfully. Refer [RFC3812] and [RFC4802]
for signaling tunnel table configuration examples.
9.3.1. mplsTunnelEntry
In mplsTunnelTable:
{
mplsTunnelIndex = 1,
mplsTunnelInstance = 0,
-- Local map number created in mplsTunnelExtNodeConfigTable for
-- Ingress LSR-Id, for the intermediate and tail-end nodes,
-- the local management entity is expected to pick a first available
-- local identifier which is not used in mplsTunnelTable.
mplsTunnelIngressLSRId = 1,
-- Local map number created in mplsTunnelExtNodeConfigTable for
-- Egress LSR-Id
mplsTunnelEgressLSRId = 2,
mplsTunnelName = "TP co-routed bidirectional LSP",
mplsTunnelDescr = "East to West",
mplsTunnelIsIf = true (1),
-- RowPointer MUST point to the first accessible column
mplsTunnelXCPointer =
mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,
mplsTunnelSignallingProto = none (1),
mplsTunnelSetupPrio = 0,
mplsTunnelHoldingPrio = 0,
mplsTunnelSessionAttributes = 0,
mplsTunnelLocalProtectInUse = false (0),
-- RowPointer MUST point to the first accessible column
mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.5,
mplsTunnelInstancePriority = 1,
mplsTunnelHopTableIndex = 1,
mplsTunnelIncludeAnyAffinity = 0,
mplsTunnelIncludeAllAffinity = 0,
mplsTunnelExcludeAnyAffinity = 0,
mplsTunnelRole = head (1),
-- Mandatory parameters needed to activate the row go here
mplsTunnelRowStatus = createAndGo (4)
}
9.3.2. mplsTunnelExtEntry
-- An MPLS extension table
In mplsTunnelExtTable:
{
-- This opposite direction tunnel pointer MAY be point to 0.0
-- if co-routed bidirectional tunnel is managed by single tunnel
-- entry
mplsTunnelExtOppositeDirTnlPtr = 0.0
-- Set both the Ingress and Egress LocalId objects to TRUE as
-- this tunnel entry uses the local identifiers.
mplsTunnelExtIngressLSRLocalIdValid = true,
mplsTunnelExtEgressLSRLocalIdValid = true
}
We must next create the appropriate in-segment and out-segment
entries. These are done in [RFC3813] using the mplsInSegmentTable and
mplsOutSegmentTable.
9.3.3. Forward direction mplsOutSegmentEntry
The forward direction mplsOutSegmentTable will be populated
automatically based on the information received from the signaling
protocol.
9.3.4. Reverse direction mplsInSegmentEntry
The reverse direction mplsOutSegmentTable will be populated
automatically based on the information received from the signaling
protocol.
Next, two cross-connect entries are created in the mplsXCTable of the
MPLS-LSR-STD-MIB [RFC3813], thereby associating the newly created
segments together.
9.3.5. Forward direction mplsXCEntry
The forward direction mplsXCEntry will be populated as soon as the
forward path label information is available.
9.3.6. Reverse direction mplsXCEntry
The reverse direction mplsXCEntry will be populated as soon as the
reverse path label information is available.
This table entry is extended by entry in the mplsXCExtTable. Note
that the nature of the 'extends' relationship is a sparse
augmentation so that the entry in the mplsXCExtTable has the same
index values as the entry in the mplsXCTable.
9.3.7. Forward direction mplsXCExtEntry
Once the forward path information is negotiated using signaling
protocol, the forward direction mplsXCExtEntry will be created for
associating the opposite direction XC entry and tunnel table entry.
9.3.8. Reverse direction mplsXCExtEntry
Once the reverse path information is negotiated using signaling
protocol, the reverse direction mplsXCExtEntry will be created for
associating the opposite direction XC entry and tunnel table entry.
9.3.9. mplsTunnelExtReversePerfTable
The mplsTunnelExtReversePerfTable SHOULD be populated incase the
single tunnel entry is used for co-routed bidirectional tunnel setup.
The mplsTunnelPerfTable will have the forward direction LSP
performance counters and mplsTunnelExtReversePerfTable will have the
reverse direction LSP performance counters.
10. MPLS Textual Convention Extension MIB definitions 10. MPLS Textual Convention Extension MIB definitions
MPLS-TC-EXT-STD-MIB DEFINITIONS ::= BEGIN MPLS-TC-EXT-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, Unsigned32 MODULE-IDENTITY, Unsigned32
FROM SNMPv2-SMI -- [RFC2578] FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC -- [RFC2579] FROM SNMPv2-TC -- [RFC2579]
mplsStdMIB mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811] FROM MPLS-TC-STD-MIB -- [RFC3811]
; ;
mplsTcExtStdMIB MODULE-IDENTITY mplsTcExtStdMIB MODULE-IDENTITY
LAST-UPDATED LAST-UPDATED
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO CONTACT-INFO
" "
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc, Dell Inc,
350 Holger way, San Jose, CA, USA 350 Holger way, San Jose, CA, USA
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Kannan KV Sampath Kannan KV Sampath
Aricent, Redeem,
India India
Email: Kannan.Sampath@aricent.com Email: kannankvs@gmail.com
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
10 Technology Park Drive, 10 Technology Park Drive,
Westford, MA 01886 Westford, MA 01886
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
" "
DESCRIPTION DESCRIPTION
"Copyright (c) 2012 IETF Trust and the persons identified "Copyright (c) 2013 IETF Trust and the persons identified
as the document authors. All rights reserved. as the document authors. All rights reserved.
This MIB module contains Textual Conventions for This MIB module contains Textual Conventions for
MPLS based transport networks." MPLS based transport networks."
-- Revision history. -- Revision history.
REVISION REVISION
"201207150000Z" -- July 15, 2012
"201301140000Z" -- January 14, 2013
DESCRIPTION DESCRIPTION
"MPLS Textual Convention Extensions" "MPLS Textual Convention Extensions"
::= { mplsStdMIB xxx } -- xxx to be replaced with correct value ::= { mplsStdMIB xxx } -- xxx to be replaced with correct value
MplsGlobalId ::= TEXTUAL-CONVENTION MplsGlobalId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object contains the Textual Convention of IP based "This object contains the Textual Convention of IP based
skipping to change at page 19, line 5 skipping to change at page 24, line 38
When the Global_ID is derived from a 2-octet AS number, When the Global_ID is derived from a 2-octet AS number,
the two high-order octets of this 4-octet identifier the two high-order octets of this 4-octet identifier
MUST be set to zero. MUST be set to zero.
Further ASN 0 is reserved. A Global_ID of zero means Further ASN 0 is reserved. A Global_ID of zero means
that no Global_ID is present. Note that a Global_ID of that no Global_ID is present. Note that a Global_ID of
zero is limited to entities contained within a single zero is limited to entities contained within a single
operator and MUST NOT be used across an NNI. operator and MUST NOT be used across an NNI.
A non-zero Global_ID MUST be derived from an ASN owned by A non-zero Global_ID MUST be derived from an ASN owned by
the operator." the operator."
REFERENCE
"MPLS Transport Profile (MPLS-TP) Identifiers, [RFC6370]
Section 3 Uniquely Identifying an Operator - the Global_ID"
SYNTAX OCTET STRING (SIZE (4)) SYNTAX OCTET STRING (SIZE (4))
MplsNodeId ::= TEXTUAL-CONVENTION MplsNodeId ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d" DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Node_ID is assigned within the scope of the Global_ID. "The Node_ID is assigned within the scope of the Global_ID.
The value 0(or 0.0.0.0 in dotted decimal notation) is The value 0(or 0.0.0.0 in dotted decimal notation) is
reserved and MUST NOT be used. reserved and MUST NOT be used.
When IPv4 addresses are in use, the value of this object When IPv4 addresses are in use, the value of this object
can be derived from the LSR's IPv4 loop back address. can be derived from the LSR's IPv4 loop back address.
When IPv6 addresses are in use, the value of this object When IPv6 addresses are in use, the value of this object
can be a 32-bit value unique within the scope of can be a 32-bit value unique within the scope of
a Global_ID. a Global_ID.
Note that, when IP reach ability is not needed, the 32-bit Note that, when IP reach ability is not needed, the 32-bit
Node_ID is not required to have any association Node_ID is not required to have any association
with the IPv4 address space." with the IPv4 address space."
SYNTAX Unsigned32 REFERENCE
"MPLS Transport Profile (MPLS-TP) Identifiers, [RFC6370],
Section 4. Node and Interface Identifiers"
SYNTAX Unsigned32 -- the default range: (0..4294967295)
MplsIccId ::= TEXTUAL-CONVENTION MplsIccId ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The ICC is a string of one to six characters, each "The ICC is a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or character being either alphabetic (i.e. A-Z) or
numeric (i.e. 0-9) characters. numeric (i.e. 0-9) characters.
Alphabetic characters in the ICC SHOULD be represented Alphabetic characters in the ICC SHOULD be represented
with upper case letters." with upper case letters."
SYNTAX OCTET STRING (SIZE (1..6)) REFERENCE
"MPLS-TP Identifiers Following ITU-T Conventions,
[I-D.ietf-mpls-tp-itu-t-identifiers], Section 3.
Uniquely Identifying an Operator - the ICC_Operator_ID"
SYNTAX OCTET STRING (SIZE (1..6))
-- MPLS-TC-EXT-STD-MIB module ends -- MPLS-TC-EXT-STD-MIB module ends
END END
11. MPLS Identifier MIB definitions 11. MPLS Identifier MIB definitions
MPLS-ID-STD-MIB DEFINITIONS ::= BEGIN MPLS-ID-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE MODULE-IDENTITY, OBJECT-TYPE
skipping to change at page 20, line 9 skipping to change at page 26, line 4
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580] FROM SNMPv2-CONF -- [RFC2580]
mplsStdMIB mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811] FROM MPLS-TC-STD-MIB -- [RFC3811]
MplsGlobalId, MplsIccId, MplsNodeId MplsGlobalId, MplsIccId, MplsNodeId
FROM MPLS-TC-EXT-STD-MIB FROM MPLS-TC-EXT-STD-MIB
; ;
mplsIdStdMIB MODULE-IDENTITY mplsIdStdMIB MODULE-IDENTITY
LAST-UPDATED LAST-UPDATED
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO CONTACT-INFO
" "
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc, Dell Inc,
350 Holger way, San Jose, CA, USA 350 Holger way, San Jose, CA, USA
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Kannan KV Sampath Kannan KV Sampath
Aricent,
Redeem,
India India
Email: Kannan.Sampath@aricent.com Email: kannankvs@gmail.com
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
10 Technology Park Drive, 10 Technology Park Drive,
Westford, MA 01886 Westford, MA 01886
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
" "
DESCRIPTION DESCRIPTION
"Copyright (c) 2012 IETF Trust and the persons identified "Copyright (c) 2013 IETF Trust and the persons identified
as the document authors. All rights reserved. as the document authors. All rights reserved.
This MIB module contains generic object definitions for This MIB module contains generic object definitions for
MPLS Traffic Engineering in transport networks." MPLS Traffic Engineering in transport networks."
-- Revision history. -- Revision history.
REVISION REVISION
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
DESCRIPTION DESCRIPTION
"MPLS identifiers MIB object extension" "This MIB modules defines the MIB objects for MPLS-TP
identifiers"
::= { mplsStdMIB xxx } -- xxx to be replaced with correct value ::= { mplsStdMIB xxx } -- xxx to be replaced with correct value
-- Notifications -- Notifications
mplsIdNotifications OBJECT IDENTIFIER ::= { mplsIdStdMIB 0 } mplsIdNotifications OBJECT IDENTIFIER ::= { mplsIdStdMIB 0 }
-- tables, scalars -- tables, scalars
mplsIdObjects OBJECT IDENTIFIER ::= { mplsIdStdMIB 1 } mplsIdObjects OBJECT IDENTIFIER ::= { mplsIdStdMIB 1 }
-- conformance -- conformance
mplsIdConformance OBJECT IDENTIFIER ::= { mplsIdStdMIB 2 } mplsIdConformance OBJECT IDENTIFIER ::= { mplsIdStdMIB 2 }
-- MPLS common objects -- MPLS common objects
mplsIdGlobalId OBJECT-TYPE mplsIdGlobalId OBJECT-TYPE
SYNTAX MplsGlobalId SYNTAX MplsGlobalId
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object allows the administrator to assign a unique
"This object allows the operator to assign a unique
operator identifier also called MPLS-TP Global_ID." operator identifier also called MPLS-TP Global_ID."
REFERENCE
"MPLS-TP Identifiers [RFC6370]."
::= { mplsIdObjects 1 } ::= { mplsIdObjects 1 }
mplsIdIcc OBJECT-TYPE mplsIdIcc OBJECT-TYPE
SYNTAX MplsIccId SYNTAX MplsIccId
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object allows the operator or service provider to "This object allows the operator or service provider to
assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a
network." network."
REFERENCE
"MPLS-TP Identifiers [RFC6370]."
::= { mplsIdObjects 2 } ::= { mplsIdObjects 2 }
mplsIdNodeId OBJECT-TYPE mplsIdNodeId OBJECT-TYPE
SYNTAX MplsNodeId SYNTAX MplsNodeId
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object allows the operator or service provider to "This object allows the operator or service provider to
assign a unique MPLS-TP Node_ID. assign a unique MPLS-TP Node_ID.
The Node_ID is assigned within the scope of The Node_ID is assigned within the scope of
the Global_ID." the Global_ID."
REFERENCE
"MPLS-TP Identifiers [RFC6370]."
::= { mplsIdObjects 3 } ::= { mplsIdObjects 3 }
-- Module compliance. -- Module compliance.
mplsIdGroups mplsIdGroups
OBJECT IDENTIFIER ::= { mplsIdConformance 1 } OBJECT IDENTIFIER ::= { mplsIdConformance 1 }
mplsIdCompliances mplsIdCompliances
OBJECT IDENTIFIER ::= { mplsIdConformance 2 } OBJECT IDENTIFIER ::= { mplsIdConformance 2 }
skipping to change at page 23, line 35 skipping to change at page 30, line 19
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE MODULE-IDENTITY, OBJECT-TYPE
FROM SNMPv2-SMI -- [RFC2578] FROM SNMPv2-SMI -- [RFC2578]
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580] FROM SNMPv2-CONF -- [RFC2580]
mplsStdMIB mplsStdMIB
FROM MPLS-TC-STD-MIB -- [RFC3811] FROM MPLS-TC-STD-MIB -- [RFC3811]
RowPointer RowPointer
FROM SNMPv2-TC -- [RFC2579] FROM SNMPv2-TC -- [RFC2579]
mplsXCIndex, mplsXCInSegmentIndex, mplsXCOutSegmentIndex, mplsXCIndex, mplsXCInSegmentIndex, mplsXCOutSegmentIndex,
mplsInSegmentGroup, mplsOutSegmentGroup, mplsXCGroup, mplsInterfaceGroup, mplsInSegmentGroup, mplsOutSegmentGroup,
mplsPerfGroup, mplsLsrNotificationGroup mplsXCGroup, mplsPerfGroup, mplsLsrNotificationGroup
FROM MPLS-LSR-STD-MIB; -- [RFC3813] FROM MPLS-LSR-STD-MIB; -- [RFC3813]
mplsLsrExtStdMIB MODULE-IDENTITY mplsLsrExtStdMIB MODULE-IDENTITY
LAST-UPDATED LAST-UPDATED
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO CONTACT-INFO
" "
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc, Dell Inc,
350 Holger way, San Jose, CA, USA 350 Holger way, San Jose, CA, USA
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Kannan KV Sampath Kannan KV Sampath
Aricent, Redeem,
India India
Email: Kannan.Sampath@aricent.com Email: kannankvs@gmail.com
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
10 Technology Park Drive, Westford, MA 01886 10 Technology Park Drive, Westford, MA 01886
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
" "
DESCRIPTION DESCRIPTION
"Copyright (c) 2012 IETF Trust and the persons identified "Copyright (c) 2013 IETF Trust and the persons identified
as the document authors. All rights reserved. as the document authors. All rights reserved.
This MIB module contains generic object definitions for This MIB module contains generic object definitions for
MPLS LSR in transport networks." MPLS LSR in transport networks."
-- Revision history. -- Revision history.
REVISION REVISION
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
DESCRIPTION DESCRIPTION
"MPLS LSR specific MIB objects extension" "MPLS LSR specific MIB objects extension"
::= { mplsStdMIB xxx } -- xxx to be replaced with correct value ::= { mplsStdMIB xxx } -- xxx to be replaced with correct value
-- Notifications -- Notifications
mplsLsrExtNotifications OBJECT IDENTIFIER mplsLsrExtNotifications OBJECT IDENTIFIER
::= { mplsLsrExtStdMIB 0 } ::= { mplsLsrExtStdMIB 0 }
-- tables, scalars -- tables, scalars
mplsLsrExtObjects OBJECT IDENTIFIER mplsLsrExtObjects OBJECT IDENTIFIER
skipping to change at page 25, line 12 skipping to change at page 31, line 41
mplsXCExtTable OBJECT-TYPE mplsXCExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsXCExtEntry SYNTAX SEQUENCE OF MplsXCExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table sparse augments the mplsXCTable of "This table sparse augments the mplsXCTable of
MPLS-LSR-STD-MIB [RFC3813] to provide MPLS-TP specific MPLS-LSR-STD-MIB [RFC3813] to provide MPLS-TP specific
information about associated tunnel information" information about associated tunnel information"
REFERENCE REFERENCE
"1. Multiprotocol Label Switching (MPLS) Label Switching "1. Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB), RFC 3813." Router (LSR) Management Information Base (MIB), RFC 3813,
Section 5.7. mplsXCTable"
::= { mplsLsrExtObjects 1 } ::= { mplsLsrExtObjects 1 }
mplsXCExtEntry OBJECT-TYPE mplsXCExtEntry OBJECT-TYPE
SYNTAX MplsXCExtEntry SYNTAX MplsXCExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entry in this table extends the cross connect "An entry in this table extends the cross connect
information represented by an entry in information represented by an entry in
the mplsXCTable in MPLS-LSR-STD-MIB [RFC3813] through the mplsXCTable in MPLS-LSR-STD-MIB [RFC3813] through
a sparse augmentation. An entry can be created by a sparse augmentation. An entry can be created by
a network administrator via SNMP SET commands, or in a network operator via SNMP SET commands, or in
response to signaling protocol events." response to signaling protocol events."
REFERENCE REFERENCE
"1. Multiprotocol Label Switching (MPLS) Label Switching "1. Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB), RFC 3813." Router (LSR) Management Information Base (MIB), RFC 3813,
Section 10. mplsXCTable"
INDEX { mplsXCIndex, mplsXCInSegmentIndex, INDEX { mplsXCIndex, mplsXCInSegmentIndex,
mplsXCOutSegmentIndex } mplsXCOutSegmentIndex }
::= { mplsXCExtTable 1 } ::= { mplsXCExtTable 1 }
MplsXCExtEntry ::= SEQUENCE { MplsXCExtEntry ::= SEQUENCE {
mplsXCExtTunnelPointer RowPointer, mplsXCExtTunnelPointer RowPointer,
mplsXCExtOppositeDirXCPtr RowPointer mplsXCExtOppositeDirXCPtr RowPointer
} }
mplsXCExtTunnelPointer OBJECT-TYPE mplsXCExtTunnelPointer OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This read-only object indicates the back pointer to "This read-only object indicates the back pointer to
the tunnel entry segment." the tunnel entry segment."
REFERENCE REFERENCE
"1. Multiprotocol Label Switching (MPLS) Label Switching "1. Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB), RFC 3813." Router (LSR) Management Information Base (MIB), RFC 3813,
Section 10. mplsXCTable"
::= { mplsXCExtEntry 1 } ::= { mplsXCExtEntry 1 }
mplsXCExtOppositeDirXCPtr OBJECT-TYPE mplsXCExtOppositeDirXCPtr OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object indicates the pointer to the opposite "This object indicates the pointer to the opposite
direction XC entry. This object cannot be modified if direction XC entry. This object cannot be modified if
mplsXCRowStatus for the corresponding entry in the mplsXCRowStatus for the corresponding entry in the
mplsXCTable is active(1)." mplsXCTable is active(1)."
REFERENCE REFERENCE
"1. Multiprotocol Label Switching (MPLS) Label Switching "1. Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB), RFC 3813." Router (LSR) Management Information Base (MIB), RFC 3813,
Section 10. mplsXCTable"
::= { mplsXCExtEntry 2 } ::= { mplsXCExtEntry 2 }
mplsLsrExtGroups mplsLsrExtGroups
OBJECT IDENTIFIER ::= { mplsLsrExtConformance 1 } OBJECT IDENTIFIER ::= { mplsLsrExtConformance 1 }
mplsLsrExtCompliances mplsLsrExtCompliances
OBJECT IDENTIFIER ::= { mplsLsrExtConformance 2 } OBJECT IDENTIFIER ::= { mplsLsrExtConformance 2 }
-- Compliance requirement for fully compliant implementations. -- Compliance requirement for fully compliant implementations.
mplsLsrExtModuleFullCompliance MODULE-COMPLIANCE mplsLsrExtModuleFullCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Compliance statement for agents that provide full support "Compliance statement for agents that provide full support
for MPLS-LSR-EXT-STD-MIB. for MPLS-LSR-EXT-STD-MIB.
skipping to change at page 27, line 40 skipping to change at page 34, line 30
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { MANDATORY-GROUPS {
mplsXCExtGroup mplsXCExtGroup
} }
OBJECT mplsXCExtTunnelPointer OBJECT mplsXCExtTunnelPointer
SYNTAX RowPointer SYNTAX RowPointer
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"The only valid value for Tunnel Pointer is mplsTunnelTable "The only valid value for Tunnel Pointer is
entry." mplsTunnelTable entry."
::= { mplsLsrExtCompliances 2 } OBJECT mplsXCExtOppositeDirXCPtr
SYNTAX RowPointer
MIN-ACCESS read-only
DESCRIPTION
"The only valid value for XC Pointer is
mplsXCTable entry."
::= { mplsLsrExtCompliances 2 }
mplsXCExtGroup OBJECT-GROUP mplsXCExtGroup OBJECT-GROUP
OBJECTS { OBJECTS {
mplsXCExtTunnelPointer, mplsXCExtTunnelPointer,
mplsXCExtOppositeDirXCPtr mplsXCExtOppositeDirXCPtr
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object should be supported in order to access "This object should be supported in order to access
the tunnel entry from XC entry." the tunnel entry from XC entry."
skipping to change at page 28, line 36 skipping to change at page 35, line 35
mplsStdMIB, MplsTunnelIndex, MplsTunnelInstanceIndex, mplsStdMIB, MplsTunnelIndex, MplsTunnelInstanceIndex,
MplsExtendedTunnelId MplsExtendedTunnelId
FROM MPLS-TC-STD-MIB -- [RFC3811] FROM MPLS-TC-STD-MIB -- [RFC3811]
mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId,
mplsTunnelEgressLSRId mplsTunnelEgressLSRId
FROM MPLS-TE-STD-MIB -- [RFC3812] FROM MPLS-TE-STD-MIB -- [RFC3812]
; ;
mplsTeExtStdMIB MODULE-IDENTITY mplsTeExtStdMIB MODULE-IDENTITY
LAST-UPDATED LAST-UPDATED
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO CONTACT-INFO
" "
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc, Dell Inc,
350 Holger way, San Jose, CA, USA 350 Holger way, San Jose, CA, USA
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Kannan KV Sampath Kannan KV Sampath
Aricent, Redeem,
India India
Email: kannankvs@gmail.com
Email: Kannan.Sampath@aricent.com
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
10 Technology Park Drive, Westford, MA 01886 10 Technology Park Drive, Westford, MA 01886
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
" "
DESCRIPTION DESCRIPTION
"Copyright (c) 2012 IETF Trust and the persons identified "Copyright (c) 2013 IETF Trust and the persons identified
as the document authors. All rights reserved. as the document authors. All rights reserved.
This MIB module contains generic object definitions for This MIB module contains generic object definitions for
MPLS Traffic Engineering in transport networks." MPLS Traffic Engineering in transport networks."
-- Revision history. -- Revision history.
REVISION REVISION
"201207150000Z" -- July 15, 2012 "201301140000Z" -- January 14, 2013
DESCRIPTION DESCRIPTION
"MPLS TE MIB objects extension" "MPLS TE MIB objects extension"
::= { mplsStdMIB xxx } -- xxx to be replaced ::= { mplsStdMIB xxx } -- xxx to be replaced
-- with correct value -- with correct value
-- Top level components of this MIB module. -- Top level components of this MIB module.
-- Notifications -- Notifications
skipping to change at page 30, line 6 skipping to change at page 36, line 49
-- conformance -- conformance
mplsTeExtConformance OBJECT IDENTIFIER mplsTeExtConformance OBJECT IDENTIFIER
::= { mplsTeExtStdMIB 2 } ::= { mplsTeExtStdMIB 2 }
-- Start of MPLS Transport Profile Node configuration table -- Start of MPLS Transport Profile Node configuration table
mplsTunnelExtNodeConfigTable OBJECT-TYPE mplsTunnelExtNodeConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtNodeConfigEntry SYNTAX SEQUENCE OF MplsTunnelExtNodeConfigEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table allows the administrator to map a node or "This table allows the operator to map a node or
LSR Identifier (IP compatible [Global_Node_ID] or ICC) LSR Identifier (IP compatible [Global_Node_ID] or ICC)
with a local identifier. with a local identifier.
This table is created to reuse the existing This table is created to reuse the existing
mplsTunnelTable for MPLS based transport network mplsTunnelTable for MPLS based transport network
tunnels also. tunnels also.
Since the MPLS tunnel's Ingress/Egress LSR identifiers' Since the MPLS tunnel's Ingress/Egress LSR identifiers'
size (Unsigned32) value is not compatible for size (Unsigned32) value is not compatible for
MPLS-TP tunnel i.e. Global_Node_Id of size 8 bytes and MPLS-TP tunnel i.e. Global_Node_Id of size 8 bytes and
ICC of size 6 bytes, there exists a need to map the ICC of size 6 bytes, there exists a need to map the
skipping to change at page 31, line 16 skipping to change at page 38, line 12
mplsTunnelExtNodeConfigLocalId OBJECT-TYPE mplsTunnelExtNodeConfigLocalId OBJECT-TYPE
SYNTAX MplsExtendedTunnelId SYNTAX MplsExtendedTunnelId
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object is used in accommodating the bigger "This object is used in accommodating the bigger
size Global_Node_ID and/or ICC with lower size LSR size Global_Node_ID and/or ICC with lower size LSR
identifier in order to index the mplsTunnelTable. identifier in order to index the mplsTunnelTable.
The Local Identifier is configured between 1 and 16777215, The Local Identifier is configured between 0 and 16777215,
as valid IP address range starts from 16777216(01.00.00.00). as valid IP address range starts from 16777216(01.00.00.00).
This range is chosen to identify the mplsTunnelTable's This range is chosen to identify the mplsTunnelTable's
Ingress/Egress LSR-id is IP address or Local identifier, Ingress/Egress LSR-id is IP address or Local identifier,
if the configured range is not IP address, administrator is if the configured range is not IP address, operator is
expected to retrieve the complete information expected to retrieve the complete information
(Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable.
This way, existing mplsTunnelTable is reused for This way, existing mplsTunnelTable is reused for
bidirectional bidirectional tunnel extensions for MPLS based transport
tunnel extensions for MPLS based transport networks. networks.
This Local Identifier allows the administrator to assign This Local Identifier allows the operator to assign
a unique identifier to map Global_Node_ID and/or ICC." a unique identifier to map Global_Node_ID and/or ICC.
As this Local Identifier is unique within the node and
the same syntax of this object can be used for MPLS TE
tunnel also, it is up to the operator/local management
entity to choose the non-conflicting value for indexing
the MPLS and MPLS-TP tunnel entries."
::= { mplsTunnelExtNodeConfigEntry 1 } ::= { mplsTunnelExtNodeConfigEntry 1 }
mplsTunnelExtNodeConfigGlobalId OBJECT-TYPE mplsTunnelExtNodeConfigGlobalId OBJECT-TYPE
SYNTAX MplsGlobalId SYNTAX MplsGlobalId
MAX-ACCESS read-write MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object indicates the Global Operator Identifier. "This object indicates the Global Operator Identifier.
This object value should be zero when This object value should be zero when
mplsTunnelExtNodeConfigIccId is configured with non-null mplsTunnelExtNodeConfigIccId is configured with non-null
value." value."
REFERENCE REFERENCE
"MPLS-TP Identifiers [RFC6370]." "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370]
Section 3. Uniquely Identifying an Operator -
the Global_ID"
::= { mplsTunnelExtNodeConfigEntry 2 } ::= { mplsTunnelExtNodeConfigEntry 2 }
mplsTunnelExtNodeConfigNodeId OBJECT-TYPE mplsTunnelExtNodeConfigNodeId OBJECT-TYPE
SYNTAX MplsNodeId SYNTAX MplsNodeId
MAX-ACCESS read-write MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object indicates the Node_ID within the operator. "This object indicates the Node_ID within the operator.
This object value should be zero when This object value should be zero when
mplsTunnelExtNodeConfigIccId is configured with non-null mplsTunnelExtNodeConfigIccId is configured with non-null
value." value."
REFERENCE REFERENCE
"MPLS-TP Identifiers [RFC6370]." "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370]
Section 4, Node and Interface Identifiers"
::= { mplsTunnelExtNodeConfigEntry 3 } ::= { mplsTunnelExtNodeConfigEntry 3 }
mplsTunnelExtNodeConfigIccId OBJECT-TYPE mplsTunnelExtNodeConfigIccId OBJECT-TYPE
SYNTAX MplsIccId SYNTAX MplsIccId
MAX-ACCESS read-write MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object allows the operator or service provider to "This object allows the operator or service provider to
configure a unique MPLS-TP ITU-T Carrier Code (ICC) configure a unique MPLS-TP ITU-T Carrier Code (ICC)
either for Ingress ID or Egress ID. either for Ingress ID or Egress ID.
This object value should be zero when This object value should be zero when
mplsTunnelExtNodeConfigGlobalId and mplsTunnelExtNodeConfigGlobalId and
mplsTunnelExtNodeConfigNodeId are assigned with non-zero mplsTunnelExtNodeConfigNodeId are assigned with non-zero
value." value."
REFERENCE REFERENCE
"MPLS-TP Identifiers [RFC6370]." "MPLS-TP Identifiers Following ITU-T Conventions,
[I-D.ietf-mpls-tp-itu-t-identifiers], August 2012,
Section 3. Uniquely Identifying an Operator - the
ICC_Operator_ID"
::= { mplsTunnelExtNodeConfigEntry 4 } ::= { mplsTunnelExtNodeConfigEntry 4 }
mplsTunnelExtNodeConfigRowStatus OBJECT-TYPE mplsTunnelExtNodeConfigRowStatus OBJECT-TYPE
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object allows the administrator to create, modify, "This object allows the operator to create, modify,
and/or delete a row in this table." and/or delete a row in this table."
::= { mplsTunnelExtNodeConfigEntry 5 } ::= { mplsTunnelExtNodeConfigEntry 5 }
mplsTunnelExtNodeConfigStorageType OBJECT-TYPE mplsTunnelExtNodeConfigStorageType OBJECT-TYPE
SYNTAX StorageType SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This variable indicates the storage type for this "This variable indicates the storage type for this
object. object.
skipping to change at page 33, line 4 skipping to change at page 40, line 10
DESCRIPTION DESCRIPTION
"This variable indicates the storage type for this "This variable indicates the storage type for this
object. object.
Conceptual rows having the value 'permanent' Conceptual rows having the value 'permanent'
need not allow write-access to any columnar need not allow write-access to any columnar
objects in the row." objects in the row."
DEFVAL { volatile } DEFVAL { volatile }
::= { mplsTunnelExtNodeConfigEntry 6 } ::= { mplsTunnelExtNodeConfigEntry 6 }
-- End of MPLS Transport Profile Node configuration table -- End of MPLS Transport Profile Node configuration table
-- Start of MPLS Transport Profile Node IP compatible -- Start of MPLS Transport Profile Node IP compatible
-- mapping table -- mapping table
mplsTunnelExtNodeIpMapTable OBJECT-TYPE mplsTunnelExtNodeIpMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtNodeIpMapEntry SYNTAX SEQUENCE OF MplsTunnelExtNodeIpMapEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This read-only table allows the administrator to retrieve "This read-only table allows the operator to retrieve
the local identifier for a given Global_Node_ID in an IP the local identifier for a given Global_Node_ID in an IP
compatible operator environment. compatible operator environment.
This table MAY be used in on-demand and/or proactive This table MAY be used in on-demand and/or proactive
OAM operations to get the Ingress/Egress LSR identifier OAM operations to get the Ingress/Egress LSR identifier
(Local Identifier) from Src-Global_Node_ID (Local Identifier) from Src-Global_Node_ID
or Dst-Global_Node_ID and the Ingress and Egress LSR or Dst-Global_Node_ID and the Ingress and Egress LSR
identifiers are used to retrieve the tunnel entry. identifiers are used to retrieve the tunnel entry.
This table returns nothing when the associated entry This table returns nothing when the associated entry
is not defined in mplsTunnelExtNodeConfigTable." is not defined in mplsTunnelExtNodeConfigTable."
::= { mplsTeExtObjects 2 } ::= { mplsTeExtObjects 2 }
mplsTunnelExtNodeIpMapEntry OBJECT-TYPE mplsTunnelExtNodeIpMapEntry OBJECT-TYPE
skipping to change at page 34, line 39 skipping to change at page 41, line 50
-- End MPLS Transport Profile Node IP compatible table -- End MPLS Transport Profile Node IP compatible table
-- Start of MPLS Transport Profile Node ICC based table -- Start of MPLS Transport Profile Node ICC based table
mplsTunnelExtNodeIccMapTable OBJECT-TYPE mplsTunnelExtNodeIccMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtNodeIccMapEntry SYNTAX SEQUENCE OF MplsTunnelExtNodeIccMapEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This read-only table allows the administrator to retrieve "This read-only table allows the operator to retrieve
the local identifier for a given ICC operator in an ICC the local identifier for a given ICC operator in an ICC
operator environment. operator environment.
This table MAY be used in on-demand and/or proactive This table MAY be used in on-demand and/or proactive
OAM operations to get the Ingress/Egress LSR OAM operations to get the Ingress/Egress LSR
identifier (Local Identifier) from Src-ICC identifier (Local Identifier) from Src-ICC
or Dst-ICC and the Ingress and Egress LSR or Dst-ICC and the Ingress and Egress LSR
identifiers are used to retrieve the tunnel entry. identifiers are used to retrieve the tunnel entry.
This table returns nothing when the associated entry This table returns nothing when the associated entry
is not defined in mplsTunnelExtNodeConfigTable." is not defined in mplsTunnelExtNodeConfigTable."
skipping to change at page 36, line 4 skipping to change at page 43, line 12
SYNTAX MplsExtendedTunnelId SYNTAX MplsExtendedTunnelId
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object contains an ICC based local identifier "This object contains an ICC based local identifier
which is defined in mplsTunnelExtNodeConfigTable." which is defined in mplsTunnelExtNodeConfigTable."
::= { mplsTunnelExtNodeIccMapEntry 2 } ::= { mplsTunnelExtNodeIccMapEntry 2 }
-- End MPLS Transport Profile Node ICC based table -- End MPLS Transport Profile Node ICC based table
-- Start of MPLS Tunnel table extension -- Start of MPLS Tunnel table extension
mplsTunnelExtTable OBJECT-TYPE mplsTunnelExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtEntry SYNTAX SEQUENCE OF MplsTunnelExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table represents MPLS-TP specific extensions to "This table represents extensions to mplsTunnelTable
mplsTunnelTable. in order to support MPLS-TP tunnels.
As per MPLS-TP Identifiers [RFC6370], LSP_ID for IP based As per MPLS-TP Identifiers [RFC6370], LSP_ID for IP based
co-routed bidirectional tunnel, co-routed bidirectional tunnel,
A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
Node_ID::Tunnel_Num}::LSP_Num Node_ID::Tunnel_Num}::LSP_Num
LSP_ID for IP based associated bidirectional tunnel, LSP_ID for IP based associated bidirectional tunnel,
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
skipping to change at page 36, line 39 skipping to change at page 43, line 48
mplsTunnelIngressLSRId, Destination Node_ID is mplsTunnelIngressLSRId, Destination Node_ID is
mapped with mplsTunnelEgressLSRId LSP_Num is mapped with mapped with mplsTunnelEgressLSRId LSP_Num is mapped with
mplsTunnelInstance. mplsTunnelInstance.
Source Global_Node_ID and/or ICC and Destination Source Global_Node_ID and/or ICC and Destination
Global_Node_ID and/or ICC are maintained in the Global_Node_ID and/or ICC are maintained in the
mplsTunnelExtNodeConfigTable and mplsTunnelExtNodeConfigTable and
mplsTunnelExtNodeConfigLocalId is used to create an entry mplsTunnelExtNodeConfigLocalId is used to create an entry
in mplsTunnelTable." in mplsTunnelTable."
REFERENCE REFERENCE
"MPLS-TP Identifiers [RFC6370]." "MPLS Transport Profile (MPLS-TP) Identifiers [RFC6370],
Section 3 and 4."
::= { mplsTeExtObjects 4 } ::= { mplsTeExtObjects 4 }
mplsTunnelExtEntry OBJECT-TYPE mplsTunnelExtEntry OBJECT-TYPE
SYNTAX MplsTunnelExtEntry SYNTAX MplsTunnelExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entry in this table represents MPLS-TP "An entry in this table represents MPLS-TP
specific additional tunnel configurations." specific additional tunnel configurations."
INDEX { INDEX {
skipping to change at page 37, line 14 skipping to change at page 44, line 27
mplsTunnelIngressLSRId, mplsTunnelIngressLSRId,
mplsTunnelEgressLSRId mplsTunnelEgressLSRId
} }
::= { mplsTunnelExtTable 1 } ::= { mplsTunnelExtTable 1 }
MplsTunnelExtEntry ::= SEQUENCE { MplsTunnelExtEntry ::= SEQUENCE {
mplsTunnelExtOppositeDirPtr RowPointer, mplsTunnelExtOppositeDirPtr RowPointer,
mplsTunnelExtOppositeDirTnlValid TruthValue, mplsTunnelExtOppositeDirTnlValid TruthValue,
mplsTunnelExtDestTnlIndex MplsTunnelIndex, mplsTunnelExtDestTnlIndex MplsTunnelIndex,
mplsTunnelExtDestTnlLspIndex MplsTunnelInstanceIndex, mplsTunnelExtDestTnlLspIndex MplsTunnelInstanceIndex,
mplsTunnelExtDestTnlValid TruthValue mplsTunnelExtDestTnlValid TruthValue,
mplsTunnelExtIngressLSRLocalIdValid TruthValue,
mplsTunnelExtEgressLSRLocalIdValid TruthValue
} }
mplsTunnelExtOppositeDirPtr OBJECT-TYPE mplsTunnelExtOppositeDirPtr OBJECT-TYPE
SYNTAX RowPointer SYNTAX RowPointer
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object is applicable only for the bidirectional "This object is applicable only for the bidirectional
tunnel that has the forward and reverse LSPs in the tunnel that has the forward and reverse LSPs in the
same tunnel or in the different tunnels. same tunnel or in the different tunnels.
This object holds the opposite direction tunnel entry This object holds the opposite direction tunnel entry
if the bidirectional tunnel is setup by configuring two if the bidirectional tunnel is setup by configuring two
tunnel entries in mplsTunnelTable. tunnel entries in mplsTunnelTable.
Note that there are two different ways to represent the
opposite direction tunnel entry. One method is to use this
object mplsTunnelExtOppositeDirPtr as RowPointer and make
it point to the other direction tunnel. Other method is to
use the mplsTunnelExtDestTnlIndex and
mplsTunnelExtDestTnlLspIndex instead of using this
mplsTunnelExtOppositeDirPtr. Implementation can choose
either one of the method to represent the opposite
direction tunnel. Duplicate methods are provided to provide
easy ways for different implementations.
The value of zeroDotZero indicates single tunnel entry The value of zeroDotZero indicates single tunnel entry
is used for bidirectional tunnel setup." is used for bidirectional tunnel setup."
DEFVAL { zeroDotZero }
::= { mplsTunnelExtEntry 1 } DEFVAL { zeroDotZero }
::= { mplsTunnelExtEntry 1 }
mplsTunnelExtOppositeDirTnlValid OBJECT-TYPE mplsTunnelExtOppositeDirTnlValid OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Denotes whether or not this tunnel uses "Denotes whether or not this tunnel uses
mplsTunnelExtOppositeDirPtr for identifying the opposite mplsTunnelExtOppositeDirPtr for identifying the opposite
direction tunnel information. Note that if this variable direction tunnel information. Note that if this variable
is set to true then the mplsTunnelExtOppositeDirPtr should is set to true then the mplsTunnelExtOppositeDirPtr should
skipping to change at page 39, line 23 skipping to change at page 46, line 51
mplsTunnelExtDestTnlIndex and mplsTunnelExtDestTnlIndex and
mplsTunnelExtDestTnlLspIndex for identifying mplsTunnelExtDestTnlLspIndex for identifying
the opposite direction tunnel information. Note that if the opposite direction tunnel information. Note that if
this variable is set to true then the this variable is set to true then the
mplsTunnelExtDestTnlIndex and mplsTunnelExtDestTnlIndex and
mplsTunnelExtDestTnlLspIndex objects should have mplsTunnelExtDestTnlLspIndex objects should have
the valid opposite direction tunnel indices." the valid opposite direction tunnel indices."
DEFVAL { false } DEFVAL { false }
::= { mplsTunnelExtEntry 5 } ::= { mplsTunnelExtEntry 5 }
-- End of MPLS Tunnel table extension mplsTunnelExtIngressLSRLocalIdValid OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object denotes whether the mplsTunnelIngressLSRId
contains the local value, which is used to reference
the complete Ingress Global_ID::Node_ID or ICC from
the mplsTunnelExtNodeConfigTable."
REFERENCE
"MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelIngressLSRId
object in mplsTunnelTable.
If this object is set to FALSE, mplsTunnelExtNodeConfigTable
will not contain an entry to reference local identifier with
Global_ID::Node_ID or ICC value.
This object is set to FALSE for legacy implementations like
MPLS TE tunnels where mplsTunnelIngressId itself provides
complete Ingress LSRId."
DEFVAL { false }
::= { mplsTunnelExtEntry 6 }
mplsTunnelExtEgressLSRLocalIdValid OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object denotes whether the mplsTunnelEgressLSRId
contains the local value, which is used to reference
the complete Egress Global_ID::Node_ID or ICC from
the mplsTunnelExtNodeConfigTable."
REFERENCE
"MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelEgressLSRId
object in mplsTunnelTable.
If this object is set to FALSE, mplsTunnelExtNodeConfigTable
will not contain an entry to reference local identifier with
Global_ID::Node_ID or ICC value.
This object is set to FALSE for legacy implementations like
MPLS TE tunnels where mplsTunnelEgressId itself provides
complete Egress LSRId."
DEFVAL { false }
::= { mplsTunnelExtEntry 7 }
-- End of MPLS Tunnel table extension
mplsTunnelExtReversePerfTable OBJECT-TYPE mplsTunnelExtReversePerfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsTunnelExtReversePerfEntry SYNTAX SEQUENCE OF MplsTunnelExtReversePerfEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table extends the mplsTunnelTable to provide "This table extends the mplsTunnelTable to provide
per-tunnel packet performance information for the reverse per-tunnel packet performance information for the reverse
direction of a bidirectional tunnel. It can be seen as direction of a bidirectional tunnel. It can be seen as
supplementing the mplsTunnelPerfTable, which augments the supplementing the mplsTunnelPerfTable, which augments the
mplsTunnelTable. mplsTunnelTable.
For links that do not transport packets, these packet For links that do not transport packets, these packet
counters cannot be maintained. For such links, attempts counters cannot be maintained. For such links, attempts
to read the objects in this table will return to read the objects in this table will return
noSuchInstance." noSuchInstance."
REFERENCE REFERENCE
"1. Multiprotocol Label Switching (MPLS) Traffic "1. Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE)Management Information Base (MIB), Engineering (TE)Management Information Base (MIB),
RFC 3812." RFC 3812. Section 6.6. mplsTunnelPerfTable"
::= { mplsTeExtObjects 5 } ::= { mplsTeExtObjects 5 }
mplsTunnelExtReversePerfEntry OBJECT-TYPE mplsTunnelExtReversePerfEntry OBJECT-TYPE
SYNTAX MplsTunnelExtReversePerfEntry SYNTAX MplsTunnelExtReversePerfEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entry in this table is created by the LSR for every "An entry in this table is created by the LSR for every
bidirectional MPLS tunnel where packets are visible to the bidirectional MPLS tunnel where packets are visible to the
LSR." LSR."
skipping to change at page 43, line 40 skipping to change at page 52, line 19
-- Units of conformance. -- Units of conformance.
mplsTunnelExtGroup OBJECT-GROUP mplsTunnelExtGroup OBJECT-GROUP
OBJECTS { OBJECTS {
mplsTunnelExtOppositeDirPtr, mplsTunnelExtOppositeDirPtr,
mplsTunnelExtOppositeDirTnlValid, mplsTunnelExtOppositeDirTnlValid,
mplsTunnelExtDestTnlIndex, mplsTunnelExtDestTnlIndex,
mplsTunnelExtDestTnlLspIndex, mplsTunnelExtDestTnlLspIndex,
mplsTunnelExtDestTnlValid, mplsTunnelExtDestTnlValid,
mplsTunnelExtIngressLSRLocalIdValid,
mplsTunnelExtEgressLSRLocalIdValid,
mplsTunnelExtReversePerfPackets, mplsTunnelExtReversePerfPackets,
mplsTunnelExtReversePerfHCPackets, mplsTunnelExtReversePerfHCPackets,
mplsTunnelExtReversePerfErrors, mplsTunnelExtReversePerfErrors,
mplsTunnelExtReversePerfBytes, mplsTunnelExtReversePerfBytes,
mplsTunnelExtReversePerfHCBytes mplsTunnelExtReversePerfHCBytes
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Necessary, but not sufficient, set of objects to "Necessary, but not sufficient, set of objects to
skipping to change at page 45, line 31 skipping to change at page 54, line 11
access to the objects only to those principles (users) that access to the objects only to those principles (users) that
have legitimate rights to indeed GET or SET (change/create/delete) have legitimate rights to indeed GET or SET (change/create/delete)
them. them.
15. IANA Considerations 15. IANA Considerations
To be added in a later version of this document. To be added in a later version of this document.
16. References 16. References
16.1 Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April "Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999. 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
16.2 Informative References 16.2. Informative References
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering "Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June (TE) Management Information Base (MIB)", RFC 3812, June
2004. 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching "Multiprotocol Label Switching (MPLS) Label Switching
(LSR) Router Management Information Base (MIB)", RFC 3813, (LSR) Router Management Information Base (MIB)", RFC 3813,
June 2004. June 2004.
skipping to change at page 46, line 35 skipping to change at page 55, line 15
Engineering Management Information Base", RFC Engineering Management Information Base", RFC
4802, February 2007. 4802, February 2007.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009. Transport Profile", RFC 5654, September 2009.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September Profile (MPLS-TP) Identifiers", RFC 6370, September
2011. 2011.
[I-D.ietf-mpls-tp-itu-t-identifiers] Winter, R., Gray, E., Helvoort,
H., and M. Betts, "MPLS-TP Identifiers Following ITU-T
Conventions", draft-ietf-mpls-tp-itu-t-identifiers-07
(work in progress), August 2012.
17. Acknowledgments 17. Acknowledgments
The authors would like to thank Francesco Fondelli, Josh Littlefield, The authors would like to thank Francesco Fondelli, Josh Littlefield,
Agrahara Kiran Koushik, Metrri Jain, Muly Ilan and Joan Cucchiara Agrahara Kiran Koushik, Metrri Jain, Muly Ilan, Joan Cucchiara and
for their valuable comments. Randy Presuhn for their valuable comments.
18. Authors' Addresses 18. Authors' Addresses
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
skipping to change at page 47, line 4 skipping to change at page 55, line 38
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way, 2330 Central Express Way,
Santa Clara, CA 95051, USA Santa Clara, CA 95051, USA
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Juniper Networks
10 Technology Park Drive, Westford, MA 01886 10 Technology Park Drive, Westford, MA 01886
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
Venkatesan Mahalingam Venkatesan Mahalingam
Dell Inc. Dell Inc.
350 Holger way, San Jose, CA, USA 350 Holger way, San Jose, CA, USA
Email: venkat.mahalingams@gmail.com Email: venkat.mahalingams@gmail.com
Kannan KV Sampath Kannan KV Sampath
Aricent Redeem
India India
Email: Kannan.Sampath@aricent.com Email: kannankvs@gmail.com
 End of changes. 134 change blocks. 
209 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Disposition: attachment; filename=draft-ietf-mpls-tp-te-mib-05.nroff Content-Type: application/octet-stream; name="draft-ietf-mpls-tp-te-mib-05.nroff" Content-Transfer-Encoding: quoted-printable .\"=20Auto=20generated=20Nroff=20by=20NroffEdit=20on=20September=2014,=20= 2012=0D=0A.pl=2010.0i=0D=0A.po=200=0D=0A.ll=207.2i=0D=0A.lt=207.2i=0D=0A= .nr=20LL=207.2i=0D=0A.nr=20LT=207.2i=0D=0A.ds=20LF=20Venkatesan,=20=20et=20= al.=0D=0A.ds=20RF=20FORMFEED[Page=20%]=0D=0A.ds=20LH=20INTERNET=20DRAFT=0D= =0A.ds=20RH=20January=2014,=202013=0D=0A.ds=20CH=20MPLS-TP=20MIB=0D=0A= .ds=20CF=20Expires=20July=2018,=202013=0D=0A.hy=200=0D=0A.nh=0D=0A.ad=20= l=0D=0A.in=200=0D=0A=0D=0A.nf=0D=0A.tl=20'Network=20Working=20Group'''=0D= =0A.tl=20'INTERNET-DRAFT''M.Venkatesan'=0D=0A.tl=20'Intended=20Status:=20= Standards=20Track''Dell=20Inc.'=0D=0A.tl=20'Expires:=20July=2018,=20= 2013''Kannan=20KV=20Sampath'=0D=0A.tl=20'''Redeem'=0D=0A.tl=20'''Sam=20= K.=20Aldrin'=0D=0A.tl=20'''Huawei=20Technologies'=0D=0A.tl=20'''Thomas=20= D.=20Nadeau'=0D=0A.tl=20'''Juniper=20Networks'=0D=0A=0D=0A.tl=20= '''January=2014,=202013'=0D=0A.fi=0D=0A.in=203=0D=0A=0D=0A=0D=0A.in=2020=0D= =0A.ti=202=0D=0AMPLS-TP=20Traffic=20Engineering=20(TE)=20Management=20= Information=20Base=20(MIB)=20\%draft-ietf-mpls-tp-te-mib-05.txt=0D=0A=0D=0A= =0D=0A.ti=200=0D=0AAbstract=0D=0A=0D=0A.in=203=0D=0AThis=20memo=20= defines=20a=20portion=20of=20the=20Management=20Information=20Base=20= (MIB)=20for=20use=20with=20network=20management=20protocols=20in=20the=20= Internet=20community.=20In=20particular,=20it=20describes=20managed=20= objects=20of=20Tunnels,=20Identifiers,=20Label=20Switch=20Router=20and=20= Textual=20conventions=20for=20Multiprotocol=20Label=20Switching=20(MPLS)=20= based=20Transport=20Profile=20(TP).=0D=0A=0D=0A.ti=200=0D=0AStatus=20of=20= this=20Memo=0D=0A=0D=0AThis=20Internet-Draft=20is=20submitted=20to=20= IETF=20in=20full=20conformance=20with=20the=20provisions=20of=20BCP=2078=20= and=20BCP=2079.=0D=0A=0D=0AInternet-Drafts=20are=20working=20documents=20= of=20the=20Internet=20Engineering=20Task=20Force=20(IETF),=20its=20= areas,=20and=20its=20working=20groups.=20=20Note=20that=20other=20groups=20= may=20also=20distribute=20working=20documents=20as=20Internet-=20Drafts.=0D= =0A=0D=0AInternet-Drafts=20are=20draft=20documents=20valid=20for=20a=20= maximum=20of=20six=20months=20and=20may=20be=20updated,=20replaced,=20or=20= obsoleted=20by=20other=20documents=20at=20any=20time.=20=20It=20is=20= inappropriate=20to=20use=20Internet-Drafts=20as=20reference=20material=20= or=20to=20cite=20them=20other=20than=20as=20"work=20in=20progress."=0D=0A= =0D=0AThe=20list=20of=20current=20Internet-Drafts=20can=20be=20accessed=20= at=20\%http://www.ietf.org/ietf/1id-abstracts.txt.=0D=0A=0D=0AThe=20list=20= of=20Internet-Draft=20Shadow=20Directories=20can=20be=20accessed=20at=20= http://www.ietf.org/shadow.html.=0D=0A=0D=0AThis=20Internet-Draft=20will=20= expire=20on=20July=2018,=202013.=0D=0A.bp=0D=0A.ti=200=0D=0ACopyright=20= and=20License=20Notice=0D=0A=0D=0ACopyright=20(c)=202013=20IETF=20Trust=20= and=20the=20persons=20identified=20as=20the=20document=20authors.=20All=20= rights=20reserved.=0D=0A=0D=0AThis=20document=20is=20subject=20to=20BCP=20= 78=20and=20the=20IETF=20Trust's=20Legal=20Provisions=20Relating=20to=20= IETF=20Documents=20\%(http://trustee.ietf.org/license-info)=20in=20= effect=20on=20the=20date=20of=20publication=20of=20this=20document.=20= Please=20review=20these=20documents=20carefully,=20as=20they=20describe=20= your=20rights=20and=20restrictions=20with=20respect=20to=20this=20= document.=20Code=20Components=20extracted=20from=20this=20document=20= must=20include=20Simplified=20BSD=20License=20text=20as=20described=20in=20= Section=204.e=20of=20the=20Trust=20Legal=20Provisions=20and=20are=20= provided=20without=20warranty=20as=20described=20in=20the=20Simplified=20= BSD=20License.=0D=0A.sp4=0D=0A.ti=200=0D=0ATable=20of=20Contents=0D=0A=0D= =0A.nf=0D=0A1.=20Introduction=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0D=0A2.=20= The=20Internet-Standard=20Management=20Framework=20=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20=204=0D=0A3.=20Overview=20=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20=204=0D=0A=20=203.1.=20Conventions=20used=20in=20this=20= document=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0D=0A= =20=203.2.=20Terminology=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=204=0D=0A=20=203.3.=20= Acronyms=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=205=0D=0A4.=20Motivations=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20=205=0D=0A5.=20Feature=20List=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20=205=0D=0A6.=20Brief=20description=20of=20MIB=20Objects=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=205=0D=0A= =20=206.1.=20mplsTunnelExtNodeConfigTable=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20=206=0D=0A=20=206.2.=20= mplsTunnelExtNodeIpMapTable=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20=206=0D=0A=20=206.3.=20mplsTunnelExtNodeIccMapTable=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D=0A= =20=206.4.=20mplsTunnelExtTable=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D=0A=20=206.5.=20= mplsTunnelExtReversePerfTable=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20=207=0D=0A7.=20MIB=20Module=20Interdependencies=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20=207=0D= =0A8.=20Dependencies=20between=20MIB=20Module=20Tables=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20=209=0D=0A9.=20Example=20of=20= MPLS-TP=20Tunnel=20Setup=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20=209=0D=0A=20=209.1.=20Example=20of=20MPLS-TP=20static=20= co-routed=20bidirectional=20tunnel=0D=0A=20=20=20=20=20=20=20setup=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2010=0D=0A=20=20=20=209.1.1.=20= mplsTunnelEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=2010=0D=0A=20=20=20=209.1.2.=20mplsTunnelExtEntry=20= =20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 11=0D=0A=20=20=20=209.1.3.=20Forward=20direction=20mplsOutSegmentEntry=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2012=0D=0A=20=20=20=209.1.4.=20Reverse=20= direction=20mplsInSegmentEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 12=0D=0A=20=20=20=209.1.5.=20Forward=20direction=20mplsXCEntry=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2012=0D=0A=20=20=20=209.1.6.=20= Reverse=20direction=20mplsXCEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2013=0D=0A=20=20=20=209.1.7.=20Forward=20direction=20= mplsXCExtEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2013=0D=0A=20= =20=20=209.1.8.=20Reverse=20direction=20mplsXCExtEntry=20=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2013=0D=0A=20=20=20=209.1.9.=20= mplsTunnelExtReversePerfTable=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2013=0D=0A=0D=0A=20=209.2.=20Example=20of=20MPLS-TP=20static=20= associated=20bidirectional=20tunnel=0D=0A=20=20=20=20=20=20=20setup=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2014=0D=0A=20=20=20=209.2.1.=20Forward=20= direction=20mplsTunnelEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 14=0D=0A=20=20=20=209.2.2.=20Forward=20direction=20mplsTunnelExtEntry=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=2015=0D=0A=20=20=20=209.2.3.=20Forward=20= direction=20mplsOutSegmentTable=20.=20.=20.=20.=20.=20.=20.=20.=20.=2015=0D= =0A=20=20=20=209.2.4.=20Forward=20direction=20mplsXCEntry=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2015=0D=0A=20=20=20=209.2.5.=20= Forward=20direction=20mplsXCExtEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2016=0D=0A=20=20=20=209.2.6.=20Reverse=20direction=20= mplsTunnelEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2016=0D=0A=20= =20=20=209.2.7.=20Reverse=20direction=20mplsTunnelExtEntry=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2017=0D=0A=20=20=20=209.2.8.=20Reverse=20= direction=20mplsInSegmentEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 17=0D=0A=20=20=20=209.2.9.=20Reverse=20direction=20mplsXCEntry=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2017=0D=0A=20=20=20=209.2.10.=20= Reverse=20direction=20mplsXCExtEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=2018=0D=0A=20=209.3.=20Example=20of=20MPLS-TP=20signaling=20= co-routed=20bidirectional=0D=0A=20=20=20=20=20=20=20tunnel=20setup=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2018=0D=0A=20=20=20=209.3.1.=20mplsTunnelEntry=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 18=0D=0A=20=20=20=209.3.2.=20mplsTunnelExtEntry=20=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2019=0D=0A=20=20=20=20= 9.3.3.=20Forward=20direction=20mplsOutSegmentEntry=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2019=0D=0A=20=20=20=209.3.4.=20Reverse=20direction=20= mplsInSegmentEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=2019=0D=0A=20=20= =20=209.3.5.=20Forward=20direction=20mplsXCEntry=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=2020=0D=0A=20=20=20=209.3.6.=20Reverse=20= direction=20mplsXCEntry=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=2020=0D=0A=20=20=20=209.3.7.=20Forward=20direction=20mplsXCExtEntry=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2020=0D=0A=20=20=20=209.3.8.=20= Reverse=20direction=20mplsXCExtEntry=20=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=2020=0D=0A=20=20=20=209.3.9.=20mplsTunnelExtReversePerfTable=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2020=0D=0A10.=20MPLS=20= Textual=20Convention=20Extension=20MIB=20definitions=20=20.=20.=20.=20.=20= .=20.=2020=0D=0A11.=20MPLS=20Identifier=20MIB=20definitions=20=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2023=0D=0A12.=20MPLS=20= LSR=20Extension=20MIB=20definitions=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2027=0D=0A13.=20MPLS=20Tunnel=20Extension=20MIB=20= definitions=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2031=0D=0A= 14.=20Security=20Consideration=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2049=0D=0A15.=20IANA=20= Considerations=20=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=2050=0D=0A16.=20References=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=2050=0D=0A=20=2016.1.=20Normative=20References=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=2050=0D=0A=20= =2016.2.=20=20Informative=20References=20=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=2050=0D=0A17.=20Acknowledgments=20=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= .=20.=20.=20.=20.=2051=0D=0A18.=20Authors'=20Addresses=20.=20.=20.=20.=20= .=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20.=20= 51=0D=0A.bp=0D=0A.ti=200=0D=0A1.=20Introduction=0D=0A=0D=0A.fi=0D=0A.in=20= 0=0D=0AThis=20memo=20defines=20a=20portion=20of=20the=20Management=20= Information=20Base=20(MIB)=20for=20use=20with=20network=20management=20= protocols=20in=20the=20Internet=20community.=20In=20particular,=20it=20= describes=20managed=20objects=20of=20Tunnels,=20Identifiers,=20Label=20= Switch=20Router=20and=20Textual=20conventions=20for=20Multiprotocol=20= Label=20Switching=20(MPLS)=20based=20Transport=20Profile=20(TP).=20This=20= draft=20extends=20the=20existing=20MPLS=20MIB=20objects=20for=20both=20= MPLS-TP=20and=20Non-MPLS-TP=20operations,=20so=20the=20MPLS-TP=20name=20= is=20not=20included=20in=20the=20MIB=20module=20name.=0D=0A=0D=0AThe=20= existing=20Multiprotocol=20Label=20Switching=20(MPLS)=20Traffic=20= Engineering=20(TE)=20Management=20Information=20Base=20(MIB)=20[RFC3812]=20= and=20Generalized=20Multiprotocol=20Label=20Switching=20(GMPLS)=20= Traffic=20Engineering=20Management=20Information=20Base=20[RFC4802]=20do=20= not=20support=20the=20transport=20network=20requirements=20of=20NON-IP=20= based=20management=20and=20static=20bidirectional=20tunnels.=20This=20= MIB=20module=20should=20be=20used=20in=20conjunction=20with=20[RFC3812]=20= and=20companion=20document=20[RFC3813]=20for=20MPLS=20based=20traffic=20= engineering=20configuration=20and=20management.=0D=0A=0D=0AThe=20key=20= words=20"MUST",=20"MUST=20NOT",=20"REQUIRED",=20"SHALL",=20"SHALL=20= NOT",=20"SHOULD",=20"SHOULD=20NOT",=20"MAY",=20and=20"OPTIONAL"=20in=20= this=20document=20are=20to=20be=20interpreted=20as=20described=20in=20= BCP=2014,=20RFC2119.=0D=0A=0D=0A.ti=200=0D=0A2.=20The=20= Internet-Standard=20Management=20Framework=0D=0A=0D=0AFor=20a=20detailed=20= overview=20of=20the=20documents=20that=20describe=20the=20current=20= \%Internet-Standard=20Management=20Framework,=20please=20refer=20to=20= section=207=20of=20RFC3410=20[RFC3410].=0D=0A=0D=0AManaged=20objects=20= are=20accessed=20via=20a=20virtual=20information=20store,=20termed=20the=20= Management=20Information=20Base=20or=20MIB.=20MIB=20objects=20are=20= generally=20accessed=20through=20the=20Simple=20Network=20Management=20= Protocol=20(SNMP).=20Objects=20in=20the=20MIB=20are=20defined=20using=20= the=20mechanisms=20defined=20in=20the=20Structure=20of=20Management=20= Information=20(SMI).=20This=20memo=20specifies=20a=20MIB=20module=20that=20= is=20compliant=20to=20the=20SMIv2,=20which=20is=20described=20in=20STD=20= 58,=20RFC2578,=20STD=2058,=20RFC2579=20and=20STD58,=20RFC2580.=0D=0A=0D=0A= =0D=0A.ti=200=0D=0A3.=20Overview=0D=0A=0D=0A.ti=200=0D=0A3.1.=20= Conventions=20used=20in=20this=20document=0D=0A=0D=0AThe=20key=20words=20= "MUST",=20"MUST=20NOT",=20"REQUIRED",=20"SHALL",=20"SHALL=20NOT",=20= "SHOULD",=20"SHOULD=20NOT",=20"RECOMMENDED",=20"MAY",=20and=20"OPTIONAL"=20= in=20this=20document=20are=20to=20be=20interpreted=20as=20described=20in=20= [RFC2119].=0D=0A=0D=0A.ti=200=0D=0A3.2.=20Terminology=0D=0A=0D=0AThis=20= document=20uses=20terminology=20from=20the=20Multiprotocol=20Label=20= Switching=20Architecture=20[RFC3031],=20Multiprotocol=20Label=20= Switching=20(MPLS)=20Traffic=20Engineering=20(TE)=20Management=20= Information=20Base=20(MIB)=20[RFC3812],=20Multiprotocol=20Label=20= Switching=20(MPLS)=20Label=20Switching=20Router=20(LSR)=20Management=20= Information=20Base=20(MIB)=20[RFC3813]=20and=20MPLS=20Transport=20= Profile=20(MPLS-TP)=20Identifiers=20[RFC6370].=0D=0A.bp=0D=0A.ti=200=0D=0A= 3.3.=20Acronyms=0D=0A=0D=0A.nf=0D=0AGMPLS:=20Generalized=20= Multi-Protocol=20Label=20Switching=0D=0AICC:=20ITU=20Carrier=20Code=0D=0A= IP:=20Internet=20Protocol=0D=0ALSP:=20Label=20Switching=20Path=0D=0ALSR:=20= Label=20Switching=20Router=0D=0AMIB:=20Management=20Information=20Base=0D= =0AMPLS:=20Multi-Protocol=20Label=20Switching=0D=0AMPLS-TP:=20MPLS=20= Transport=20Profile=0D=0AOSPF:=20Open=20Shortest=20Path=20First=0D=0APW:=20= Pseudowire=0D=0ATE:=20Traffic=20Engineering=0D=0ATP:=20Transport=20= Profile=0D=0A=0D=0A.ti=200=0D=0A4.=20Motivations=0D=0A=0D=0A.fi=0D=0A= Multiprotocol=20Label=20Switching=20(MPLS)=20Traffic=20Engineering=20= (TE)=20Management=20Information=20Base=20(MIB)=20[RFC3812]=20provides=20= support=20for=20Traffic=20Engineering=20tunnels.=20However,=20with=20= MPLS-TP,=20the=20characteristics=20of=20Tunnels=20were=20enhanced.=20For=20= example,=20MPLS-TP=20tunnels=20are=20bidirectional=20in=20nature=20and=20= could=20be=20used=20in=20non-IP=20environment.=20As=20the=20existing=20= MPLS-TE-STD-MIB=20is=20not=20sufficient=20to=20capture=20all=20the=20= characteristics=20of=20the=20tunnels,=20enhancing=20the=20MIB=20to=20= support=20MPLS=20TP=20tunnels=20is=20required.=20As=20most=20of=20the=20= attributes=20of=20MPLS=20Traffic=20Engineering=20tunnels=20are=20also=20= applicable=20to=20MPLS-TP=20tunnels,=20it=20is=20optimal=20to=20re-use=20= the=20existing=20MIB=20definition=20instead=20of=20a=20new=20MIB.=0D=0A=0D= =0AThis=20MIB=20also=20defines=20three=20other=20MIB=20modules=20within=20= this=20document.=20As=20these=20new=20MIB=20modules=20are=20small=20in=20= size,=20MPLS-TC-EXT-STD-MIB,=20MPLS-ID-STD-MIB=20and=20= MPLS-LSR-EXT-STD-MIB=20are=20retained=20in=20the=20same=20document,=20= instead=20of=20a=20separate=20document.=0D=0A=0D=0A.ti=200=0D=0A5.=20= Feature=20List=0D=0A=0D=0AThe=20MPLS=20transport=20profile=20MIB=20= module=20is=20designed=20to=20satisfy=20the=20following=20requirements=20= and=20constraints:=0D=0A=0D=0AThe=20MIB=20module=20supports=20static=20= and=20signaling=20point-to-point,=20co-routed=20\%bi-directional=20and=20= associated=20bi-directional=20tunnels.=0D=0A=0D=0A.nf=0D=0A.in=206=0D=0A= -=20=20The=20MPLS=20tunnels=20need=20not=20be=20interfaces,=20but=20it=20= is=20possible=0D=0A=20=20=20to=20configure=20a=20TP=20tunnel=20as=20an=20= interface.=0D=0A=0D=0A.fi=0D=0A.in=209=0D=0A.ti=206=0D=0A-=20=20The=20= mplsTunnelTable=20[RFC3812]=20to=20be=20also=20used=20for=20MPLS-TP=20= tunnels=0D=0A=0D=0A.ti=206=0D=0A-=20=20The=20mplsTunnelTable=20is=20= extended=20to=20support=20MPLS-TP=20specific=20objects.=0D=0A=0D=0A.nf=0D= =0A.in=206=0D=0A-=20=20A=20node=20configuration=20table=20= (mplsTunnelExtNodeConfigTable)=0D=0A=20=20=20is=20used=20to=20translate=20= the=20Global_Node_ID=20or=20ICC=20to=20the=20local=0D=0A=20=20=20= identifier=20in=20order=20to=20index=20mplsTunnelTable.=0D=0A=0D=0A.fi=0D= =0A.in=209=0D=0A.ti=206=0D=0A-=20=20The=20MIB=20module=20supports=20= persistent,=20as=20well=20as=20non-persistent=20tunnels.=0D=0A=0D=0A=0D=0A= .ti=200=0D=0A6.=20Brief=20description=20of=20MIB=20Objects=0D=0A=0D=0A=0D= =0A.in=203=0D=0AThe=20objects=20described=20in=20this=20section=20= support=20the=20functionality=20described=20in=20documents=20[RFC5654]=20= and=20[RFC6370].=20=20The=20tables=20support=20both=20IP=20compatible=20= and=20ICC=20based=20tunnel=20configurations.=0D=0A=0D=0A.ti=200=0D=0A= 6.1.=20mplsTunnelExtNodeConfigTable=0D=0A=0D=0A.nf=0D=0AThe=20= mplsTunnelExtNodeConfigTable=20is=20used=20to=20assign=20a=20local=20= identifier=0D=0Afor=20a=20given=20ICC=20or=20Global_Node_ID=20= combination=20as=20defined=20in=0D=0A[RFC6370].=20An=20ICC=20is=20a=20= string=20of=20one=20to=20six=20characters,=20each=0D=0Acharacter=20being=20= either=20alphabetic=20(i.e.=20A-Z)=20or=20numeric=20(i.e.=200-9)=0D=0A= characters.=20Alphabetic=20characters=20in=20the=20ICC=20should=20be=20= represented=0D=0Awith=20upper=20case=20letters.=20In=20the=20IP=20= compatible=20mode,=0D=0AGlobal_Node_ID,=20is=20used=20to=20uniquely=20= identify=20a=20node.=0D=0A=0D=0AEach=20ICC=20or=20Global_Node_ID=20= contains=20one=20unique=20entry=20in=20the=0D=0Atable=20representing=20a=20= node.=20Every=20node=20is=20assigned=20a=20local=20identifier=0D=0A= within=20a=20range=20of=200=20to=2016777215.=20This=20local=20identifier=20= is=20used=20for=0D=0Aindexing=20into=20mplsTunnelTable=20as=20= mplsTunnelIngressLSRId=20and=0D=0AmplsTunnelEgressLSRId.=0D=0A=0D=0A.fi=0D= =0AFor=20IP=20compatible=20environment,=20MPLS-TP=20tunnel=20is=20= indexed=20by=20Tunnel=20Index,=20Tunnel=20Instance,=20Source=20= Global_ID,=20Source=20Node_ID,=20Destination=20Global_ID=20and=20= Destination=20Node_ID.=0D=0A=0D=0AFor=20ICC=20based=20environment,=20= MPLS-TP=20tunnel=20is=20indexed=20by=20Tunnel=20Index,=20Tunnel=20= Instance,=20Source=20ICC=20and=20Destination=20ICC.=0D=0A=0D=0A.nf=0D=0A= As=20mplsTunnelTable=20is=20indexed=20by=20mplsTunnelIndex,=0D=0A= mplsTunnelInstance,=20mplsTunnelIngressLSRId,=20and=0D=0A= mplsTunnelEgressLSRId,=20the=20MPLS-TP=20tunnel=20identifiers=20cannot=20= be=0D=0Aused=20directly.=0D=0A=0D=0A.fi=0D=0AThe=20= mplsTunnelExtNodeConfigTable=20will=20be=20used=20to=20store=20an=20= entry=20for=20ICC=20or=20Global_Node_ID=20with=20a=20local=20identifier=20= to=20be=20used=20as=20LSR=20ID=20in=20mplsTunnelTable.=20As=20the=20= regular=20TE=20tunnels=20use=20IP=20address=20as=20LSR=20ID,=20the=20= local=20identifier=20should=20be=20below=20the=20first=20valid=20IP=20= address,=20which=20is=2016777216[1.0.0.0].=0D=0A=0D=0A.ti=200=0D=0A6.2.=20= mplsTunnelExtNodeIpMapTable=0D=0A=0D=0A.nf=0D=0AThe=20read-only=20= mplsTunnelExtNodeIpMaptable=20is=20used=20to=20query=20the=20local=0D=0A= identifier=20assigned=20and=20stored=20in=20mplsTunnelExtNodeConfigTable=20= for=0D=0Aa=20given=20Global_Node_ID.=20In=20order=20to=20query=20the=20= local=20identifier,=0D=0Ain=20the=20IP=20compatible=20mode,=20this=20= table=20is=20indexed=20with=20Global_Node_ID.=0D=0AIn=20the=20IP=20= compatible=20mode=20for=20a=20TP=20tunnel,=20Global_Node_ID=0D=0Ais=20= used.=0D=0A=0D=0A.ne=203=0D=0AA=20separate=20query=20is=20made=20to=20= get=20the=20local=20identifier=20of=20both=0D=0AIngress=20and=20Egress=20= Global_Node_ID=20identifiers.=20These=20local=0D=0Aidentifiers=20are=20= used=20as=20mplsTunnelIngressLSRId=20and=0D=0AmplsTunnelEgressLSRId,=20= while=20indexing=20mplsTunnelTable.=0D=0A=0D=0A=0D=0A.ti=200=0D=0A6.3.=20= mplsTunnelExtNodeIccMapTable=0D=0A=0D=0A.fi=0D=0AThe=20read-only=20= mplsTunnelExtNodeIccMapTable=20is=20used=20to=20query=20the=20local=20= identifier=20assigned=20and=20stored=20in=20the=20= mplsTunnelExtNodeConfigTable=20for=20a=20given=20ICC.=0D=0A=0D=0A.nf=0D=0A= A=20separate=20query=20is=20made=20to=20get=20the=20local=20identifier=20= of=20both=0D=0AIngress=20and=20Egress=20ICC.=20These=20local=20= identifiers=20are=20used=20as=0D=0AmplsTunnelIngressLSRId=20and=20= mplsTunnelEgressLSRId,=0D=0Awhile=20indexing=20mplsTunnelTable.=0D=0A=0D=0A= .ti=200=0D=0A6.4.=20mplsTunnelExtTable=0D=0A=0D=0A.fi=0D=0A= mplsTunnelExtTable=20extends=20the=20mplsTunnelTable=20in=20order=20to=20= support=20MPLS-TP=20tunnels=20with=20additional=20objects.=20All=20the=20= additional=20attributes=20specific=20to=20supporting=20TP=20tunnel=20are=20= contained=20in=20this=20extended=20table=20and=20could=20be=20accessed=20= with=20the=20mplsTunnelTable=20indices.=0D=0A=0D=0A.ti=200=0D=0A6.5.=20= mplsTunnelExtReversePerfTable=0D=0A=0D=0AThis=20table=20augments=20the=20= mplsTunnelTable=20to=20provide=20per-tunnel=20packet=20performance=20= information=20for=20the=20reverse=20direction=20of=20a=20bidirectional=20= tunnel.=20It=20can=20be=20seen=20as=20supplementing=20the=20= mplsTunnelPerfTable,=20which=20augments=20the=20mplsTunnelTable.=0D=0A=0D= =0A.ti=200=0D=0A7.=20MIB=20Module=20Interdependencies=0D=0A=0D=0AThis=20= section=20provides=20an=20overview=20of=20the=20relationship=20between=20= the=20\%MPLS-TP=20TE=20MIB=20module=20and=20other=20MPLS=20MIB=20= modules.=0D=0A=0D=0A.nf=0D=0AThe=20arrows=20in=20the=20following=20= diagram=20show=20a=20'depends=20on'=0D=0Arelationship.=20A=20= relationship=20"MIB=20module=20A=20depends=20on=20MIB=20module=20B"=0D=0A= means=20that=20MIB=20module=20A=20uses=20an=20object,=20object=20= identifier,=20or=0D=0Atextual=20convention=20defined=20in=20MIB=20module=20= B,=20or=20that=20MIB=20module=20A=0D=0Acontains=20a=20pointer=20(index=20= or=20RowPointer)=20to=20an=20object=20in=0D=0AMIB=20module=20B.=0D=0A=0D=0A= .bp=0D=0A.in=207=0D=0AMPLS-TC-EXT-STD-MIB=0D=0A=20=20=20^=0D=0A=20=20=20= |=0D=0A=20=20=20|=0D=0A=20=20=20+<----=20MPLS-ID-STD-MIB=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20^=0D=0A=20=20=20|=20=20=20=20=20=20= =20=20=20=20=20=20=20|=0D=0A=20=20=20+<----=20MPLS-TE-EXT-STD-MIB=0D=0A=20= =20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20|=0D=0A=20=20=20|=20=20=20=20= =20=20=20=20=20=20=20=20=20V=0D=0A=20=20=20|=20=20=20=20=20=20= MPLS-TE-STD-MIB=0D=0A=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20|=0D= =0A=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20|=0D=0A=20=20=20|=20=20= =20=20=20=20=20=20=20=20=20=20=20V=0D=0A=20=20=20|=20=20=20=20=20=20= MPLS-LSR-STD-MIB=0D=0A=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20^=0D= =0A=20=20=20|=20=20=20=20=20=20=20=20=20=20=20=20=20|=0D=0A=20=20=20|=20=20= =20=20=20=20=20=20=20=20=20=20=20|=0D=0A=20=20=20= +------MPLS-LSR-EXT-STD-MIB=0D=0A=0D=0AThus:=0D=0A=0D=0A.fi=0D=0A.in=20= 11=0D=0A.ti=208=0D=0A-=20=20All=20the=20new=20MPLS=20extension=20MIB=20= modules=20depend=20on=20\%MPLS-TC-EXT-STD-MIB.=0D=0A=0D=0A.ti=208=0D=0A-=20= =20MPLS-ID-STD-MIB=20contains=20references=20to=20objects=20in=20= \%MPLS-TE-STD-MIB=20[RFC3812].=0D=0A=0D=0A.ti=208=0D=0A-=20=20= MPLS-TE-EXT-STD-MIB=20contains=20references=20to=20objects=20in=20= \%MPLS-TE-STD-MIB=20[RFC3812].=0D=0A=0D=0A.ti=208=0D=0A-=20=20= MPLS-LSR-EXT-STD-MIB=20contains=20references=20to=20objects=20in=20= \%MPLS-LSR-STD-MIB=20[RFC3813].=0D=0A=0D=0A.nf=0D=0A.in=203=0D=0A= MPLS-TE-STD-MIB=20[RFC3812]=20is=20extended=20by=20MPLS-TE-EXT-STD-MIB=0D= =0AMIB=20module=20for=20associating=20the=20reverse=20direction=20tunnel=0D= =0Ainformation.=0D=0A=0D=0ANote=20that=20the=20nature=20of=20the=20= 'extends'=20relationship=0D=0Ais=20a=20sparse=20augmentation=20so=20that=20= the=20entry=20in=20the=0D=0AmplsTunnelExtTable=20has=20the=20same=20= index=20values=20as=20the=20in=20the=0D=0AmplsTunnelTable.=0D=0A=0D=0A= MPLS-LSR-STD-MIB=20[RFC3813]=20is=20extended=20by=20MPLS-LSR-EXT-STD-MIB=0D= =0AMIB=20module=20for=20pointing=20back=20to=20the=20tunnel=20entry=20= for=20easy=20tunnel=0D=0Aaccess=20from=20XC=20entry.=0D=0A=0D=0ANote=20= that=20the=20nature=20of=20the=20'extends'=20relationship=0D=0A=0D=0Ais=20= a=20sparse=20augmentation=20so=20that=20the=20entry=20in=20the=0D=0A= mplsXCExtTable=20has=20the=20same=20index=20values=20as=20the=20in=20the=20= mplsXCTable.=0D=0A=0D=0A.ti=200=0D=0A8.=20Dependencies=20between=20MIB=20= Module=20Tables=0D=0A=0D=0A.fi=0D=0AThe=20tables=20in=20= MPLS-TE-EXT-STD-MIB=20are=20related=20as=20shown=20on=20the=20diagram=20= below.=20=20The=20arrows=20indicate=20a=20reference=20from=20one=20table=20= to=20another.=0D=0A=0D=0A.nf=0D=0A.in=2019=0D=0A= mplsTunnelExtNodeConfigTable=0D=0A=20=20=20=20=20=20=20=20=20^=20=20=20=20= =20=20=20=20=20=20=20=20=20=20mplsXCExtTable=0D=0A=20=20=20=20=20=20=20=20= =20|=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20|=20=20=20=20=20=20^=0D=0A= =20=20=20=20=20=20=20=20=20|=20=20=20=20=20+---------+=20=20=20=20=20=20= |=0D=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20|=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20|=0D=0A=20=20=20=20=20=20=20=20=20|=20=20=20=20=20= V=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20V=0D=0A=20=20=20= mplsTunnelTable=20---->mplsXCTable=0D=0A=20=20=20=20=20=20=20=20=20^=0D=0A= =20=20=20=20=20=20=20=20=20|=0D=0A=20=20=20=20=20=20=20=20=20|=0D=0A=20=20= =20mplsTunnelExtTable=0D=0A=0D=0A.fi=0D=0A.in=203=0D=0AAn=20existing=20= mplsTunnelTable=20uses=20the=20mplsTunnelExtNodeConfigTable=20table=20to=20= map=20the=20Global_Node_ID=20and/or=20ICC=20with=20the=20local=20number=20= in=20order=20to=20accommodate=20in=20the=20existing=20tunnel=20table's=20= ingress/egress=20\%LSR-id.=0D=0A=0D=0ANew=20mplsTunnelExtTable=20table=20= provides=20the=20reverse=20direction=20LSP=20information=20for=20the=20= existing=20tunnel=20table=20in=20order=20to=20achieve=20bidirectional=20= LSPs.=0D=0A=0D=0A.nf=0D=0AmplsXCExtTable=20is=20extended=20from=20= mplsLsrXCTable=20to=20provide=0D=0Abackward=20reference=20to=20tunnel=20= entry.=0D=0A=0D=0A.in=200=0D=0A9.=20Example=20of=20MPLS-TP=20Tunnel=20= Setup=0D=0A=20=20=20In=20this=20section,=20we=20provide=20an=20example=20= of=20the=20IP=20based=20MPLS-TP=0D=0A=20=20=20bidirectional=20tunnel=20= setup.=20This=20example=20provides=20the=20usage=20of=0D=0A=20=20=20= \%MPLS-TP=20Tunnel=20MIB=20along=20with=20the=20extended=20new=20MIB=20= modules=20introduced=0D=0A=20=20=20in=20this=20document.=0D=0A=0D=0A.fi=0D= =0A.in=203=0D=0ADo=20note=20that=20a=20MPLS-TP=20tunnel=20could=20be=20= setup=20statically=20as=20well=20as=20signaled=20via=20control=20plane.=20= This=20example=20considers=20accessing=20MIB=20objects=20on=20a=20= head-end=20for=20a=20static=20and=20signaling=20MPLS-TP=20tunnels.=20= Only=20relevant=20objects=20which=20are=20applicable=20for=20MPLS-TP=20= tunnel=20are=20illustrated=20here.=0D=0A=0D=0AIn=20= mplsTunnelExtNodeConfigTable:=0D=0A=0D=0A.nf=0D=0A{=0D=0A--=20Non-IP=20= Ingress=20LSR-Id=20(Index=20to=20the=20table)=0D=0A=0D=0A.ti=205=0D=0A= mplsTunnelExtNodeConfigLocalId=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=201,=0D=0A=0D=0A=20=20mplsTunnelExtNodeConfigGlobalId=20=20=20=20=20=20= =20=20=20=20=20=20=20=3D=201234,=0D=0A=20=20= mplsTunnelExtNodeConfigNodeId=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=2010,=0D=0A--=20Mandatory=20parameters=20needed=20to=20activate=20= the=20row=20go=20here=0D=0A=20=20mplsTunnelExtNodeConfigRowStatus=20=20=20= =20=20=20=20=20=20=3D=20createAndGo=20(4)=0D=0A=0D=0A--=20Non-IP=20= Egress=20LSR-Id=20(Index=20to=20the=20table)=0D=0A=20=20= mplsTunnelExtNodeConfigLocalId=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=202,=0D=0A=20=20mplsTunnelExtNodeConfigGlobalId=20=20=20=20=20=20=20=20= =20=20=20=20=20=3D=201234,=0D=0A=20=20mplsTunnelExtNodeConfigNodeId=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=3D=2020,=0D=0A--=20Mandatory=20= parameters=20needed=20to=20activate=20the=20row=20go=20here=0D=0A=20=20= mplsTunnelExtNodeConfigRowStatus=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0AThis=20will=20create=20an=20entry=20= in=20the=20mplsTunnelExtNodeConfigTable=20for=20a=0D=0AGlobal_Node_ID.=20= A=20separate=20entry=20is=20made=20for=20both=20Ingress=20LSR=0D=0Aand=20= Egress=20LSR.=0D=0A=0D=0AThe=20following=20read-only=20= mplsTunnelExtNodeIpMapTable=20table=20is=0D=0Apopulated=20automatically=20= upon=20creating=20an=20entry=20in=0D=0AmplsTunnelExtNodeConfigTable=20= and=20this=20table=20is=20used=20to=20retrieve=0D=0Athe=20local=20= identifier=20for=20the=20given=20Global_Node_ID.=0D=0A=0D=0AIn=20= mplsTunnelExtNodeIpMapTable:=0D=0A=0D=0A{=0D=0A--=20Global_ID=20(Index=20= to=20the=20table)=0D=0A=20=20mplsTunnelExtNodeIpMapGlobalId=20=20=20=20=20= =20=20=20=20=20=20=20=20=3D=201234,=0D=0A--=20Node=20Identifier=20(Index=20= to=20the=20table)=0D=0A=20=20mplsTunnelExtNodeIpMapNodeId=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=3D=2010,=0D=0A=20=20= mplsTunnelExtNodeIpMapLocalId=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D= =201=0D=0A=0D=0A--=20Global_ID=20(Index=20to=20the=20table)=0D=0A=20=20= mplsTunnelExtNodeIpMapGlobalId=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20= 1234,=0D=0A--=20Node=20Identifier=20(Index=20to=20the=20table)=0D=0A=20=20= mplsTunnelExtNodeIpMapNodeId=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=2020,=0D=0A=20=20mplsTunnelExtNodeIpMapLocalId=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=3D=202=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.1.=20Example=20= of=20MPLS-TP=20static=20co-routed=20bidirectional=20tunnel=20setup=0D=0A=0D= =0AThe=20following=20denotes=20the=20configured=20co-routed=20= bidirectional=0D=0Atunnel=20"head"=20entry:=0D=0A=0D=0A.ti=200=0D=0A= 9.1.1.=20mplsTunnelEntry=0D=0A=0D=0A.ti=205=0D=0AIn=20mplsTunnelTable:=0D= =0A=0D=0A{=0D=0A=20=20mplsTunnelIndex=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=3D=201,=0D=0A=20=20mplsTunnelInstance=20=20=20=20=20=20=20=20=20=20= =20=3D=201,=0D=0A--=20Local=20map=20number=20created=20in=20= mplsTunnelExtNodeConfigTable=20for=0D=0A--=20Ingress=20LSR-Id=0D=0A=20=20= mplsTunnelIngressLSRId=20=20=20=20=20=20=20=3D=201,=0D=0A=0D=0A--=20= Local=20map=20number=20created=20in=20mplsTunnelExtNodeConfigTable=20for=0D= =0A--=20Egress=20LSR-Id=0D=0A=20=20mplsTunnelEgressLSRId=20=20=20=20=20=20= =20=20=3D=202,=0D=0A=20=20mplsTunnelName=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=3D=20"TP=20co-routed=20bidirectional=20LSP",=0D=0A=20=20= mplsTunnelDescr=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20"East=20= to=20West",=0D=0A=20=20mplsTunnelIsIf=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=3D=20true=20(1),=0D=0A--=20=20RowPointer=20MUST=20point=20to=20= the=20first=20accessible=20column=0D=0A=20=20mplsTunnelXCPointer=20=20=20= =20=20=20=20=20=20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20= mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D=0A=20=20= mplsTunnelSignallingProto=20=20=20=20=3D=20none=20(1),=0D=0A=20=20= mplsTunnelSetupPrio=20=20=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelHoldingPrio=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelSessionAttributes=20=20=3D=200,=0D=0A=20=20= mplsTunnelLocalProtectInUse=20=20=3D=20false=20(0),=0D=0A--=20=20= RowPointer=20MUST=20point=20to=20the=20first=20accessible=20column=0D=0A=20= =20mplsTunnelResourcePointer=20=20=20=20=3D=20= mplsTunnelResourceMaxRate.5,=0D=0A=20=20mplsTunnelInstancePriority=20=20=20= =3D=201,=0D=0A=20=20mplsTunnelHopTableIndex=20=20=20=20=20=20=3D=201,=0D=0A= =20=20mplsTunnelIncludeAnyAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelIncludeAllAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelExcludeAnyAffinity=20=3D=200,=0D=0A=20=20mplsTunnelRole=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=3D=20head=20(1),=0D=0A--=20= Mandatory=20parameters=20needed=20to=20activate=20the=20row=20go=20here=0D= =0A=20=20mplsTunnelRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.1.2.=20= mplsTunnelExtEntry=0D=0A=0D=0A--=20An=20MPLS=20extension=20table=0D=0AIn=20= mplsTunnelExtTable:=0D=0A{=0D=0A=20=20--=20This=20opposite=20direction=20= tunnel=20pointer=20MAY=20be=20point=20to=200.0=0D=0A=20=20--=20if=20= co-routed=20bidirectional=20tunnel=20is=20managed=20by=20single=20tunnel=0D= =0A=20=20\%--=20entry=0D=0A=20=20mplsTunnelExtOppositeDirTnlPtr=20=20=20=20= =20=20=20=3D=200.0=0D=0A=20=20--=20Set=20both=20the=20Ingress=20and=20= Egress=20LocalId=20objects=20to=20TRUE=20as=0D=0A=20=20--=20this=20= tunnel=20entry=20uses=20the=20local=20identifiers.=0D=0A=20=20= mplsTunnelExtIngressLSRLocalIdValid=20=20=3D=20true,=0D=0A=20=20= mplsTunnelExtEgressLSRLocalIdValid=20=3D=20true=0D=0A=0D=0A}=0D=0A=0D=0A= .fi=0D=0AWe=20must=20next=20create=20the=20appropriate=20in-segment=20= and=20out-segment=20entries.=20These=20are=20done=20in=20[RFC3813]=20= using=20the=20mplsInSegmentTable=20and=20mplsOutSegmentTable.=0D=0A=0D=0A= .ti=200=0D=0A9.1.3.=20Forward=20direction=20mplsOutSegmentEntry=0D=0A=0D=0A= For=20the=20forward=20direction.=0D=0A=0D=0A.nf=0D=0AIn=20= mplsOutSegmentTable:=0D=0A{=0D=0A=20=20=20mplsOutSegmentIndex=20=20=20=20= =20=20=20=20=20=20=3D=200x0000001,=0D=0A=20=20=20mplsOutSegmentInterface=20= =20=20=20=20=20=3D=2013,=20--=20outgoing=20interface=0D=0A=20=20=20= mplsOutSegmentPushTopLabel=20=20=20=3D=20true(1),=0D=0A=20=20=20= mplsOutSegmentTopLabel=20=20=20=20=20=20=20=3D=2022,=20--=20outgoing=20= label=0D=0A=0D=0A=20=20=20--=20RowPointer=20MUST=20point=20to=20the=20= first=20accessible=20column.=0D=0A=20=20=20mplsOutSegmentTrafficParamPtr=20= =20=20=3D=200.0,=0D=0A=20=20=20mplsOutSegmentRowStatus=20=20=20=20=20=20=20= =20=20=3D=20createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.1.4.=20= Reverse=20direction=20mplsInSegmentEntry=0D=0A=0D=0A.ti=205=0D=0AFor=20= the=20reverse=20direction.=0D=0A=0D=0AIn=20mplsInSegmentTable:=0D=0A{=0D=0A= =20=20=20mplsInSegmentIndex=20=20=20=20=20=20=20=20=20=20=20=3D=20= 0x0000001=0D=0A=20=20=20mplsInSegmentLabel=20=20=20=20=20=20=20=20=20=20=20= =3D=2021,=20--=20incoming=20label=0D=0A=20=20=20mplsInSegmentNPop=20=20=20= =20=20=20=20=20=20=20=20=20=3D=201,=0D=0A=20=20=20mplsInSegmentInterface=20= =20=20=20=20=20=20=3D=2013,=20--=20incoming=20interface=0D=0A=0D=0A=20=20= =20--=20RowPointer=20MUST=20point=20to=20the=20first=20accessible=20= column.=0D=0A=20=20=20mplsInSegmentTrafficParamPtr=20=20=20=20=3D=200.0,=0D= =0A=20=20=20mplsInSegmentRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.fi=0D=0ANext,=20two=20cross-connect=20= entries=20are=20created=20in=20the=20mplsXCTable=20of=20the=20= \%MPLS-LSR-STD-MIB=20[RFC3813],=20thereby=20associating=20the=20newly=20= created=20segments=20together.=0D=0A=0D=0A.ti=200=0D=0A9.1.5.=20Forward=20= direction=20mplsXCEntry=0D=0A=0D=0A.nf=0D=0AIn=20mplsXCTable:=0D=0A{=0D=0A= =20=20=20mplsXCIndex=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20= 0x01,=0D=0A=20=20=20mplsXCInSegmentIndex=20=20=20=20=20=20=20=3D=20= 0x00000000,=0D=0A=20=20=20mplsXCOutSegmentIndex=20=20=20=20=20=20=3D=20= 0x00000001,=0D=0A=20=20=20mplsXCLspId=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=3D=200x0102=20--=20unique=20ID=0D=0A=0D=0A.in=206=0D=0A--=20= only=20a=20single=20outgoing=20label=0D=0AmplsXCLabelStackIndex=20=20=20=20= =20=20=3D=200x00,=0D=0AmplsXCRowStatus=20=20=20=20=20=20=20=20=20=20=20=20= =3D=20createAndGo(4)=0D=0A=0D=0A.ti=203=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A= 9.1.6.=20Reverse=20direction=20mplsXCEntry=0D=0A=0D=0A.in=203=0D=0AIn=20= mplsXCTable:=0D=0A{=0D=0A=20=20=20mplsXCIndex=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=3D=200x01,=0D=0A=20=20=20mplsXCInSegmentIndex=20=20=20= =20=20=20=20=3D=200x00000001,=0D=0A=20=20=20mplsXCOutSegmentIndex=20=20=20= =20=20=20=3D=200x00000000,=0D=0A=20=20=20mplsXCLspId=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=3D=200x0102=20--=20unique=20ID=0D=0A=20=20=20= --=20only=20a=20single=20outgoing=20label=0D=0A=20=20=20= mplsXCLabelStackIndex=20=20=20=20=20=20=3D=200x00,=0D=0A=20=20=20= mplsXCRowStatus=20=20=20=20=20=20=20=20=20=20=20=20=3D=20createAndGo(4)=0D= =0A}=0D=0A=0D=0AThis=20table=20entry=20is=20extended=20by=20entry=20in=20= the=0D=0AmplsXCExtTable.=20=20Note=20that=20the=20nature=20of=20the=20= 'extends'=0D=0Arelationship=20is=20a=20sparse=20augmentation=20so=20that=20= the=20entry=20in=20the=0D=0AmplsXCExtTable=20has=20the=20same=20index=20= values=20as=20the=20entry=20in=0D=0Athe=20mplsXCTable.=0D=0A=0D=0A.ti=20= 0=0D=0A9.1.7.=20Forward=20direction=20mplsXCExtEntry=0D=0A=0D=0AIn=20= mplsXCExtTable=20(0x01,=200x00000000,=200x00000001)=0D=0A{=0D=0A=20=20--=20= Back=20pointer=20from=20XC=20table=20to=20Tunnel=20table=0D=0A=20=20= mplsXCExtTunnelPointer=20=20=20=20=20=20=20=20=20=3D=20= mplsTunnelName.1.1.1.2=0D=0A=20=20mplsXCExtOppositeDirXCPtr=20=20=20=20=20= =20=20=20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0=0D= =0A}=0D=0A=0D=0A.ti=200=0D=0A9.1.8.=20Reverse=20direction=20= mplsXCExtEntry=0D=0A=0D=0ANext=20for=20the=20reverse=20direction:=0D=0A=0D= =0AIn=20mplsXCExtTable=20(0x01,=200x00000001,=200x00000000)=0D=0A{=0D=0A=20= =20--=20Back=20pointer=20from=20XC=20table=20to=20Tunnel=20table=0D=0A=20= =20mplsXCExtTunnelPointer=20=20=20=20=20=20=20=20=20=3D=20= mplsTunnelName.1.1.1.2=0D=0A=20=20mplsXCExtOppositeDirXCPtr=20=20=20=20=20= =20=20=20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1=0D= =0A}=0D=0A=0D=0A.ti=200=0D=0A9.1.9.=20mplsTunnelExtReversePerfTable=0D=0A= =0D=0AThe=20mplsTunnelExtReversePerfTable=20SHOULD=20be=20populated=20= incase=0D=0Athe=20single=20tunnel=20entry=20is=20used=20for=20co-routed=20= bidirectional=20tunnel=0D=0Asetup.=20The=20mplsTunnelPerfTable=20will=20= have=20the=20forward=20direction=0D=0ALSP=20performance=20counters=20and=20= mplsTunnelExtReversePerfTable=20will=20have=0D=0Athe=20reverse=20= direction=20LSP=20performance=20counters.=0D=0A=0D=0A.ti=200=0D=0A9.2.=20= Example=20of=20MPLS-TP=20static=20associated=20bidirectional=20tunnel=20= setup=0D=0A=0D=0AThe=20MPLS-TP=20associated=20bidirectional=20tunnel=20= has=20two=20different=0D=0Adirection=20tunnels[Forward=20and=20Reverse=20= LSPs]=20and=20these=20are=0D=0Aassociated=20together=20using=20= mplsTunnelExtTable.=20Two=20different=0D=0Atunnel=20entries=20for=20both=20= forward=20and=20reverse=20direction=20MAY=20be=20used=0D=0Afor=20= co-routed=20bidirectional=20tunnel=20as=20well.=0D=0A=0D=0A.fi=0D=0AThe=20= following=20denotes=20the=20configured=20associated=20bidirectional=20= forward=20tunnel=20"head"=20entry:=0D=0A=0D=0A.ti=200=0D=0A9.2.1.=20= Forward=20direction=20mplsTunnelEntry=0D=0A=0D=0A.ti=205=0D=0AIn=20= mplsTunnelTable:=0D=0A=0D=0A.nf=0D=0A{=0D=0A=20=20mplsTunnelIndex=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=3D=201,=0D=0A=20=20mplsTunnelInstance=20= =20=20=20=20=20=20=20=20=20=20=3D=201,=0D=0A--=20Local=20map=20number=20= created=20in=20mplsTunnelExtNodeConfigTable=20for=0D=0A--=20Ingress=20= LSR-Id=0D=0A=20=20mplsTunnelIngressLSRId=20=20=20=20=20=20=20=3D=201,=0D=0A= =0D=0A--=20Local=20map=20number=20created=20in=20= mplsTunnelExtNodeConfigTable=20for=0D=0A--=20Egress=20LSR-Id=0D=0A=20=20= mplsTunnelEgressLSRId=20=20=20=20=20=20=20=20=3D=202,=0D=0A=20=20= mplsTunnelName=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20"TP=20= associated=20bi-directional=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20forward=20= LSP",=0D=0A=20=20mplsTunnelDescr=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=20"East=20to=20West",=0D=0A=20=20mplsTunnelIsIf=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=3D=20true=20(1),=0D=0A--=20=20RowPointer=20MUST=20= point=20to=20the=20first=20accessible=20column=0D=0A=20=20= mplsTunnelXCPointer=20=20=20=20=20=20=20=20=20=20=3D=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D=0A=20=20= mplsTunnelSignallingProto=20=20=20=20=3D=20none=20(1),=0D=0A=20=20= mplsTunnelSetupPrio=20=20=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelHoldingPrio=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelSessionAttributes=20=20=3D=200,=0D=0A=20=20= mplsTunnelLocalProtectInUse=20=20=3D=20false=20(0),=0D=0A--=20=20= RowPointer=20MUST=20point=20to=20the=20first=20accessible=20column=0D=0A=20= =20mplsTunnelResourcePointer=20=20=20=20=3D=20= mplsTunnelResourceMaxRate.5,=0D=0A=20=20mplsTunnelInstancePriority=20=20=20= =3D=201,=0D=0A=20=20mplsTunnelHopTableIndex=20=20=20=20=20=20=3D=201,=0D=0A= =20=20mplsTunnelIncludeAnyAffinity=20=3D=200,=0D=0A=0D=0A=20=20= mplsTunnelIncludeAllAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelExcludeAnyAffinity=20=3D=200,=0D=0A=20=20mplsTunnelRole=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=3D=20head=20(1),=0D=0A--=20= Mandatory=20parameters=20needed=20to=20activate=20the=20row=20go=20here=0D= =0A=20=20mplsTunnelRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.2.2.=20Forward=20= direction=20mplsTunnelExtEntry=0D=0A=0D=0AFor=20Associated=20= bidirectional=20forward=20LSP,=0D=0AIn=20mplsTunnelExtTable:=0D=0A{=0D=0A= =20=20mplsTunnelExtOppositeDirPtr=20=20=20=20=20=20=20=3D=20= mplsTunnelName.2.1.2.1=0D=0A=20--=20Set=20both=20the=20Ingress=20and=20= Egress=20LocalId=20objects=20to=20TRUE=20as=0D=0A=20=20--=20this=20= tunnel=20entry=20uses=20the=20local=20identifiers.=0D=0A=20=20= mplsTunnelExtIngressLSRLocalIdValid=20=20=3D=20true,=0D=0A=20=20= mplsTunnelExtEgressLSRLocalIdValid=20=3D=20true=0D=0A}=0D=0A=0D=0A.ti=20= 0=0D=0A9.2.3.=20Forward=20direction=20mplsOutSegmentTable=0D=0A=0D=0AFor=20= the=20forward=20direction.=0D=0A=0D=0AIn=20mplsOutSegmentTable:=0D=0A{=0D= =0A=20=20=20mplsOutSegmentIndex=20=20=20=20=20=20=20=20=20=20=3D=20= 0x0000001,=0D=0A=20=20=20mplsOutSegmentInterface=20=20=20=20=20=20=3D=20= 13,=20--=20outgoing=20interface=0D=0A=20=20=20mplsOutSegmentPushTopLabel=20= =20=20=3D=20true(1),=0D=0A=20=20=20mplsOutSegmentTopLabel=20=20=20=20=20=20= =20=3D=2022,=20--=20outgoing=20label=0D=0A=0D=0A=20=20=20--=20RowPointer=20= MUST=20point=20to=20the=20first=20accessible=20column.=0D=0A=20=20=20= mplsOutSegmentTrafficParamPtr=20=20=20=3D=200.0,=0D=0A=20=20=20= mplsOutSegmentRowStatus=20=20=20=20=20=20=20=20=20=3D=20createAndGo=20= (4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.2.4.=20Forward=20direction=20= mplsXCEntry=0D=0A=0D=0AIn=20mplsXCTable:=0D=0A{=0D=0A=20=20=20= mplsXCIndex=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=200x01,=0D= =0A=20=20=20mplsXCInSegmentIndex=20=20=20=20=20=20=20=3D=200x00000000,=0D= =0A=20=20=20mplsXCOutSegmentIndex=20=20=20=20=20=20=3D=200x00000001,=0D=0A= =20=20=20mplsXCLspId=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20= 0x0102=20--=20unique=20ID=0D=0A=20=20=20--=20only=20a=20single=20= outgoing=20label=0D=0A=20=20=20mplsXCLabelStackIndex=20=20=20=20=20=20=3D=20= 0x00,=0D=0A=20=20=20mplsXCRowStatus=20=20=20=20=20=20=20=20=20=20=20=20=3D= =20createAndGo(4)=0D=0A=0D=0A}=0D=0A.bp=0D=0A.ti=200=0D=0A9.2.5.=20= Forward=20direction=20mplsXCExtEntry=0D=0A=0D=0AIn=20mplsXCExtTable=20= (0x01,=200x00000000,=200x00000001)=0D=0A{=0D=0A=20=20--=20Back=20pointer=20= from=20XC=20table=20to=20Tunnel=20table=0D=0A=20=20= mplsXCExtTunnelPointer=20=20=20=20=20=20=20=20=20=3D=20= mplsTunnelName.1.1.1.2=0D=0A=20=20mplsXCExtOppositeDirXCPtr=20=20=20=20=20= =20=20=20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0=0D=0A= }=0D=0A=0D=0A.ti=200=0D=0A9.2.6.=20Reverse=20direction=20mplsTunnelEntry=0D= =0A=0D=0A.fi=0D=0AThe=20following=20denotes=20the=20configured=20= associated=20bidirectional=20reverse=20tunnel=20"tail"=20entry:=0D=0A=0D=0A= .ti=207=0D=0AIn=20mplsTunnelTable:=0D=0A=0D=0A.nf=0D=0A{=0D=0A=20=20= mplsTunnelIndex=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=202,=0D=0A=20= =20mplsTunnelInstance=20=20=20=20=20=20=20=20=20=20=20=3D=201,=0D=0A--=20= Local=20map=20number=20created=20in=20mplsTunnelExtNodeConfigTable=20for=0D= =0A--=20Ingress=20LSR-Id=0D=0A=20=20mplsTunnelIngressLSRId=20=20=20=20=20= =20=20=3D=202,=0D=0A--=20Local=20map=20number=20created=20in=20= mplsTunnelExtNodeConfigTable=20for=0D=0A--=20Egress=20LSR-Id=0D=0A=20=20= mplsTunnelEgressLSRId=20=20=20=20=20=20=20=20=3D=201,=0D=0A=20=20= mplsTunnelName=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20"TP=20= associated=20bi-directional=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20reverse=20= LSP",=0D=0A=20=20mplsTunnelDescr=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =3D=20"West=20to=20East",=0D=0A=20=20mplsTunnelIsIf=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=3D=20true=20(1),=0D=0A--=20=20RowPointer=20MUST=20= point=20to=20the=20first=20accessible=20column=0D=0A=20=20= mplsTunnelXCPointer=20=20=20=20=20=20=20=20=20=20=3D=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= mplsXCLspId.4.0.0.0.1.4.0.0.0.1.1.0,=0D=0A=20=20= mplsTunnelSignallingProto=20=20=20=20=3D=20none=20(1),=0D=0A=20=20= mplsTunnelSetupPrio=20=20=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelHoldingPrio=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelSessionAttributes=20=20=3D=200,=0D=0A=20=20= mplsTunnelLocalProtectInUse=20=20=3D=20false=20(0),=0D=0A=0D=0A--=20=20= RowPointer=20MUST=20point=20to=20the=20first=20accessible=20column=0D=0A=20= =20mplsTunnelResourcePointer=20=20=20=20=3D=20= mplsTunnelResourceMaxRate.5,=0D=0A=20=20mplsTunnelInstancePriority=20=20=20= =3D=201,=0D=0A=20=20mplsTunnelHopTableIndex=20=20=20=20=20=20=3D=201,=0D=0A= =20=20mplsTunnelIncludeAnyAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelIncludeAllAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelExcludeAnyAffinity=20=3D=200,=0D=0A=20=20mplsTunnelRole=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=3D=20head=20(1),=0D=0A--=20= Mandatory=20parameters=20needed=20to=20activate=20the=20row=20go=20here=0D= =0A=0D=0A=20=20mplsTunnelRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.2.7.=20Reverse=20= direction=20mplsTunnelExtEntry=0D=0A=0D=0AFor=20Associated=20= bidirectional=20reverse=20LSP,=0D=0AIn=20mplsTunnelExtTable:=0D=0A{=0D=0A= =20=20mplsTunnelExtOppositeDirPtr=20=20=20=20=20=20=20=3D=20= mplsTunnelName.1.1.1.2=0D=0A=20=20--=20Set=20both=20the=20Ingress=20and=20= Egress=20LocalId=20objects=20to=20TRUE=20as=0D=0A=20=20--=20this=20= tunnel=20entry=20uses=20the=20local=20identifiers.=0D=0A=20=20= mplsTunnelExtIngressLSRLocalIdValid=20=20=3D=20true,=0D=0A=20=20= mplsTunnelExtEgressLSRLocalIdValid=20=3D=20true=0D=0A}=0D=0A=0D=0A.ti=20= 0=0D=0A9.2.8.=20Reverse=20direction=20mplsInSegmentEntry=0D=0A=0D=0A.fi=0D= =0AWe=20must=20next=20create=20the=20appropriate=20in-segment=20and=20= out-segment=20entries.=20These=20are=20done=20in=20[RFC3813]=20using=20= the=20mplsInSegmentTable=20and=20mplsOutSegmentTable.=0D=0A=0D=0A.nf=0D=0A= In=20mplsInSegmentTable:=0D=0A{=0D=0A=20=20=20mplsInSegmentIndex=20=20=20= =20=20=20=20=20=20=20=20=3D=200x0000001=0D=0A=20=20=20mplsInSegmentLabel=20= =20=20=20=20=20=20=20=20=20=20=3D=2021,=20--=20incoming=20label=0D=0A=20=20= =20mplsInSegmentNPop=20=20=20=20=20=20=20=20=20=20=20=20=3D=201,=0D=0A=20= =20=20mplsInSegmentInterface=20=20=20=20=20=20=20=3D=2013,=20--=20= incoming=20interface=0D=0A=0D=0A=20=20=20--=20RowPointer=20MUST=20point=20= to=20the=20first=20accessible=20column.=0D=0A=20=20=20= mplsInSegmentTrafficParamPtr=20=20=20=20=3D=200.0,=0D=0A=20=20=20= mplsInSegmentRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20createAndGo=20= (4)=0D=0A}=0D=0A=0D=0A.fi=0D=0ANext,=20two=20cross-connect=20entries=20= are=20created=20in=20the=20mplsXCTable=20of=20the=20\%MPLS-LSR-STD-MIB=20= [RFC3813],=20thereby=20associating=20the=20newly=20created=20segments=20= together.=0D=0A=0D=0A.ti=200=0D=0A9.2.9.=20Reverse=20direction=20= mplsXCEntry=0D=0A=0D=0A=0D=0A.nf=0D=0AIn=20mplsXCTable:=0D=0A{=0D=0A=20=20= =20mplsXCIndex=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20= 0x01,=0D=0A=20=20=20mplsXCInSegmentIndex=20=20=20=20=20=20=20=3D=20= 0x00000001,=0D=0A=20=20=20mplsXCOutSegmentIndex=20=20=20=20=20=20=3D=20= 0x00000000,=0D=0A=20=20=20mplsXCLspId=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=3D=200x0102=20--=20unique=20ID=0D=0A=20=20=20--=20only=20a=20= single=20outgoing=20label=0D=0A=20=20=20mplsXCLabelStackIndex=20=20=20=20= =20=20=3D=200x00,=0D=0A=0D=0A=20=20=20mplsXCRowStatus=20=20=20=20=20=20=20= =20=20=20=20=20=3D=20createAndGo(4)=0D=0A}=0D=0A=0D=0AThis=20table=20= entry=20is=20extended=20by=20entry=20in=20the=0D=0AmplsXCExtTable.=20=20= Note=20that=20the=20nature=20of=20the=20'extends'=0D=0Arelationship=20is=20= a=20sparse=20augmentation=20so=20that=20the=20entry=20in=20the=0D=0A= mplsXCExtTable=20has=20the=20same=20index=20values=20as=20the=20entry=20= in=0D=0Athe=20mplsXCTable.=0D=0A=0D=0A.ti=200=0D=0A9.2.10.=20Reverse=20= direction=20mplsXCExtEntry=0D=0A=0D=0ANext=20for=20the=20reverse=20= direction:=0D=0A=0D=0AIn=20mplsXCExtTable=20(0x01,=200x00000001,=20= 0x00000000)=0D=0A{=0D=0A=20=20--=20Back=20pointer=20from=20XC=20table=20= to=20Tunnel=20table=0D=0A=20=20mplsXCExtTunnelPointer=20=20=20=20=20=20=20= =20=20=3D=20mplsTunnelName.2.1.2.1=0D=0A=20=20mplsXCExtOppositeDirXCPtr=20= =20=20=20=20=20=20=20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20= mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1=0D=0A}=0D=0A=0D=0A.in=200=0D=0A9.3.=20= Example=20of=20MPLS-TP=20signaling=20co-routed=20bidirectional=20tunnel=20= setup=0D=0A=0D=0A.in=203=0D=0AThe=20following=20denotes=20the=20= configured=20co-routed=20bidirectional=0D=0Atunnel=20"head"=20entry=20= and=20in=20intermediate=20and=20tail-end=20nodes,=0D=0Athe=20tunnel=20= table=20and=20its=20associated=20tables=20are=20created=0D=0Aby=20the=20= local=20management=20subsystem=20(e.g.=20agent)=20when=20the=20MPLS=20TP=0D= =0Atunnel=20is=20signaled=20successfully.=20Refer=20[RFC3812]=20and=20= [RFC4802]=0D=0Afor=20signaling=20tunnel=20table=20configuration=20= examples.=0D=0A=0D=0A.ti=200=0D=0A9.3.1.=20mplsTunnelEntry=0D=0A=0D=0A= .ti=205=0D=0AIn=20mplsTunnelTable:=0D=0A=0D=0A{=0D=0A=20=20= mplsTunnelIndex=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=201,=0D=0A=20= =20mplsTunnelInstance=20=20=20=20=20=20=20=20=20=20=20=3D=200,=0D=0A--=20= Local=20map=20number=20created=20in=20mplsTunnelExtNodeConfigTable=20for=0D= =0A--=20Ingress=20LSR-Id,=20for=20the=20intermediate=20and=20tail-end=20= nodes,=0D=0A--=20the=20local=20management=20entity=20is=20expected=20to=20= pick=20a=20first=20available=0D=0A--=20local=20identifier=20which=20is=20= not=20used=20in=20mplsTunnelTable.=0D=0A=20=20mplsTunnelIngressLSRId=20=20= =20=20=20=20=20=3D=201,=0D=0A=0D=0A--=20Local=20map=20number=20created=20= in=20mplsTunnelExtNodeConfigTable=20for=0D=0A--=20Egress=20LSR-Id=0D=0A=20= =20mplsTunnelEgressLSRId=20=20=20=20=20=20=20=20=3D=202,=0D=0A=20=20= mplsTunnelName=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20"TP=20= co-routed=20bidirectional=20LSP",=0D=0A=20=20mplsTunnelDescr=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=3D=20"East=20to=20West",=0D=0A=20=20= mplsTunnelIsIf=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20true=20= (1),=0D=0A=0D=0A--=20=20RowPointer=20MUST=20point=20to=20the=20first=20= accessible=20column=0D=0A=20=20mplsTunnelXCPointer=20=20=20=20=20=20=20=20= =20=20=3D=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20mplsXCLspId.4.0.0.0.1.1.0.4.0.0.0.1,=0D=0A=20=20= mplsTunnelSignallingProto=20=20=20=20=3D=20none=20(1),=0D=0A=20=20= mplsTunnelSetupPrio=20=20=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelHoldingPrio=20=20=20=20=20=20=20=20=3D=200,=0D=0A=20=20= mplsTunnelSessionAttributes=20=20=3D=200,=0D=0A=20=20= mplsTunnelLocalProtectInUse=20=20=3D=20false=20(0),=0D=0A--=20=20= RowPointer=20MUST=20point=20to=20the=20first=20accessible=20column=0D=0A=20= =20mplsTunnelResourcePointer=20=20=20=20=3D=20= mplsTunnelResourceMaxRate.5,=0D=0A=20=20mplsTunnelInstancePriority=20=20=20= =3D=201,=0D=0A=20=20mplsTunnelHopTableIndex=20=20=20=20=20=20=3D=201,=0D=0A= =20=20mplsTunnelIncludeAnyAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelIncludeAllAffinity=20=3D=200,=0D=0A=20=20= mplsTunnelExcludeAnyAffinity=20=3D=200,=0D=0A=20=20mplsTunnelRole=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=3D=20head=20(1),=0D=0A--=20= Mandatory=20parameters=20needed=20to=20activate=20the=20row=20go=20here=0D= =0A=20=20mplsTunnelRowStatus=20=20=20=20=20=20=20=20=20=20=3D=20= createAndGo=20(4)=0D=0A}=0D=0A=0D=0A.ti=200=0D=0A9.3.2.=20= mplsTunnelExtEntry=0D=0A=0D=0A--=20An=20MPLS=20extension=20table=0D=0AIn=20= mplsTunnelExtTable:=0D=0A{=0D=0A=20=20--=20This=20opposite=20direction=20= tunnel=20pointer=20MAY=20be=20point=20to=200.0=0D=0A=20=20--=20if=20= co-routed=20bidirectional=20tunnel=20is=20managed=20by=20single=20tunnel=0D= =0A=20=20\%--=20entry=0D=0A=20=20mplsTunnelExtOppositeDirTnlPtr=20=20=20=20= =20=20=20=3D=200.0=0D=0A=20=20--=20Set=20both=20the=20Ingress=20and=20= Egress=20LocalId=20objects=20to=20TRUE=20as=0D=0A=20=20--=20this=20= tunnel=20entry=20uses=20the=20local=20identifiers.=0D=0A=20=20= mplsTunnelExtIngressLSRLocalIdValid=20=20=3D=20true,=0D=0A=20=20= mplsTunnelExtEgressLSRLocalIdValid=20=3D=20true=0D=0A}=0D=0A=0D=0A.fi=0D=0A= We=20must=20next=20create=20the=20appropriate=20in-segment=20and=20= out-segment=20entries.=20These=20are=20done=20in=20[RFC3813]=20using=20= the=20mplsInSegmentTable=20and=20mplsOutSegmentTable.=0D=0A=0D=0A.ti=200=0D= =0A9.3.3.=20Forward=20direction=20mplsOutSegmentEntry=0D=0A=0D=0AThe=20= forward=20direction=20mplsOutSegmentTable=20will=20be=20populated=20= automatically=20based=20on=20the=20information=20received=20from=20the=20= signaling=20protocol.=0D=0A=0D=0A.ti=200=0D=0A9.3.4.=20Reverse=20= direction=20mplsInSegmentEntry=0D=0A=0D=0AThe=20reverse=20direction=20= mplsOutSegmentTable=20will=20be=20populated=20automatically=20based=20on=20= the=20information=20received=20from=20the=20signaling=20protocol.=0D=0A=0D= =0ANext,=20two=20cross-connect=20entries=20are=20created=20in=20the=20= mplsXCTable=20of=20the=20\%MPLS-LSR-STD-MIB=20[RFC3813],=20thereby=20= associating=20the=20newly=20created=20segments=20together.=0D=0A=0D=0A= .ti=200=0D=0A9.3.5.=20Forward=20direction=20mplsXCEntry=0D=0A=0D=0AThe=20= forward=20direction=20mplsXCEntry=20will=20be=20populated=20as=20soon=20= as=20the=20forward=20path=20label=20information=20is=20available.=0D=0A=0D= =0A.ti=200=0D=0A9.3.6.=20Reverse=20direction=20mplsXCEntry=0D=0A=0D=0A= The=20reverse=20direction=20mplsXCEntry=20will=20be=20populated=20as=20= soon=20as=20the=20reverse=20path=20label=20information=20is=20available.=0D= =0A=0D=0AThis=20table=20entry=20is=20extended=20by=20entry=20in=20the=20= mplsXCExtTable.=20=20Note=20that=20the=20nature=20of=20the=20'extends'=20= relationship=20is=20a=20sparse=20augmentation=20so=20that=20the=20entry=20= in=20the=20mplsXCExtTable=20has=20the=20same=20index=20values=20as=20the=20= entry=20in=20the=20mplsXCTable.=0D=0A=0D=0A.ti=200=0D=0A9.3.7.=20Forward=20= direction=20mplsXCExtEntry=0D=0A=0D=0AOnce=20the=20forward=20path=20= information=20is=20negotiated=20using=20signaling=20protocol,=20the=20= forward=20direction=20mplsXCExtEntry=20will=20be=20created=20for=20= associating=20the=20opposite=20direction=20XC=20entry=20and=20tunnel=20= table=20entry.=0D=0A=0D=0A.ti=200=0D=0A9.3.8.=20Reverse=20direction=20= mplsXCExtEntry=0D=0A=0D=0AOnce=20the=20reverse=20path=20information=20is=20= negotiated=20using=20signaling=20protocol,=20the=20reverse=20direction=20= mplsXCExtEntry=20will=20be=20created=20for=20associating=20the=20= opposite=20direction=20XC=20entry=20and=20tunnel=20table=20entry.=0D=0A=0D= =0A.ti=200=0D=0A9.3.9.=20mplsTunnelExtReversePerfTable=0D=0A=0D=0AThe=20= mplsTunnelExtReversePerfTable=20SHOULD=20be=20populated=20incase=20the=20= single=20tunnel=20entry=20is=20used=20for=20co-routed=20bidirectional=20= tunnel=20setup.=20The=20mplsTunnelPerfTable=20will=20have=20the=20= forward=20direction=20LSP=20performance=20counters=20and=20= mplsTunnelExtReversePerfTable=20will=20have=20the=20reverse=20direction=20= LSP=20performance=20counters.=0D=0A=0D=0A.nf=0D=0A.in=200=0D=0A10.=20= MPLS=20Textual=20Convention=20Extension=20MIB=20definitions=0D=0A=20=20=20= \%MPLS-TC-EXT-STD-MIB=20DEFINITIONS=20::=3D=20BEGIN=0D=0A=0D=0A.in=203=0D= =0AIMPORTS=0D=0A=20=20=20MODULE-IDENTITY,=20Unsigned32=0D=0A=20=20=20=20=20= =20FROM=20SNMPv2-SMI=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20= [RFC2578]=0D=0A=0D=0A.in=206=0D=0ATEXTUAL-CONVENTION=0D=0A=20=20=20FROM=20= SNMPv2-TC=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC2579]=0D= =0A=0D=0AmplsStdMIB=0D=0A=20=20=20FROM=20MPLS-TC-STD-MIB=20=20=20=20=20=20= =20=20=20=20--=20[RFC3811]=0D=0A=0D=0A;=0D=0A=0D=0A.ti=203=0D=0A= mplsTcExtStdMIB=20MODULE-IDENTITY=0D=0A=0D=0ALAST-UPDATED=0D=0A=20=20=20= "201301140000Z"=20--=20January=2014,=202013=0D=0AORGANIZATION=0D=0A=20=20= =20"Multiprotocol=20Label=20Switching=20(MPLS)=20Working=20Group"=0D=0A= \%CONTACT-INFO=0D=0A=20=20=20"=0D=0A=20=20=20=20=20=20=20=20=20=20= Venkatesan=20Mahalingam=0D=0A=20=20=20=20=20=20=20=20=20=20Dell=20Inc,=0D= =0A=20=20=20=20=20=20=20=20=20=20350=20Holger=20way,=20San=20Jose,=20CA,=20= USA=0D=0A=20=20=20=20Email:=20venkat.mahalingams@gmail.com=0D=0A=0D=0A= .in=2010=0D=0A=20=20=20=20=20=20Kannan=20KV=20Sampath=0D=0A=20=20=20=20=20= =20Redeem,=0D=0A=20=20=20=20=20=20India=0D=0AEmail:=20= kannankvs@gmail.com=0D=0A=0D=0A=20=20=20=20=20=20Sam=20Aldrin=0D=0A=20=20= =20=20=20=20Huawei=20Technologies=0D=0A=20=20=20=20=20=202330=20Central=20= Express=20Way,=0D=0A=20=20=20=20=20=20Santa=20Clara,=20CA=2095051,=20USA=0D= =0AEmail:=20=20aldrin.ietf@gmail.com=0D=0A=0D=0A.in=206=0D=0A=20=20=20=20= =20=20=20=20=20=20Thomas=20D.=20Nadeau=0D=0A=20=20=20=20=20=20=20=20=20=20= Juniper=20Networks=0D=0A=20=20=20=20=20=20=20=20=20=2010=20Technology=20= Park=20Drive,=0D=0A=20=20=20=20=20=20=20=20=20=20Westford,=20MA=2001886=0D= =0A=20=20=20=20Email:=20tnadeau@juniper.net=0D=0A=20=20=20"=0D=0A= DESCRIPTION=0D=0A=20=20=20=20"Copyright=20(c)=202013=20IETF=20Trust=20= and=20the=20persons=20identified=0D=0A=20=20=20=20=20as=20the=20document=20= authors.=20=20All=20rights=20reserved.=0D=0A=0D=0A.in=2011=0D=0AThis=20= MIB=20module=20contains=20Textual=20Conventions=20for=0D=0AMPLS=20based=20= transport=20networks."=0D=0A=0D=0A.ti=206=0D=0A--=20Revision=20history.=0D= =0A=0D=0A.ti=206=0D=0AREVISION=0D=0A=0D=0A.in=206=0D=0A=20=20=20= "201301140000Z"=20--=20January=2014,=202013=0D=0ADESCRIPTION=0D=0A=20=20=20= =20=20"MPLS=20Textual=20Convention=20Extensions"=0D=0A=0D=0A::=3D=20{=20= mplsStdMIB=20xxx=20}=20--=20xxx=20to=20be=20replaced=20with=20correct=20= value=0D=0A=0D=0A.ti=203=0D=0AMplsGlobalId=20::=3D=20TEXTUAL-CONVENTION=0D= =0A=0D=0ASTATUS=20=20=20=20=20=20current=0D=0ADESCRIPTION=0D=0A=20=20=20=20= =20"This=20object=20contains=20the=20Textual=20Convention=20of=20IP=20= based=0D=0A=20=20=20=20=20=20operator=20unique=20identifier=20= (Global_ID),=20the=20Global_ID=20can=0D=0A=20=20=20=20=20=20contain=20= the=202-octet=20or=204-octet=20value=20of=20the=20operator's=0D=0A=20=20=20= =20=20=20Autonomous=20System=20Number=20(ASN).=0D=0A=0D=0A.in=2012=0D=0A= It=20is=20expected=20that=20the=20Global_ID=20will=20be=20derived=20from=0D= =0Athe=20globally=20unique=20ASN=20of=20the=20autonomous=20system=20= hosting=0D=0Athe=20PEs=20containing=20the=20actual=20AIIs.=0D=0AThe=20= presence=20of=20a=20Global_ID=20based=20on=20the=20operator's=0D=0AASN=20= ensures=20that=20the=20AII=20will=20be=20globally=20unique.=0D=0A=0D=0A= When=20the=20Global_ID=20is=20derived=20from=20a=202-octet=20AS=20= number,=0D=0A=0D=0A=0D=0A=0D=0A.in=206=0D=0A=20=20=20=20=20=20the=20two=20= high-order=20octets=20of=20this=204-octet=20identifier=0D=0A=20=20=20=20=20= =20MUST=20be=20set=20to=20zero.=0D=0A=20=20=20=20=20=20Further=20ASN=200=20= is=20reserved.=20=20A=20Global_ID=20of=20zero=20means=0D=0A=20=20=20=20=20= =20that=20no=20Global_ID=20is=20present.=20=20Note=20that=20a=20= Global_ID=20of=0D=0A=20=20=20=20=20=20zero=20is=20limited=20to=20= entities=20contained=20within=20a=20single=0D=0A=20=20=20=20=20=20= operator=20and=20MUST=20NOT=20be=20used=20across=20an=20NNI.=0D=0A=20=20=20= =20=20=20A=20non-zero=20Global_ID=20MUST=20be=20derived=20from=20an=20= ASN=20owned=20by=0D=0A=20=20=20=20=20=20the=20operator."=0D=0AREFERENCE=0D= =0A=20=20=20=20=20"MPLS=20Transport=20Profile=20(MPLS-TP)=20Identifiers,=20= [RFC6370]=20=0D=0A=20=20=20=20=20=20Section=203=20Uniquely=20Identifying=20= an=20Operator=20-=20the=20Global_ID"=0D=0ASYNTAX=20=20OCTET=20STRING=20= (SIZE=20(4))=0D=0A=0D=0A.in=203=0D=0AMplsNodeId=20::=3D=20= TEXTUAL-CONVENTION=0D=0A=20=20=20DISPLAY-HINT=20"d"=0D=0A=20=20=20STATUS=20= =20=20=20=20=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20= "The=20Node_ID=20is=20assigned=20within=20the=20scope=20of=20the=20= Global_ID.=0D=0A=20=20=20=20=20=20=20=20The=20value=200(or=200.0.0.0=20= in=20dotted=20decimal=20notation)=20is=0D=0A=20=20=20=20=20=20=20=20= reserved=20and=20MUST=20NOT=20be=20used.=0D=0A=0D=0A.in=2011=0D=0AWhen=20= IPv4=20addresses=20are=20in=20use,=20the=20value=20of=20this=20object=0D=0A= can=20be=20derived=20from=20the=20LSR's=20IPv4=20loop=20back=20address.=0D= =0AWhen=20IPv6=20addresses=20are=20in=20use,=20the=20value=20of=20this=20= object=0D=0Acan=20be=20a=2032-bit=20value=20unique=20within=20the=20= scope=20of=0D=0Aa=20Global_ID.=0D=0A=0D=0A.in=206=0D=0A=20=20=20=20=20= Note=20that,=20when=20IP=20reach=20ability=20is=20not=20needed,=20the=20= 32-bit=0D=0A=20=20=20=20=20Node_ID=20is=20not=20required=20to=20have=20= any=20association=0D=0A=20=20=20=20=20with=20the=20IPv4=20address=20= space."=0D=0AREFERENCE=0D=0A=20=20=20=20=20"MPLS=20Transport=20Profile=20= (MPLS-TP)=20Identifiers,=20[RFC6370],=20=0D=0A=20=20=20=20=20=20Section=20= 4.=20Node=20and=20Interface=20Identifiers"=0D=0ASYNTAX=20=20Unsigned32=20= =20--=20the=20default=20range:=20(0..4294967295)=0D=0A=0D=0A.in=203=0D=0A= MplsIccId=20::=3D=20TEXTUAL-CONVENTION=0D=0A=20=20=20STATUS=20=20=20=20=20= =20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"The=20= ICC=20is=20a=20string=20of=20one=20to=20six=20characters,=20each=0D=0A=20= =20=20=20=20=20=20=20=20character=20being=20either=20alphabetic=20(i.e.=20= =20A-Z)=20or=0D=0A=20=20=20=20=20=20=20=20=20numeric=20(i.e.=200-9)=20= characters.=0D=0A=20=20=20=20=20=20=20=20=20Alphabetic=20characters=20in=20= the=20ICC=20SHOULD=20be=20represented=0D=0A=20=20=20=20=20=20=20=20=20= with=20upper=20case=20letters."=0D=0AREFERENCE=0D=0A=20=20=20=20=20=20=20= =20"MPLS-TP=20Identifiers=20Following=20ITU-T=20Conventions,=20=0D=0A=20=20= =20=20=20=20=20=20=20[I-D.ietf-mpls-tp-itu-t-identifiers],=20Section=20= 3.=20=0D=0A=20=20=20=20=20=20=20=20=20Uniquely=20Identifying=20an=20= Operator=20-=20the=20ICC_Operator_ID"=0D=0ASYNTAX=20=20OCTET=20STRING=20= (SIZE=20(1..6))=0D=0A=0D=0A.in=205=0D=0A--=20MPLS-TC-EXT-STD-MIB=20= module=20ends=0D=0AEND=0D=0A=0D=0A.ti=200=0D=0A11.=20MPLS=20Identifier=20= MIB=20definitions=0D=0A=0D=0A.ti=204=0D=0AMPLS-ID-STD-MIB=20DEFINITIONS=20= ::=3D=20BEGIN=0D=0A=0D=0A.in=204=0D=0AIMPORTS=0D=0A=20MODULE-IDENTITY,=20= OBJECT-TYPE=0D=0A=20=20=20=20FROM=20SNMPv2-SMI=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= --=20[RFC2578]=0D=0A=20\%MODULE-COMPLIANCE,=20OBJECT-GROUP=0D=0A=20=20=20= =20FROM=20SNMPv2-CONF=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC2580]=0D=0A=20= mplsStdMIB=0D=0A=20=20=20=20FROM=20MPLS-TC-STD-MIB=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20= [RFC3811]=0D=0A=20MplsGlobalId,=20MplsIccId,=20MplsNodeId=0D=0A=20=20=20=20= FROM=20MPLS-TC-EXT-STD-MIB=0D=0A=20;=0D=0A=0D=0A.in=203=0D=0A= mplsIdStdMIB=20MODULE-IDENTITY=0D=0A=20=20LAST-UPDATED=0D=0A=20=20=20=20=20= "201301140000Z"=20--=20January=2014,=202013=0D=0A=20=20ORGANIZATION=0D=0A= =20=20=20=20=20"Multiprotocol=20Label=20Switching=20(MPLS)=20Working=20= Group"=0D=0A=0D=0A.in=205=0D=0ACONTACT-INFO=0D=0A=20=20=20"=0D=0A=20=20=20= =20=20=20=20=20=20=20Venkatesan=20Mahalingam=0D=0A=20=20=20=20=20=20=20=20= =20=20Dell=20Inc,=0D=0A=20=20=20=20=20=20=20=20=20=20350=20Holger=20way,=20= San=20Jose,=20CA,=20USA=0D=0AEmail:=20venkat.mahalingams@gmail.com=0D=0A=0D= =0A.ti=2015=0D=0AKannan=20KV=20Sampath=0D=0A=0D=0A.in=209=0D=0A=20=20=20=20= =20=20Redeem,=0D=0A=20=20=20=20=20=20India=0D=0AEmail:=20= kannankvs@gmail.com=0D=0A=0D=0A=0D=0A=20=20=20=20=20=20Sam=20Aldrin=0D=0A= =20=20=20=20=20=20Huawei=20Technologies=0D=0A=20=20=20=20=20=202330=20= Central=20Express=20Way,=0D=0A=20=20=20=20=20=20Santa=20Clara,=20CA=20= 95051,=20USA=0D=0AEmail:=20=20aldrin.ietf@gmail.com=0D=0A=0D=0A.in=205=0D= =0A=20=20=20=20=20=20=20=20=20=20Thomas=20D.=20Nadeau=0D=0A=20=20=20=20=20= =20=20=20=20=20Juniper=20Networks=0D=0A=20=20=20=20=20=20=20=20=20=2010=20= Technology=20Park=20Drive,=0D=0A=20=20=20=20=20=20=20=20=20=20Westford,=20= MA=2001886=0D=0A=20=20=20=20Email:=20tnadeau@juniper.net=0D=0A=20=20"=0D=0A= DESCRIPTION=0D=0A=20=20=20=20"Copyright=20(c)=202013=20IETF=20Trust=20= and=20the=20persons=20identified=0D=0A=20=20=20=20=20as=20the=20document=20= authors.=20=20All=20rights=20reserved.=0D=0A=0D=0A.in=2010=0D=0AThis=20= MIB=20module=20contains=20generic=20object=20definitions=20for=0D=0AMPLS=20= Traffic=20Engineering=20in=20transport=20networks."=0D=0A=0D=0A.ti=205=0D= =0A--=20Revision=20history.=0D=0A=0D=0A.in=205=0D=0AREVISION=0D=0A=20=20=20= =20"201301140000Z"=20--=20January=2014,=202013=0D=0ADESCRIPTION=0D=0A=20=20= =20=20=20"This=20MIB=20modules=20defines=20the=20MIB=20objects=20for=20= MPLS-TP=0D=0A=20=20=20=20=20=20identifiers"=0D=0A=0D=0A::=3D=20{=20= mplsStdMIB=20xxx=20}=20--=20xxx=20to=20be=20replaced=20with=20correct=20= value=0D=0A=0D=0A--=20Notifications=0D=0AmplsIdNotifications=20OBJECT=20= IDENTIFIER=20::=3D=20{=20mplsIdStdMIB=200=20}=0D=0A--=20tables,=20= scalars=0D=0AmplsIdObjects=20=20=20=20=20=20=20OBJECT=20IDENTIFIER=20::=3D= =20{=20mplsIdStdMIB=201=20}=0D=0A--=20conformance=0D=0AmplsIdConformance=20= =20=20OBJECT=20IDENTIFIER=20::=3D=20{=20mplsIdStdMIB=202=20}=0D=0A=0D=0A=0D= =0A--=20MPLS=20common=20objects=0D=0A=0D=0A.in=203=0D=0AmplsIdGlobalId=20= OBJECT-TYPE=0D=0A=20=20=20=20=20SYNTAX=20=20=20=20=20=20MplsGlobalId=0D=0A= =20=20=20=20=20MAX-ACCESS=20=20read-write=0D=0A=20=20=20=20=20STATUS=20=20= =20=20=20=20current=0D=0A=20=20=20=20=20DESCRIPTION=0D=0A=0D=0A.in=207=0D= =0A=20=20=20=20=20"This=20object=20allows=20the=20operator=20to=20assign=20= a=20unique=0D=0A=20=20=20=20=20=20operator=20identifier=20also=20called=20= MPLS-TP=20Global_ID."=0D=0A::=3D=20{=20mplsIdObjects=201=20}=0D=0A=0D=0A= .in=203=0D=0AmplsIdIcc=20OBJECT-TYPE=0D=0A=20=20=20=20=20SYNTAX=20=20=20=20= =20=20MplsIccId=0D=0A=20=20=20=20=20MAX-ACCESS=20=20read-write=0D=0A=20=20= =20=20=20STATUS=20=20=20=20=20=20current=0D=0A=20=20=20=20=20DESCRIPTION=0D= =0A=20=20=20=20=20=20=20=20=20"This=20object=20allows=20the=20operator=20= or=20service=20provider=20to=0D=0A=20=20=20=20=20=20=20=20=20=20assign=20= a=20unique=20MPLS-TP=20ITU-T=20Carrier=20Code=20(ICC)=20to=20a=0D=0A=20=20= =20=20=20=20=20=20=20=20network."=0D=0A=20=20=20=20::=3D=20{=20= mplsIdObjects=202=20}=0D=0A=0D=0AmplsIdNodeId=20OBJECT-TYPE=0D=0A=20=20=20= =20=20SYNTAX=20=20=20=20=20=20MplsNodeId=0D=0A=20=20=20=20=20MAX-ACCESS=20= =20read-write=0D=0A=20=20=20=20=20STATUS=20=20=20=20=20=20current=0D=0A=20= =20=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20=20"This=20object=20= allows=20the=20operator=20or=20service=20provider=20to=0D=0A=20=20=20=20=20= =20=20=20=20=20assign=20a=20unique=20MPLS-TP=20Node_ID.=0D=0A=0D=0A.in=20= 7=0D=0A=20=20=20=20=20=20The=20Node_ID=20is=20assigned=20within=20the=20= scope=20of=0D=0A=20=20=20=20=20=20the=20Global_ID."=0D=0A::=3D=20{=20= mplsIdObjects=203=20}=0D=0A=0D=0A.ti=204=0D=0A--=20Module=20compliance.=0D= =0A=0D=0A.in=203=0D=0AmplsIdGroups=0D=0A=20=20=20OBJECT=20IDENTIFIER=20= ::=3D=20{=20mplsIdConformance=201=20}=0D=0A=0D=0A=0D=0AmplsIdCompliances=0D= =0A=20=20=20OBJECT=20IDENTIFIER=20::=3D=20{=20mplsIdConformance=202=20}=0D= =0A=0D=0A--=20Compliance=20requirement=20for=20fully=20compliant=20= implementations.=0D=0A=0D=0AmplsIdModuleFullCompliance=20= MODULE-COMPLIANCE=0D=0A=20=20=20STATUS=20current=0D=0A=20=20=20= DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"Compliance=20statement=20for=20= agents=20that=20provide=20full=0D=0A=20=20=20=20=20=20=20=20=20=20= support=20the=20MPLS-ID-STD-MIB=20module."=0D=0A=0D=0A.ti=206=0D=0A= MODULE=20--=20this=20module=0D=0A=0D=0A=0D=0A.in=209=0D=0A--=20The=20= mandatory=20group=20has=20to=20be=20implemented=20by=20all=0D=0A--=20= LSRs=20that=20originate/terminate=20MPLS-TP=20paths.=0D=0A=0D=0A= MANDATORY-GROUPS=20=20=20=20{=0D=0A=20=20=20mplsIdScalarGroup=0D=0A}=0D=0A= =0D=0A.ti=2010=0D=0A::=3D=20{=20mplsIdCompliances=201=20}=0D=0A=0D=0A.ti=20= 3=0D=0A--=20Compliance=20requirement=20for=20read-only=20= implementations.=0D=0A=0D=0A.in=203=0D=0AmplsIdModuleReadOnlyCompliance=20= MODULE-COMPLIANCE=0D=0A=20=20=20STATUS=20current=0D=0A=20=20=20= DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"Compliance=20statement=20for=20= agents=20that=20provide=20full=0D=0A=20=20=20=20=20=20=20=20=20=20= support=20the=20MPLS-ID-STD-MIB=20module."=0D=0A=0D=0A.ti=206=0D=0A= MODULE=20--=20this=20module=0D=0A=0D=0A.in=209=0D=0A--=20The=20mandatory=20= group=20has=20to=20be=20implemented=20by=20all=0D=0A--=20LSRs=20that=20= originate/terminate=20MPLS-TP=20paths.=0D=0A=0D=0AMANDATORY-GROUPS=20=20=20= =20{=0D=0A=20=20=20mplsIdScalarGroup=0D=0A}=0D=0A=0D=0A.ti=208=0D=0A::=3D=20= {=20mplsIdCompliances=202=20}=0D=0A=0D=0A.ti=205=0D=0A--=20Units=20of=20= conformance.=0D=0A=0D=0A.in=204=0D=0AmplsIdScalarGroup=20OBJECT-GROUP=0D=0A= =20=20OBJECTS=20{=20mplsIdGlobalId,=0D=0A=20=20=20=20=20=20=20=20=20=20=20= =20mplsIdNodeId,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20mplsIdIcc=0D=0A= =0D=0A.in=206=0D=0A}=0D=0ASTATUS=20=20current=0D=0ADESCRIPTION=0D=0A=20=20= =20=20"Scalar=20object=20needed=20to=20implement=20MPLS=20TP=20path."=0D=0A= ::=3D=20{=20mplsIdGroups=201=20}=0D=0A=0D=0A.in=204=0D=0A--=20= MPLS-ID-STD-MIB=20module=20ends=0D=0AEND=0D=0A.bp=0D=0A.ti=200=0D=0A12.=20= MPLS=20LSR=20Extension=20MIB=20definitions=0D=0A=0D=0A.ti=203=0D=0A= MPLS-LSR-EXT-STD-MIB=20DEFINITIONS=20::=3D=20BEGIN=0D=0A=0D=0A.in=203=0D=0A= IMPORTS=0D=0A=20=20=20MODULE-IDENTITY,=20OBJECT-TYPE=0D=0A=20=20=20=20=20= =20FROM=20SNMPv2-SMI=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC2578]=0D=0A=20=20=20= \%MODULE-COMPLIANCE,=20OBJECT-GROUP=0D=0A=20=20=20=20=20=20FROM=20= SNMPv2-CONF=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20--=20[RFC2580]=0D=0A=20=20=20mplsStdMIB=0D= =0A=20=20=20=20=20=20FROM=20MPLS-TC-STD-MIB=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC3811]=0D=0A= =20=20=20RowPointer=0D=0A=20=20=20=20=20=20FROM=20SNMPv2-TC=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20--=20[RFC2579]=0D=0A=20=20=20mplsXCIndex,=20= mplsXCInSegmentIndex,=20mplsXCOutSegmentIndex,=0D=0A=20=20=20= mplsInterfaceGroup,=20mplsInSegmentGroup,=20mplsOutSegmentGroup,=20=0D=0A= =20=20=20mplsXCGroup,=20mplsPerfGroup,=20mplsLsrNotificationGroup=0D=0A=20= =20=20=20=20=20FROM=20MPLS-LSR-STD-MIB;=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC3813]=0D=0A=0D=0A= mplsLsrExtStdMIB=20MODULE-IDENTITY=0D=0A=20=20=20LAST-UPDATED=0D=0A=20=20= =20=20=20=20"201301140000Z"=20--=20January=2014,=202013=0D=0A=20=20=20= ORGANIZATION=0D=0A=20=20=20=20=20=20"Multiprotocol=20Label=20Switching=20= (MPLS)=20Working=20Group"=0D=0A=20=20=20\%CONTACT-INFO=0D=0A=20=20=20=20=20= =20"=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20Venkatesan=20Mahalingam=0D= =0A=20=20=20=20=20=20=20=20=20=20=20=20=20Dell=20Inc,=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20350=20Holger=20way,=20San=20Jose,=20CA,=20USA=0D=0A= =20=20=20=20=20=20=20Email:=20venkat.mahalingams@gmail.com=0D=0A=0D=0A= .in=2010=0D=0A=20=20=20=20=20=20Kannan=20KV=20Sampath=0D=0A=20=20=20=20=20= =20Redeem,=0D=0A=20=20=20=20=20=20India=0D=0AEmail:=20= kannankvs@gmail.com=0D=0A=0D=0A.in=2016=0D=0ASam=20Aldrin=0D=0AHuawei=20= Technologies=0D=0A2330=20Central=20Express=20Way,=0D=0ASanta=20Clara,=20= CA=2095051,=20USA=0D=0A=0D=0A.ti=2010=0D=0AEmail:=20=20= aldrin.ietf@gmail.com=0D=0A=0D=0A.in=206=0D=0A=20=20=20=20=20=20=20=20=20= Thomas=20D.=20Nadeau=0D=0A=20=20=20=20=20=20=20=20=20Juniper=20Networks=0D= =0A=20=20=20=20=20=20=20=20=2010=20Technology=20Park=20Drive,=20= Westford,=20MA=2001886=0D=0A=20=20=20Email:=20tnadeau@juniper.net=0D=0A=20= =20"=0D=0ADESCRIPTION=0D=0A=0D=0A.in=2010=0D=0A"Copyright=20(c)=202013=20= IETF=20Trust=20and=20the=20persons=20identified=0D=0A=20as=20the=20= document=20authors.=20=20All=20rights=20reserved.=0D=0A=0D=0A.ti=2011=0D=0A= This=20MIB=20module=20contains=20generic=20object=20definitions=20for=0D=0A= =0D=0A=0D=0A.ti=2011=0D=0AMPLS=20LSR=20in=20transport=20networks."=0D=0A=0D= =0A=0D=0A.ti=206=0D=0A--=20Revision=20history.=0D=0A=0D=0A.in=206=0D=0A= REVISION=0D=0A=20=20"201301140000Z"=20--=20January=2014,=202013=0D=0A= DESCRIPTION=0D=0A=20=20=20=20=20"MPLS=20LSR=20specific=20MIB=20objects=20= extension"=0D=0A=0D=0A::=3D=20{=20mplsStdMIB=20xxx=20}=20--=20xxx=20to=20= be=20replaced=20with=20correct=20value=0D=0A=0D=0A.in=203=0D=0A--=20= Notifications=0D=0AmplsLsrExtNotifications=20OBJECT=20IDENTIFIER=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ::=3D=20{=20mplsLsrExtStdMIB=200=20}=0D=0A--=20tables,=20scalars=0D=0A= mplsLsrExtObjects=20=20=20=20=20=20=20OBJECT=20IDENTIFIER=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20::=3D=20{=20= mplsLsrExtStdMIB=201=20}=0D=0A--=20conformance=0D=0A= mplsLsrExtConformance=20=20=20OBJECT=20IDENTIFIER=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20::=3D=20{=20= mplsLsrExtStdMIB=202=20}=0D=0A=0D=0A--=20MPLS=20LSR=20common=20objects=0D= =0AmplsXCExtTable=20=20OBJECT-TYPE=0D=0A=20=20=20=20SYNTAX=20=20=20=20=20= =20=20=20SEQUENCE=20OF=20MplsXCExtEntry=0D=0A=20=20=20=20MAX-ACCESS=20=20= =20=20not-accessible=0D=0A=20=20=20=20STATUS=20=20=20=20=20=20=20=20= current=0D=0A=20=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20"This=20= table=20sparse=20augments=20the=20mplsXCTable=20of=0D=0A=20=20=20=20=20=20= =20=20\%MPLS-LSR-STD-MIB=20[RFC3813]=20to=20provide=20MPLS-TP=20specific=0D= =0A=20=20=20=20=20=20=20=20information=20about=20associated=20tunnel=20= information"=0D=0A=20=20=20=20REFERENCE=0D=0A=20=20=20=20=20=20=20"1.=20= Multiprotocol=20Label=20Switching=20(MPLS)=20Label=20Switching=0D=0A=20=20= =20=20=20=20=20=20Router=20(LSR)=20Management=20Information=20Base=20= (MIB),=20RFC=203813,=0D=0A=20=20=20=20=20=20=20=20Section=205.7.=20= mplsXCTable"=0D=0A::=3D=20{=20mplsLsrExtObjects=201=20}=0D=0A=0D=0A= mplsXCExtEntry=20=20OBJECT-TYPE=0D=0A=20=20=20=20SYNTAX=20=20=20=20=20=20= =20=20MplsXCExtEntry=0D=0A=20=20=20=20MAX-ACCESS=20=20=20=20= not-accessible=0D=0A=0D=0A.in=207=0D=0ASTATUS=20=20=20=20=20=20=20=20= current=0D=0ADESCRIPTION=0D=0A=0D=0A=20=20=20"An=20entry=20in=20this=20= table=20extends=20the=20cross=20connect=0D=0A=20=20=20=20information=20= represented=20by=20an=20entry=20in=0D=0A=20=20=20=20the=20mplsXCTable=20= in=20MPLS-LSR-STD-MIB=20[RFC3813]=20through=0D=0A=20=20=20=20a=20sparse=20= augmentation.=20=20An=20entry=20can=20be=20created=20by=0D=0A=20=20=20=20= a=20network=20operator=20via=20SNMP=20SET=20commands,=20or=20in=0D=0A=20=20= =20=20response=20to=20signaling=20protocol=20events."=0D=0AREFERENCE=0D=0A= =20=20=20"1.=20Multiprotocol=20Label=20Switching=20(MPLS)=20Label=20= Switching=0D=0A=20=20=20=20Router=20(LSR)=20Management=20Information=20= Base=20(MIB),=20RFC=203813,=0D=0A=20=20=20=20Section=2010.=20= mplsXCTable"=0D=0A=0D=0A=0D=0A.in=204=0D=0A=20INDEX=20{=20mplsXCIndex,=20= mplsXCInSegmentIndex,=0D=0A=20=20=20=20=20=20=20mplsXCOutSegmentIndex=20= }=0D=0A::=3D=20{=20mplsXCExtTable=201=20}=0D=0A=0D=0A.in=203=0D=0A= MplsXCExtEntry=20::=3D=20SEQUENCE=20{=0D=0A=20=20=20= mplsXCExtTunnelPointer=20=20=20=20=20=20=20=20RowPointer,=0D=0A=20=20=20= mplsXCExtOppositeDirXCPtr=20=20=20=20=20RowPointer=0D=0A}=0D=0A=0D=0A= mplsXCExtTunnelPointer=20OBJECT-TYPE=0D=0A=20=20=20=20SYNTAX=20=20=20=20=20= =20=20=20RowPointer=0D=0A=20=20=20=20MAX-ACCESS=20=20=20=20read-only=0D=0A= =20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20=20=20= DESCRIPTION=0D=0A=20=20=20=20=20=20=20"This=20read-only=20object=20= indicates=20the=20back=20pointer=20to=0D=0A=20=20=20=20=20=20=20=20the=20= tunnel=20entry=20segment."=0D=0A=20=20=20=20REFERENCE=0D=0A=20=20=20=20=20= =20=20"1.=20Multiprotocol=20Label=20Switching=20(MPLS)=20Label=20= Switching=0D=0A=20=20=20=20=20=20=20=20Router=20(LSR)=20Management=20= Information=20Base=20(MIB),=20RFC=203813,=0D=0A=20=20=20=20=20=20=20=20= Section=2010.=20mplsXCTable"=0D=0A=20::=3D=20{=20mplsXCExtEntry=201=20}=0D= =0A=0D=0AmplsXCExtOppositeDirXCPtr=20OBJECT-TYPE=0D=0A=20=20=20=20SYNTAX=20= =20=20=20=20=20=20=20RowPointer=0D=0A=20=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20= =20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20"This=20object=20= indicates=20the=20pointer=20to=20the=20opposite=0D=0A=20=20=20=20=20=20=20= =20direction=20XC=20entry.=20=20This=20object=20cannot=20be=20modified=20= if=0D=0A=20=20=20=20=20=20=20=20mplsXCRowStatus=20for=20the=20= corresponding=20entry=20in=20the=0D=0A=20=20=20=20=20=20=20=20= mplsXCTable=20is=20active(1)."=0D=0A=20=20=20=20REFERENCE=0D=0A=20=20=20=20= =20=20=20"1.=20Multiprotocol=20Label=20Switching=20(MPLS)=20Label=20= Switching=0D=0A=20=20=20=20=20=20=20=20Router=20(LSR)=20Management=20= Information=20Base=20(MIB),=20RFC=203813,=0D=0A=20=20=20=20=20=20=20=20= Section=2010.=20mplsXCTable"=0D=0A=20::=3D=20{=20mplsXCExtEntry=202=20}=0D= =0A=0D=0A.in=204=0D=0AmplsLsrExtGroups=0D=0A=20=20=20OBJECT=20IDENTIFIER=20= ::=3D=20{=20mplsLsrExtConformance=201=20}=0D=0A=0D=0A= mplsLsrExtCompliances=0D=0A=20=20=20OBJECT=20IDENTIFIER=20::=3D=20{=20= mplsLsrExtConformance=202=20}=0D=0A=0D=0A--=20Compliance=20requirement=20= for=20fully=20compliant=20implementations.=0D=0A=0D=0A= mplsLsrExtModuleFullCompliance=20MODULE-COMPLIANCE=0D=0A=20=20=20=20= STATUS=20current=0D=0A=20=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20= "Compliance=20statement=20for=20agents=20that=20provide=20full=20support=0D= =0A=20=20=20=20=20=20=20=20for=20MPLS-LSR-EXT-STD-MIB.=0D=0A=20=20=20=20=20= =20=20=20The=20mandatory=20group=20has=20to=20be=20implemented=20by=20= all=20LSRs=0D=0A=20=20=20=20=20=20=20=20that=20originate,=20terminate,=20= or=20act=20as=20transit=20for=0D=0A=20=20=20=20=20=20=20=20= \%TE-LSPs/tunnels.=0D=0A=20=20=20=20=20=20=20=20In=20addition,=20= depending=20on=20the=20type=20of=20tunnels=20supported,=0D=0A=20=20=20=20= =20=20=20=20other=20groups=20become=20mandatory=20as=20explained=20= below."=0D=0A=0D=0A.ti=205=0D=0AMODULE=20MPLS-LSR-STD-MIB=20--=20The=20= MPLS-LSR-STD-MIB,=20RFC3813=0D=0A=0D=0A.in=205=0D=0AMANDATORY-GROUPS=20{=0D= =0A=20=20mplsInSegmentGroup,=0D=0A=20=20mplsOutSegmentGroup,=0D=0A=20=20= mplsXCGroup,=0D=0A=20=20mplsPerfGroup,=0D=0A=20=20= mplsLsrNotificationGroup=0D=0A}=0D=0A=0D=0AMODULE=20--=20this=20module=0D= =0A.sp4=0D=0AMANDATORY-GROUPS=20=20=20=20{=0D=0A=20=20mplsXCExtGroup=0D=0A= }=0D=0A=0D=0A::=3D=20{=20mplsLsrExtCompliances=201=20}=0D=0A=0D=0A.in=20= 4=0D=0A--=20Compliance=20requirement=20for=20implementations=20that=20= provide=0D=0A--=20read-only=20access.=0D=0A=0D=0A.in=205=0D=0A= mplsLsrExtModuleReadOnlyCompliance=20MODULE-COMPLIANCE=0D=0A=20=20STATUS=20= current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20=20"Compliance=20= requirement=20for=20implementations=20that=20only=0D=0A=20=20=20=20=20=20= provide=20read-only=20support=20for=20MPLS-LSR-EXT-STD-MIB.=0D=0A=20=20=20= =20=20=20Such=20devices=20can=20then=20be=20monitored=20but=20cannot=20= be=0D=0A=20=20=20=20=20=20configured=20using=20this=20MIB=20module."=0D=0A= =0D=0A=0D=0AMODULE=20MPLS-LSR-STD-MIB=0D=0A=0D=0AMANDATORY-GROUPS=20{=0D=0A= =20=20=20=20mplsInterfaceGroup,=0D=0A=20=20=20=20mplsInSegmentGroup,=0D=0A= =20=20=20=20mplsOutSegmentGroup,=0D=0A=20=20=20=20mplsXCGroup,=0D=0A=20=20= =20=20mplsPerfGroup=0D=0A}=0D=0A=0D=0AMODULE=20--=20this=20module=0D=0A=0D= =0AMANDATORY-GROUPS=20{=0D=0A=20=20=20mplsXCExtGroup=0D=0A}=0D=0A=0D=0A= OBJECT=20=20=20=20=20=20mplsXCExtTunnelPointer=0D=0ASYNTAX=20=20=20=20=20= =20RowPointer=0D=0AMIN-ACCESS=20=20read-only=0D=0ADESCRIPTION=0D=0A=20=20= =20"The=20only=20valid=20value=20for=20Tunnel=20Pointer=20is=20=0D=0A=20=20= =20=20mplsTunnelTable=20entry."=0D=0A=0D=0AOBJECT=20=20=20=20=20=20= mplsXCExtOppositeDirXCPtr=0D=0ASYNTAX=20=20=20=20=20=20RowPointer=0D=0A= MIN-ACCESS=20=20read-only=0D=0ADESCRIPTION=0D=0A=20=20=20"The=20only=20= valid=20value=20for=20XC=20Pointer=20is=20=0D=0A=20=20=20=20mplsXCTable=20= entry."=0D=0A=0D=0A::=3D=20{=20mplsLsrExtCompliances=202=20}=0D=0A=0D=0A= mplsXCExtGroup=20=20OBJECT-GROUP=0D=0AOBJECTS=20{=0D=0A=20=20=20=20= mplsXCExtTunnelPointer,=0D=0A=20=20=20=20mplsXCExtOppositeDirXCPtr=0D=0A= }=0D=0ASTATUS=20=20current=0D=0ADESCRIPTION=0D=0A=20=20=20=20"This=20= object=20should=20be=20supported=20in=20order=20to=20access=0D=0A=20=20=20= =20the=20tunnel=20entry=20from=20XC=20entry."=0D=0A::=3D=20{=20= mplsLsrExtGroups=201=20}=0D=0A=0D=0A.in=204=0D=0A--=20= MPLS-LSR-EXT-STD-MIB=20module=20ends=0D=0AEND=0D=0A=0D=0A=0D=0A.ti=200=0D= =0A13.=20MPLS=20Tunnel=20Extension=20MIB=20definitions=0D=0A=0D=0A.ti=20= 5=0D=0AMPLS-TE-EXT-STD-MIB=20DEFINITIONS=20::=3D=20BEGIN=0D=0A=0D=0A.in=20= 5=0D=0AIMPORTS=0D=0A=20=20=20MODULE-IDENTITY,=20OBJECT-TYPE,=20= Counter32,=0D=0A=20=20=20=20=20=20Counter64,=20zeroDotZero=0D=0A=0D=0A= .in=208=0D=0A=20=20=20FROM=20SNMPv2-SMI=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC2578]=0D= =0A\%MODULE-COMPLIANCE,=20OBJECT-GROUP=0D=0A=20=20=20FROM=20SNMPv2-CONF=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20--=20[RFC2580]=0D=0ATruthValue,=20RowStatus,=20RowPointer,=20= StorageType=0D=0A=20=20=20FROM=20SNMPv2-TC=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20= [RFC2579]=0D=0AMplsGlobalId,=20MplsNodeId,=20MplsIccId=0D=0A=20=20=20= FROM=20MPLS-TC-EXT-STD-MIB=0D=0AmplsStdMIB,=20MplsTunnelIndex,=20= MplsTunnelInstanceIndex,=0D=0AMplsExtendedTunnelId=0D=0A=20=20=20FROM=20= MPLS-TC-STD-MIB=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20--=20[RFC3811]=0D=0AmplsTunnelIndex,=20= mplsTunnelInstance,=20mplsTunnelIngressLSRId,=0D=0AmplsTunnelEgressLSRId=0D= =0A=20=20=20FROM=20MPLS-TE-STD-MIB=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20--=20[RFC3812]=0D=0A;=0D=0A=0D=0A= .in=205=0D=0AmplsTeExtStdMIB=20MODULE-IDENTITY=0D=0A=20=20=20= LAST-UPDATED=0D=0A=20=20=20=20=20=20=20"201301140000Z"=20--=20January=20= 14,=202013=0D=0A=20=20=20ORGANIZATION=0D=0A=20=20=20=20=20=20= "Multiprotocol=20Label=20Switching=20(MPLS)=20Working=20Group"=0D=0A=20=20= =20\%CONTACT-INFO=0D=0A=20=20=20=20=20=20"=0D=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20Venkatesan=20Mahalingam=0D=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20Dell=20Inc,=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20350=20= Holger=20way,=20San=20Jose,=20CA,=20USA=0D=0A=20=20=20=20=20=20=20Email:=20= venkat.mahalingams@gmail.com=0D=0A=0D=0A.in=2012=0D=0A=20=20=20=20=20=20= Kannan=20KV=20Sampath=0D=0A=20=20=20=20=20=20Redeem,=0D=0A=20=20=20=20=20= =20India=0D=0AEmail:=20kannankvs@gmail.com=0D=0A=0D=0A=20=20=20=20=20=20= Sam=20Aldrin=0D=0A=20=20=20=20=20=20Huawei=20Technologies=0D=0A=20=20=20=20= =20=202330=20Central=20Express=20Way,=0D=0A=20=20=20=20=20=20Santa=20= Clara,=20CA=2095051,=20USA=0D=0AEmail:=20=20aldrin.ietf@gmail.com=0D=0A=0D= =0A.in=208=0D=0A=20=20=20=20=20=20=20Thomas=20D.=20Nadeau=0D=0A=20=20=20=20= =20=20=20Juniper=20Networks=0D=0A=20=20=20=20=20=20=2010=20Technology=20= Park=20Drive,=20Westford,=20MA=2001886=0D=0A=20Email:=20= tnadeau@juniper.net=0D=0A=20=20"=0D=0ADESCRIPTION=0D=0A=20=20=20=20= "Copyright=20(c)=202013=20IETF=20Trust=20and=20the=20persons=20= identified=0D=0A=20=20=20=20=20as=20the=20document=20authors.=20=20All=20= rights=20reserved.=0D=0A=0D=0A.fi=0D=0A.in=2013=0D=0AThis=20MIB=20module=20= contains=20generic=20object=20definitions=20for=20MPLS=20Traffic=20= Engineering=20in=20transport=20networks."=0D=0A=0D=0A=0D=0A.ti=208=0D=0A= --=20Revision=20history.=0D=0A=0D=0A.nf=0D=0A.in=208=0D=0AREVISION=0D=0A=20= =20=20"201301140000Z"=20--=20January=2014,=202013=0D=0A=0D=0ADESCRIPTION=0D= =0A=20=20=20=20=20"MPLS=20TE=20MIB=20objects=20extension"=0D=0A=0D=0A::=3D= =20{=20mplsStdMIB=20xxx=20}=20--=20xxx=20to=20be=20replaced=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20--=20with=20= correct=20value=0D=0A=0D=0A.ti=205=0D=0A--=20Top=20level=20components=20= of=20this=20MIB=20module.=0D=0A=0D=0A.in=205=0D=0A--=20Notifications=0D=0A= mplsTeExtNotifications=20OBJECT=20IDENTIFIER=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ::=3D=20{=20mplsTeExtStdMIB=200=20}=0D=0A--=20tables,=20scalars=0D=0A= mplsTeExtObjects=20=20=20=20=20=20=20OBJECT=20IDENTIFIER=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20::=3D=20{=20mplsTeExtStdMIB=201=20}=0D=0A--=20conformance=0D=0A= mplsTeExtConformance=20=20=20OBJECT=20IDENTIFIER=0D=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20::=3D=20{=20mplsTeExtStdMIB=202=20}=0D=0A=0D=0A.in=204=0D=0A--=20= Start=20of=20MPLS=20Transport=20Profile=20Node=20configuration=20table=0D= =0A=20=20mplsTunnelExtNodeConfigTable=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20= =20=20=20=20=20=20=20SEQUENCE=20OF=20MplsTunnelExtNodeConfigEntry=0D=0A=20= =20=20\%MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20=20=20STATUS=20=20=20= =20=20=20=20=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20= =20=20"This=20table=20allows=20the=20operator=20to=20map=20a=20node=20or=0D= =0A=20=20=20=20=20=20=20=20=20=20LSR=20Identifier=20(IP=20compatible=20= [Global_Node_ID]=20or=20ICC)=0D=0A=20=20=20=20=20=20=20=20=20=20with=20a=20= local=20identifier.=0D=0A=0D=0A=0D=0A.in=2014=0D=0AThis=20table=20is=20= created=20to=20reuse=20the=20existing=0D=0AmplsTunnelTable=20for=20MPLS=20= based=20transport=20network=0D=0Atunnels=20also.=0D=0ASince=20the=20MPLS=20= tunnel's=20Ingress/Egress=20LSR=20identifiers'=0D=0Asize=20(Unsigned32)=20= value=20is=20not=20compatible=20for=0D=0AMPLS-TP=20tunnel=20i.e.=20= Global_Node_Id=20of=20size=208=20bytes=20and=0D=0AICC=20of=20size=206=20= bytes,=20there=20exists=20a=20need=20to=20map=20the=0D=0AGlobal_Node_ID=20= or=20ICC=20with=20the=20local=20identifier=20of=20size=0D=0A4=20bytes=20= (Unsigned32)=20value=20in=20order=0D=0Ato=20index=20(Ingress/Egress=20= LSR=20identifier)=0D=0Athe=20existing=20mplsTunnelTable."=0D=0A=0D=0A.ti=20= 7=0D=0A::=3D=20{=20mplsTeExtObjects=201=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtNodeConfigEntry=20OBJECT-TYPE=0D=0A=20SYNTAX=20=20=20=20=20=20= =20=20MplsTunnelExtNodeConfigEntry=0D=0A=20MAX-ACCESS=20=20=20=20= not-accessible=0D=0A=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20= DESCRIPTION=0D=0A=0D=0A=0D=0A.in=2014=0D=0A"An=20entry=20in=20this=20= table=20represents=20a=20mapping=0D=0Aidentification=20for=20the=20= operator=20or=20service=20provider=0D=0Awith=20node=20or=20LSR.=0D=0A=0D=0A= As=20per=20[RFC6370],=20this=20mapping=20is=0D=0A=0D=0Arepresented=20as=20= Global_Node_ID=20or=20ICC.=0D=0A=0D=0A.in=208=0D=0A=20=20=20=20=20=20= Note:=20Each=20entry=20in=20this=20table=20should=20have=20a=20unique=0D=0A= =20=20=20=20=20=20Global_ID=20and=20Node_ID=20combination."=0D=0AINDEX=20= {=20mplsTunnelExtNodeConfigLocalId=20}=0D=0A::=3D=20{=20= mplsTunnelExtNodeConfigTable=201=20}=0D=0A=0D=0A.fi=0D=0A.in=2012=0D=0A= .ti=206=0D=0AMplsTunnelExtNodeConfigEntry=20::=3D=20SEQUENCE=20{=20= mplsTunnelExtNodeConfigLocalId=20=20=20=20=20MplsExtendedTunnelId,=20= mplsTunnelExtNodeConfigGlobalId=20=20=20=20MplsGlobalId,=20= mplsTunnelExtNodeConfigNodeId=20=20=20=20=20=20MplsNodeId,=20= mplsTunnelExtNodeConfigIccId=20=20=20=20=20=20=20MplsIccId,=20= mplsTunnelExtNodeConfigRowStatus=20=20=20RowStatus,=20= mplsTunnelExtNodeConfigStorageType=20StorageType=0D=0A=0D=0A.ti=206=0D=0A= }=0D=0A=0D=0A.nf=0D=0A.in=206=0D=0AmplsTunnelExtNodeConfigLocalId=20=20= OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20=20=20=20=20=20= MplsExtendedTunnelId=0D=0A=20=20=20MAX-ACCESS=20=20=20=20not-accessible=0D= =0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20=20= DESCRIPTION=0D=0A=20=20=20=20=20"This=20object=20is=20used=20in=20= accommodating=20the=20bigger=0D=0A=20=20=20=20=20=20size=20= Global_Node_ID=20and/or=20ICC=20with=20lower=20size=20LSR=0D=0A=20=20=20=20= =20=20identifier=20in=20order=20to=20index=20the=20mplsTunnelTable.=0D=0A= =0D=0A.in=2012=0D=0AThe=20Local=20Identifier=20is=20configured=20between=20= 0=20and=2016777215,=0D=0Aas=20valid=20IP=20address=20range=20starts=20= from=2016777216(01.00.00.00).=0D=0AThis=20range=20is=20chosen=20to=20= identify=20the=20mplsTunnelTable's=0D=0AIngress/Egress=20LSR-id=20is=20= IP=20address=20or=20Local=20identifier,=0D=0Aif=20the=20configured=20= range=20is=20not=20IP=20address,=20operator=20is=0D=0Aexpected=20to=20= retrieve=20the=20complete=20information=0D=0A(Global_Node_ID=20or=20ICC)=20= from=20mplsTunnelExtNodeConfigTable.=0D=0AThis=20way,=20existing=20= mplsTunnelTable=20is=20reused=20for=0D=0Abidirectional=20tunnel=20= extensions=20for=20MPLS=20based=20transport=0D=0Anetworks.=0D=0A=0D=0A= .in=209=0D=0A=20=20=20This=20Local=20Identifier=20allows=20the=20= operator=20to=20assign=0D=0A=20=20=20a=20unique=20identifier=20to=20map=20= Global_Node_ID=20and/or=20ICC.=0D=0A=20=20=20As=20this=20Local=20= Identifier=20is=20unique=20within=20the=20node=20and=0D=0A=20=20=20the=20= same=20syntax=20of=20this=20object=20can=20be=20used=20for=20MPLS=20TE=0D= =0A=20=20=20tunnel=20also,=20it=20is=20up=20to=20the=20operator/local=20= management=0D=0A=20=20=20entity=20to=20choose=20the=20non-conflicting=20= value=20for=20indexing=20=0D=0A=20=20=20the=20MPLS=20and=20MPLS-TP=20= tunnel=20entries."=0D=0A::=3D=20{=20mplsTunnelExtNodeConfigEntry=201=20}=0D= =0A=0D=0A=0D=0A.in=206=0D=0AmplsTunnelExtNodeConfigGlobalId=20=20= OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20=20=20=20=20=20MplsGlobalId=0D=0A= =20=20=20MAX-ACCESS=20=20=20=20read-create=0D=0A=20=20=20STATUS=20=20=20=20= =20=20=20=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20"This=20= object=20indicates=20the=20Global=20Operator=20Identifier.=0D=0A=20=20=20= =20=20=20This=20object=20value=20should=20be=20zero=20when=0D=0A=20=20=20= =20=20=20mplsTunnelExtNodeConfigIccId=20is=20configured=20with=20= non-null=0D=0A=20=20=20=20=20=20value."=0D=0A=20=20=20REFERENCE=0D=0A=20=20= =20=20=20=20=20=20=20"MPLS=20Transport=20Profile=20(MPLS-TP)=20= Identifiers=20[RFC6370]=0D=0A=20=20=20=20=20=20=20=20=20=20Section=203.=20= Uniquely=20Identifying=20an=20Operator=20-=0D=0A=20=20=20=20=20=20=20=20=20= =20the=20Global_ID"=0D=0A=20=20=20::=3D=20{=20= mplsTunnelExtNodeConfigEntry=202=20}=0D=0A=0D=0A= mplsTunnelExtNodeConfigNodeId=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20= =20=20=20=20=20=20MplsNodeId=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"This=20object=20indicates=20the=20= Node_ID=20within=20the=20operator.=0D=0A=20=20=20=20=20=20This=20object=20= value=20should=20be=20zero=20when=0D=0A=20=20=20=20=20=20= mplsTunnelExtNodeConfigIccId=20is=20configured=20with=20non-null=0D=0A=20= =20=20=20=20=20value."=0D=0A=20=20=20REFERENCE=0D=0A=20=20=20=20=20=20=20= "MPLS=20Transport=20Profile=20(MPLS-TP)=20Identifiers=20[RFC6370]=0D=0A=20= =20=20=20=20=20=20=20Section=204,=20Node=20and=20Interface=20= Identifiers"=0D=0A=20=20=20::=3D=20{=20mplsTunnelExtNodeConfigEntry=203=20= }=0D=0A=0D=0AmplsTunnelExtNodeConfigIccId=20OBJECT-TYPE=0D=0A=20=20=20=20= =20SYNTAX=20=20=20=20=20=20MplsIccId=0D=0A=20=20=20=20=20MAX-ACCESS=20=20= read-create=0D=0A=20=20=20=20=20STATUS=20=20=20=20=20=20current=0D=0A=20=20= =20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"This=20object=20= allows=20the=20operator=20or=20service=20provider=20to=0D=0A=20=20=20=20=20= =20=20=20=20configure=20a=20unique=20MPLS-TP=20ITU-T=20Carrier=20Code=20= (ICC)=0D=0A=20=20=20=20=20=20=20=20=20either=20for=20Ingress=20ID=20or=20= Egress=20ID.=0D=0A=0D=0A.in=209=0D=0A=20=20=20=20=20=20This=20object=20= value=20should=20be=20zero=20when=0D=0A=20=20=20=20=20=20= mplsTunnelExtNodeConfigGlobalId=20and=0D=0A=20=20=20=20=20=20= mplsTunnelExtNodeConfigNodeId=20are=20assigned=20with=20non-zero=0D=0A=20= =20=20=20=20=20value."=0D=0A=20=20=20=20=20REFERENCE=0D=0A=20=20=20=20=20= =20=20=20"MPLS-TP=20Identifiers=20Following=20ITU-T=20Conventions,=20=0D=0A= =20=20=20=20=20=20=20=20=20[I-D.ietf-mpls-tp-itu-t-identifiers],=20= August=202012,=0D=0A=20=20=20=20=20=20=20=20=20Section=203.=20Uniquely=20= Identifying=20an=20Operator=20-=20the=0D=0A=20=20=20=20=20=20=20=20=20= ICC_Operator_ID"=0D=0A::=3D=20{=20mplsTunnelExtNodeConfigEntry=204=20}=0D= =0A=0D=0A.in=206=0D=0AmplsTunnelExtNodeConfigRowStatus=20OBJECT-TYPE=0D=0A= =20=20=20SYNTAX=20=20=20=20=20=20=20=20RowStatus=0D=0A=20=20=20= MAX-ACCESS=20=20=20=20read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20= =20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20"This=20= object=20allows=20the=20operator=20to=20create,=20modify,=0D=0A=20=20=20=20= =20=20=20and/or=20delete=20a=20row=20in=20this=20table."=0D=0A=20=20=20= ::=3D=20{=20mplsTunnelExtNodeConfigEntry=205=20}=0D=0A=0D=0A=0D=0A= mplsTunnelExtNodeConfigStorageType=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20= =20=20=20=20=20=20StorageType=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20"This=20variable=20indicates=20the=20= storage=20type=20for=20this=0D=0A=20=20=20=20=20object.=0D=0A=20=20=20=20= =20Conceptual=20rows=20having=20the=20value=20'permanent'=0D=0A=20=20=20=20= =20need=20not=20allow=20write-access=20to=20any=20columnar=0D=0A=20=20=20= =20=20objects=20in=20the=20row."=0D=0A=20=20=20DEFVAL=20{=20volatile=20}=0D= =0A=20=20=20::=3D=20{=20mplsTunnelExtNodeConfigEntry=206=20}=0D=0A=0D=0A=0D= =0A.ti=205=0D=0A--=20End=20of=20MPLS=20Transport=20Profile=20Node=20= configuration=20table=0D=0A=0D=0A.in=205=0D=0A--=20Start=20of=20MPLS=20= Transport=20Profile=20Node=20IP=20compatible=0D=0A--=20mapping=20table=0D= =0A=0D=0A.in=204=0D=0AmplsTunnelExtNodeIpMapTable=20OBJECT-TYPE=0D=0A=20=20= =20SYNTAX=20=20=20=20=20=20=20=20SEQUENCE=20OF=20= MplsTunnelExtNodeIpMapEntry=0D=0A=0D=0A.in=207=0D=0AMAX-ACCESS=20=20=20=20= not-accessible=0D=0ASTATUS=20=20=20=20=20=20=20=20current=0D=0A= DESCRIPTION=0D=0A=20=20=20=20"This=20read-only=20table=20allows=20the=20= operator=20to=20retrieve=0D=0A=20=20=20=20=20the=20local=20identifier=20= for=20a=20given=20Global_Node_ID=20in=20an=20IP=0D=0A=20=20=20=20=20= compatible=20operator=20environment.=0D=0A=0D=0A.ti=2012=0D=0AThis=20= table=20MAY=20be=20used=20in=20on-demand=20and/or=20proactive=0D=0A=0D=0A= .in=2012=0D=0AOAM=20operations=20to=20get=20the=20Ingress/Egress=20LSR=20= identifier=0D=0A(Local=20Identifier)=20from=20Src-Global_Node_ID=0D=0Aor=20= Dst-Global_Node_ID=20and=20the=20Ingress=20and=20Egress=20LSR=0D=0A= identifiers=20are=20used=20to=20retrieve=20the=20tunnel=20entry.=0D=0A=0D= =0A.in=207=0D=0A=20=20=20=20=20This=20table=20returns=20nothing=20when=20= the=20associated=20entry=0D=0A=20=20=20=20=20is=20not=20defined=20in=20= mplsTunnelExtNodeConfigTable."=0D=0A::=3D=20{=20mplsTeExtObjects=202=20}=0D= =0A=0D=0A.in=206=0D=0AmplsTunnelExtNodeIpMapEntry=20OBJECT-TYPE=0D=0A=20= SYNTAX=20=20=20=20=20=20=20=20MplsTunnelExtNodeIpMapEntry=0D=0A=20= MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20STATUS=20=20=20=20=20=20=20=20= current=0D=0A=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20"An=20entry=20in=20= this=20table=20represents=20a=20mapping=20of=0D=0A=20=20=20=20=20=20=20=20= Global_Node_ID=20with=20the=20local=20identifier.=0D=0A=0D=0A.in=2014=0D=0A= An=20entry=20in=20this=20table=20is=20created=20automatically=20when=0D=0A= the=20Local=20identifier=20is=20associated=20with=20Global_ID=20and=0D=0A= Node_Id=20in=20the=20mplsTunnelExtNodeConfigTable.=0D=0A=0D=0A.in=208=0D=0A= =20=20=20=20=20=20Note:=20Each=20entry=20in=20this=20table=20should=20= have=20a=20unique=0D=0A=20=20=20=20=20=20Global_ID=20and=20Node_ID=20= combination."=0D=0AINDEX=20{=20mplsTunnelExtNodeIpMapGlobalId,=0D=0A=20=20= =20=20=20=20=20=20mplsTunnelExtNodeIpMapNodeId=0D=0A=20=20=20=20=20=20}=0D= =0A::=3D=20{=20mplsTunnelExtNodeIpMapTable=201=20}=0D=0A=0D=0A.in=206=0D=0A= MplsTunnelExtNodeIpMapEntry=20::=3D=20SEQUENCE=20{=0D=0A=20=20=20=20=20=20= mplsTunnelExtNodeIpMapGlobalId=20=20=20=20MplsGlobalId,=0D=0A=20=20=20=20= =20=20mplsTunnelExtNodeIpMapNodeId=20=20=20=20=20=20MplsNodeId,=0D=0A=20=20= =20=20=20=20mplsTunnelExtNodeIpMapLocalId=20=20=20=20=20= MplsExtendedTunnelId=0D=0A}=0D=0A=0D=0AmplsTunnelExtNodeIpMapGlobalId=20=20= OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20=20=20=20=20=20MplsGlobalId=0D=0A= =20=20=20MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20=20=20STATUS=20=20=20= =20=20=20=20=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20= "This=20object=20indicates=20the=20Global_ID."=0D=0A=20=20=20::=3D=20{=20= mplsTunnelExtNodeIpMapEntry=201=20}=0D=0A=0D=0A= mplsTunnelExtNodeIpMapNodeId=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20= =20=20=20=20=20MplsNodeId=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= not-accessible=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20= =20=20DESCRIPTION=0D=0A=20=20=20=20=20"This=20object=20indicates=20the=20= Node_ID=20within=20the=0D=0A=0D=0A.in=209=0D=0A=20=20=20operator."=0D=0A= ::=3D=20{=20mplsTunnelExtNodeIpMapEntry=202=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtNodeIpMapLocalId=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20= =20=20=20=20=20=20MplsExtendedTunnelId=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-only=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20"This=20object=20contains=20an=20IP=20= compatible=20local=20identifier=0D=0A=20=20=20=20=20=20which=20is=20= defined=20in=20mplsTunnelExtNodeConfigTable."=0D=0A=20=20=20::=3D=20{=20= mplsTunnelExtNodeIpMapEntry=203=20}=0D=0A=0D=0A--=20End=20MPLS=20= Transport=20Profile=20Node=20IP=20compatible=20table=0D=0A=0D=0A--=20= Start=20of=20MPLS=20Transport=20Profile=20Node=20ICC=20based=20table=0D=0A= =0D=0AmplsTunnelExtNodeIccMapTable=20OBJECT-TYPE=0D=0A=20SYNTAX=20=20=20=20= =20=20=20=20SEQUENCE=20OF=20MplsTunnelExtNodeIccMapEntry=0D=0A=20= \%MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20STATUS=20=20=20=20=20=20=20= =20current=0D=0A=20DESCRIPTION=0D=0A=20=20=20=20"This=20read-only=20= table=20allows=20the=20operator=20to=20retrieve=0D=0A=20=20=20=20=20the=20= local=20identifier=20for=20a=20given=20ICC=20operator=20in=20an=20ICC=0D=0A= =20=20=20=20=20operator=20environment.=0D=0A=0D=0A.in=207=0D=0A=20=20=20=20= This=20table=20MAY=20be=20used=20in=20on-demand=20and/or=20proactive=0D=0A= =20=20=20=20OAM=20operations=20to=20get=20the=20Ingress/Egress=20LSR=0D=0A= =20=20=20=20identifier=20(Local=20Identifier)=20from=20Src-ICC=0D=0A=20=20= =20=20or=20Dst-ICC=20and=20the=20Ingress=20and=20Egress=20LSR=0D=0A=20=20= =20=20identifiers=20are=20used=20to=20retrieve=20the=20tunnel=20entry.=0D= =0A=20=20=20=20This=20table=20returns=20nothing=20when=20the=20= associated=20entry=0D=0A=20=20=20=20is=20not=20defined=20in=20= mplsTunnelExtNodeConfigTable."=0D=0A::=3D=20{=20mplsTeExtObjects=203=20}=0D= =0A=0D=0A.in=206=0D=0AmplsTunnelExtNodeIccMapEntry=20OBJECT-TYPE=0D=0A=20= SYNTAX=20=20=20=20=20=20=20=20MplsTunnelExtNodeIccMapEntry=0D=0A=20= MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20STATUS=20=20=20=20=20=20=20=20= current=0D=0A=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20"An=20entry=20in=20= this=20table=20represents=20a=20mapping=20of=20ICC=20with=0D=0A=20=20=20=20= =20=20=20=20the=20local=20identifier.=0D=0A=0D=0A.in=208=0D=0A=20=20=20=20= =20=20An=20entry=20in=20this=20table=20is=20created=20automatically=20= when=0D=0A=20=20=20=20=20=20the=20Local=20identifier=20is=20associated=20= with=20ICC=20in=0D=0A=20=20=20=20=20=20the=20= mplsTunnelExtNodeConfigTable."=0D=0AINDEX=20{=20= mplsTunnelExtNodeIccMapIccId=20}=0D=0A::=3D=20{=20= mplsTunnelExtNodeIccMapTable=201=20}=0D=0A=0D=0A=0D=0A.in=206=0D=0A= MplsTunnelExtNodeIccMapEntry=20::=3D=20SEQUENCE=20{=0D=0A=20=20=20=20=20=20= mplsTunnelExtNodeIccMapIccId=20=20=20=20=20=20MplsIccId,=0D=0A=20=20=20=20= =20=20mplsTunnelExtNodeIccMapLocalId=20=20=20=20MplsExtendedTunnelId=0D=0A= }=0D=0A=0D=0AmplsTunnelExtNodeIccMapIccId=20OBJECT-TYPE=0D=0A=20=20=20=20= =20SYNTAX=20=20=20=20=20=20MplsIccId=0D=0A=20=20=20=20=20MAX-ACCESS=20=20= not-accessible=0D=0A=20=20=20=20=20STATUS=20=20=20=20=20=20current=0D=0A=20= =20=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"This=20object=20= allows=20the=20operator=20or=20service=20provider=20to=0D=0A=20=20=20=20=20= =20=20=20=20configure=20a=20unique=20MPLS-TP=20ITU-T=20Carrier=20Code=20= (ICC)=0D=0A=20=20=20=20=20=20=20=20=20either=20for=20Ingress=20or=20= Egress=20LSR=20ID.=0D=0A=0D=0A.in=2011=0D=0A=20=20=20=20The=20ICC=20is=20= a=20string=20of=20one=20to=20six=20characters,=20each=0D=0A=20=20=20=20= character=20being=20either=20alphabetic=20(i.e.=20=20A-Z)=20or=0D=0A=20=20= =20=20numeric=20(i.e.=200-9)=20characters.=20Alphabetic=20characters=0D=0A= =20=20=20=20in=20the=20ICC=20should=20be=20represented=20with=20upper=20= case=0D=0A=20=20=20=20letters."=0D=0A::=3D=20{=20= mplsTunnelExtNodeIccMapEntry=201=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtNodeIccMapLocalId=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20= =20=20=20=20=20=20MplsExtendedTunnelId=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-only=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20"This=20object=20contains=20an=20ICC=20= based=20local=20identifier=0D=0A=20=20=20=20=20=20which=20is=20defined=20= in=20mplsTunnelExtNodeConfigTable."=0D=0A=0D=0A=0D=0A=0D=0A.ti=209=0D=0A= ::=3D=20{=20mplsTunnelExtNodeIccMapEntry=202=20}=0D=0A=0D=0A.ti=203=0D=0A= --=20End=20MPLS=20Transport=20Profile=20Node=20ICC=20based=20table=0D=0A=0D= =0A.ti=203=0D=0A--=20Start=20of=20MPLS=20Tunnel=20table=20extension=0D=0A= =0D=0A.in=205=0D=0AmplsTunnelExtTable=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= =20=20=20=20=20=20SEQUENCE=20OF=20MplsTunnelExtEntry=0D=0A=20=20= MAX-ACCESS=20=20=20=20not-accessible=0D=0A=20=20STATUS=20=20=20=20=20=20=20= =20current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20"This=20table=20= represents=20extensions=20to=20mplsTunnelTable=20=0D=0A=20=20=20=20=20in=20= order=20to=20support=20MPLS-TP=20tunnels.=0D=0A=0D=0A.fi=0D=0A.in=2010=0D= =0AAs=20per=20MPLS-TP=20Identifiers=20[RFC6370],=20LSP_ID=20for=20IP=20= based=20\%co-routed=20bidirectional=20tunnel,=0D=0A=0D=0A=0D=0A= A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::=20= Node_ID::Tunnel_Num}::LSP_Num=0D=0A=0D=0ALSP_ID=20for=20IP=20based=20= associated=20bidirectional=20tunnel,=20= \%A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::=20= \%Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}=0D=0A=0D=0A.nf=0D=0A= mplsTunnelTable=20is=20reused=20for=20forming=20the=20LSP_ID=0D=0Aas=20= follows,=0D=0A=0D=0ASource=20Tunnel_Num=20is=20mapped=20with=20= mplsTunnelIndex,=0D=0ASource=20Node_ID=20is=20mapped=20with=0D=0A= mplsTunnelIngressLSRId,=20Destination=20Node_ID=20is=0D=0Amapped=20with=20= mplsTunnelEgressLSRId=20LSP_Num=20is=20mapped=20with=0D=0A= mplsTunnelInstance.=0D=0A=0D=0A.in=207=0D=0A=20=20=20Source=20= Global_Node_ID=20and/or=20ICC=20and=20Destination=0D=0A=20=20=20= Global_Node_ID=20and/or=20ICC=20are=20maintained=20in=20the=0D=0A=20=20=20= mplsTunnelExtNodeConfigTable=20and=0D=0A=20=20=20= mplsTunnelExtNodeConfigLocalId=20is=20used=20to=20create=20an=20entry=0D=0A= =20=20=20in=20mplsTunnelTable."=0D=0AREFERENCE=0D=0A=20=20=20=20=20=20= "MPLS=20Transport=20Profile=20(MPLS-TP)=20Identifiers=20[RFC6370],=0D=0A=20= =20=20=20=20=20=20Section=203=20and=204."=0D=0A::=3D=20{=20= mplsTeExtObjects=204=20}=0D=0A=0D=0A.in=206=0D=0AmplsTunnelExtEntry=20= OBJECT-TYPE=0D=0ASYNTAX=20=20=20=20=20=20=20=20MplsTunnelExtEntry=0D=0A= MAX-ACCESS=20=20=20=20not-accessible=0D=0ASTATUS=20=20=20=20=20=20=20=20= current=0D=0ADESCRIPTION=0D=0A=20=20=20=20=20=20"An=20entry=20in=20this=20= table=20represents=20MPLS-TP=0D=0A=20=20=20=20=20=20=20specific=20= additional=20tunnel=20configurations."=0D=0AINDEX=20{=0D=0A=20=20= mplsTunnelIndex,=0D=0A=20=20mplsTunnelInstance,=0D=0A=20=20= mplsTunnelIngressLSRId,=0D=0A=20=20mplsTunnelEgressLSRId=0D=0A=20}=0D=0A=20= ::=3D=20{=20mplsTunnelExtTable=201=20}=0D=0A=0D=0AMplsTunnelExtEntry=20= ::=3D=20SEQUENCE=20{=0D=0A=20=20=20=20=20mplsTunnelExtOppositeDirPtr=20=20= =20=20=20=20=20=20=20=20RowPointer,=0D=0A=20=20=20=20=20= mplsTunnelExtOppositeDirTnlValid=20=20TruthValue,=0D=0A=20=20=20=20=20= mplsTunnelExtDestTnlIndex=20=20=20=20=20=20=20=20=20MplsTunnelIndex,=0D=0A= =20=20=20=20=20mplsTunnelExtDestTnlLspIndex=20=20=20=20=20=20= MplsTunnelInstanceIndex,=0D=0A=20=20=20=20=20mplsTunnelExtDestTnlValid=20= =20=20=20=20=20=20=20=20TruthValue,=0D=0A=20=20=20=20=20= mplsTunnelExtIngressLSRLocalIdValid=20=20TruthValue,=0D=0A=20=20=20=20=20= mplsTunnelExtEgressLSRLocalIdValid=20=20TruthValue=0D=0A=0D=0A}=0D=0A=0D=0A= mplsTunnelExtOppositeDirPtr=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20= =20=20=20=20=20RowPointer=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"This=20object=20is=20applicable=20= only=20for=20the=20bidirectional=0D=0A=20=20=20=20=20=20=20tunnel=20that=20= has=20the=20forward=20and=20reverse=20LSPs=20in=20the=0D=0A=20=20=20=20=20= =20=20same=20tunnel=20or=20in=20the=20different=20tunnels.=0D=0A=0D=0A= .in=2013=0D=0AThis=20object=20holds=20the=20opposite=20direction=20= tunnel=20entry=0D=0Aif=20the=20bidirectional=20tunnel=20is=20setup=20by=20= configuring=20two=0D=0Atunnel=20entries=20in=20mplsTunnelTable.=0D=0A=0D=0A= .in=2013=0D=0ANote=20that=20there=20are=20two=20different=20ways=20to=20= represent=20the=0D=0Aopposite=20direction=20tunnel=20entry.=20One=20= method=20is=20to=20use=20this=0D=0Aobject=20mplsTunnelExtOppositeDirPtr=20= as=20RowPointer=20and=20make=0D=0Ait=20point=20to=20the=20other=20= direction=20tunnel.=20Other=20method=20is=20to=0D=0Ause=20the=20= mplsTunnelExtDestTnlIndex=20and=0D=0AmplsTunnelExtDestTnlLspIndex=20= instead=20of=20using=20this=0D=0AmplsTunnelExtOppositeDirPtr.=20= Implementation=20can=20choose=0D=0Aeither=20one=20of=20the=20method=20to=20= represent=20the=20opposite=0D=0Adirection=20tunnel.=20Duplicate=20= methods=20are=20provided=20to=20provide=0D=0Aeasy=20ways=20for=20= different=20implementations.=0D=0A=0D=0AThe=20value=20of=20zeroDotZero=20= indicates=20single=20tunnel=20entry=0D=0Ais=20used=20for=20bidirectional=20= tunnel=20setup."=0D=0A=0D=0ADEFVAL=20=20=20{=20zeroDotZero=20}=0D=0A=20= ::=3D=20{=20mplsTunnelExtEntry=201=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtOppositeDirTnlValid=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20= =20=20=20=20=20=20=20TruthValue=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"Denotes=20whether=20or=20not=20= this=20tunnel=20uses=0D=0A=20=20=20=20=20=20=20= mplsTunnelExtOppositeDirPtr=20for=20identifying=20the=20opposite=0D=0A=20= =20=20=20=20=20=20direction=20tunnel=20information.=20Note=20that=20if=20= this=20variable=0D=0A=20=20=20=20=20=20=20is=20set=20to=20true=20then=20= the=20mplsTunnelExtOppositeDirPtr=20should=0D=0A=20=20=20=20=20=20=20= point=20to=20the=20first=20accessible=20row=20of=20the=20opposite=0D=0A=20= =20=20=20=20=20=20direction=20tunnel."=0D=0A=20=20=20DEFVAL=20{=20false=20= }=0D=0A=20=20=20=20=20::=3D=20{=20mplsTunnelExtEntry=202=20}=0D=0A=0D=0A= mplsTunnelExtDestTnlIndex=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20=20= =20=20=20=20MplsTunnelIndex=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"This=20object=20is=20applicable=20= only=20for=20the=20bidirectional=0D=0A=20=20=20=20=20=20=20tunnel=20that=20= has=20the=20forward=20and=20reverse=20LSPs=20in=20the=0D=0A=20=20=20=20=20= =20=20same=20tunnel=20or=20in=20the=20different=20tunnels.=0D=0A=0D=0A= .in=2013=0D=0AThis=20object=20holds=20the=20same=20value=20as=20that=20= of=20the=0D=0AmplsTunnelIndex=20of=20mplsTunnelEntry=20if=20the=20= forward=20and=0D=0Areverse=20LSPs=20are=20in=20the=20same=20tunnel.=20= Otherwise,=0D=0Athis=20object=20holds=20the=20value=20of=20the=20other=20= direction=0D=0Aassociated=20LSP's=20mplsTunnelIndex=20from=20a=20= different=0D=0A=0D=0Atunnel.=0D=0A=0D=0AThe=20values=20of=20this=20= object=20and=20the=0D=0AmplsTunnelExtDestTnlLspIndex=20object=20together=20= can=20be=20used=0D=0Ato=20identify=20an=20opposite=20direction=20LSP=20= i.e.=20if=20the=0D=0AmplsTunnelIndex=20and=20mplsTunnelInstance=20hold=20= the=20value=0D=0Afor=20forward=20LSP,=20this=20object=20and=0D=0A= mplsTunnelExtDestTnlLspIndex=20can=20be=20used=20to=20retrieve=0D=0Athe=20= reverse=20direction=20LSP=20and=20vice=20versa.=0D=0A=0D=0AThis=20object=20= and=20mplsTunnelExtDestTnlLspIndex=20values=0D=0Aprovide=20the=20first=20= two=20indices=20of=20tunnel=20entry=20and=0D=0Athe=20remaining=20indices=20= can=20be=20derived=20as=20follows,=0D=0Aif=20both=20the=20forward=20and=20= reverse=20LSPs=20are=20present=20in=0D=0Athe=20same=20tunnel,=20the=20= opposite=20direction=20LSP's=20Ingress=0D=0Aand=20Egress=20Identifier=20= will=20be=20same=20for=20both=20the=20LSPs,=0D=0Aelse=20the=20Ingress=20= and=20Egress=20Identifiers=20should=20be=0D=0Aswapped=20in=20order=20to=20= index=20the=20other=20direction=20tunnel."=0D=0A=0D=0A.ti=2012=0D=0A::=3D=20= {=20mplsTunnelExtEntry=203=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtDestTnlLspIndex=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20= =20=20=20=20=20MplsTunnelInstanceIndex=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"This=20object=20is=20applicable=20= only=20for=20the=20bidirectional=0D=0A=20=20=20=20=20=20=20tunnel=20that=20= has=20the=20forward=20and=20reverse=20LSPs=20in=20the=0D=0A=20=20=20=20=20= =20=20same=20tunnel=20or=20in=20the=20different=20tunnels.=0D=0A=0D=0A= .fi=0D=0A.in=2013=0D=0AThis=20object=20should=20contain=20different=20= value=20if=20both=20the=20forward=20and=20reverse=20LSPs=20present=20in=20= the=20same=20tunnel.=0D=0A=0D=0A.nf=0D=0AThis=20object=20can=20contain=20= same=20value=20or=20different=20values=0D=0Aif=20the=20forward=20and=20= reverse=20LSPs=20present=20in=20the=20different=0D=0Atunnels."=0D=0A=0D=0A= .ti=2012=0D=0A::=3D=20{=20mplsTunnelExtEntry=204=20}=0D=0A=0D=0A.in=206=0D= =0AmplsTunnelExtDestTnlValid=20=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20=20= =20=20=20=20=20TruthValue=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20=20=20"Denotes=20whether=20or=20not=20= this=20tunnel=20uses=0D=0A=20=20=20=20=20=20=20mplsTunnelExtDestTnlIndex=20= and=0D=0A=20=20=20=20=20=20=20mplsTunnelExtDestTnlLspIndex=20for=20= identifying=0D=0A=20=20=20=20=20=20=20the=20opposite=20direction=20= tunnel=20information.=20Note=20that=20if=0D=0A=20=20=20=20=20=20=20this=20= variable=20is=20set=20to=20true=20then=20the=0D=0A=20=20=20=20=20=20=20= mplsTunnelExtDestTnlIndex=20and=0D=0A=20=20=20=20=20=20=20= mplsTunnelExtDestTnlLspIndex=20objects=20should=20have=0D=0A=20=20=20=20=20= =20=20the=20valid=20opposite=20direction=20tunnel=20indices."=0D=0A=20=20= =20DEFVAL=20{=20false=20}=0D=0A=20=20=20=20=20::=3D=20{=20= mplsTunnelExtEntry=205=20}=0D=0A=0D=0A= mplsTunnelExtIngressLSRLocalIdValid=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20= =20=20=20=20=20=20=20TruthValue=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20"This=20object=20denotes=20whether=20the=20= mplsTunnelIngressLSRId=0D=0A=20=20=20=20=20contains=20the=20local=20= value,=20which=20is=20used=20to=20reference=0D=0A=20=20=20=20=20the=20= complete=20Ingress=20Global_ID::Node_ID=20or=20ICC=20from=0D=0A=20=20=20=20= =20the=20mplsTunnelExtNodeConfigTable."=0D=0A=20=20=20REFERENCE=0D=0A=20=20= =20=20"MPLS-TE-STD-MIB=20[RFC3812],=20Section=2011.=20= mplsTunnelIngressLSRId=0D=0A=20=20=20=20=20object=20in=20= mplsTunnelTable.=20=0D=0A=0D=0A.fi=0D=0A.in=2011=0D=0AIf=20this=20object=20= is=20set=20to=20FALSE,=20mplsTunnelExtNodeConfigTable=20will=20not=20= contain=20an=20entry=20to=20reference=20local=20identifier=20with=20= Global_ID::Node_ID=20or=20ICC=20value.=0D=0A=0D=0A.nf=0D=0A.in=209=0D=0A=20= =20This=20object=20is=20set=20to=20FALSE=20for=20legacy=20= implementations=20like=0D=0A=20=20MPLS=20TE=20tunnels=20where=20= mplsTunnelIngressId=20itself=20provides=0D=0A=20=20complete=20Ingress=20= LSRId."=0D=0ADEFVAL=20{=20false=20}=0D=0A=20=20::=3D=20{=20= mplsTunnelExtEntry=206=20}=0D=0A=0D=0A.in=206=0D=0A= mplsTunnelExtEgressLSRLocalIdValid=20OBJECT-TYPE=0D=0A=20=20=20SYNTAX=20=20= =20=20=20=20=20=20TruthValue=0D=0A=20=20=20MAX-ACCESS=20=20=20=20= read-create=0D=0A=20=20=20STATUS=20=20=20=20=20=20=20=20current=0D=0A=20=20= =20DESCRIPTION=0D=0A=20=20=20=20"This=20object=20denotes=20whether=20the=20= mplsTunnelEgressLSRId=0D=0A=20=20=20=20=20contains=20the=20local=20= value,=20which=20is=20used=20to=20reference=0D=0A=20=20=20=20=20the=20= complete=20Egress=20Global_ID::Node_ID=20or=20ICC=20from=0D=0A=20=20=20=20= =20the=20mplsTunnelExtNodeConfigTable."=0D=0A=20=20=20REFERENCE=0D=0A=20=20= =20=20"MPLS-TE-STD-MIB=20[RFC3812],=20Section=2011.=20= mplsTunnelEgressLSRId=0D=0A=20=20=20=20=20object=20in=20mplsTunnelTable.=0D= =0A=0D=0A.fi=0D=0A.in=2011=0D=0AIf=20this=20object=20is=20set=20to=20= FALSE,=20mplsTunnelExtNodeConfigTable=20will=20not=20contain=20an=20= entry=20to=20reference=20local=20identifier=20with=20Global_ID::Node_ID=20= or=20ICC=20value.=0D=0A=0D=0A.nf=0D=0A.in=209=0D=0A=20=20This=20object=20= is=20set=20to=20FALSE=20for=20legacy=20implementations=20like=0D=0A=20=20= MPLS=20TE=20tunnels=20where=20mplsTunnelEgressId=20itself=20provides=0D=0A= =20=20complete=20Egress=20LSRId."=0D=0ADEFVAL=20{=20false=20}=0D=0A=20=20= ::=3D=20{=20mplsTunnelExtEntry=207=20}=0D=0A=0D=0A.in=206=0D=0A--=20End=20= of=20MPLS=20Tunnel=20table=20extension=0D=0A= mplsTunnelExtReversePerfTable=20=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= SEQUENCE=20OF=20MplsTunnelExtReversePerfEntry=0D=0A=20=20MAX-ACCESS=20= not-accessible=0D=0A=20=20STATUS=20=20current=0D=0A=20=20DESCRIPTION=0D=0A= =20=20=20=20"This=20table=20extends=20the=20mplsTunnelTable=20to=20= provide=0D=0A=20=20=20=20=20per-tunnel=20packet=20performance=20= information=20for=20the=20reverse=0D=0A=20=20=20=20=20direction=20of=20a=20= bidirectional=20tunnel.=20=20It=20can=20be=20seen=20as=0D=0A=20=20=20=20=20= supplementing=20the=20mplsTunnelPerfTable,=20which=20augments=20the=0D=0A= =20=20=20=20=20mplsTunnelTable.=0D=0A=0D=0A=20=20=20=20=20For=20links=20= that=20do=20not=20transport=20packets,=20these=20packet=0D=0A=20=20=20=20= =20counters=20cannot=20be=20maintained.=20=20For=20such=20links,=20= attempts=0D=0A=20=20=20=20=20to=20read=20the=20objects=20in=20this=20= table=20will=20return=0D=0A=20=20=20=20=20noSuchInstance."=0D=0A=20=20= REFERENCE=0D=0A=20=20=20=20"1.=20Multiprotocol=20Label=20Switching=20= (MPLS)=20Traffic=0D=0A=20=20=20=20=20=20=20=20Engineering=20= (TE)Management=20Information=20Base=20(MIB),=0D=0A=20=20=20=20=20=20=20=20= RFC=203812.=20Section=206.6.=20mplsTunnelPerfTable"=0D=0A::=3D=20{=20= mplsTeExtObjects=205=20}=0D=0A=0D=0AmplsTunnelExtReversePerfEntry=20= OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20MplsTunnelExtReversePerfEntry=0D=0A=20= =20MAX-ACCESS=20not-accessible=0D=0A=20=20STATUS=20=20current=0D=0A=20=20= DESCRIPTION=0D=0A=20=20=20=20"An=20entry=20in=20this=20table=20is=20= created=20by=20the=20LSR=20for=20every=0D=0A=20=20=20=20=20bidirectional=20= MPLS=20tunnel=20where=20packets=20are=20visible=20to=20the=0D=0A=20=20=20= =20=20LSR."=0D=0AINDEX=20{=0D=0A=20=20mplsTunnelIndex,=0D=0A=20=20= mplsTunnelInstance,=0D=0A=20=20mplsTunnelIngressLSRId,=0D=0A=20=20= mplsTunnelEgressLSRId=0D=0A=20}=0D=0A::=3D=20{=20= mplsTunnelExtReversePerfTable=201=20}=0D=0A=0D=0A= MplsTunnelExtReversePerfEntry=20::=3D=20SEQUENCE=20{=0D=0A=20=20= mplsTunnelExtReversePerfPackets=20=20=20=20=20Counter32,=0D=0A=20=20= mplsTunnelExtReversePerfHCPackets=20=20=20Counter64,=0D=0A=20=20= mplsTunnelExtReversePerfErrors=20=20=20=20=20=20Counter32,=0D=0A=20=20= mplsTunnelExtReversePerfBytes=20=20=20=20=20=20=20Counter32,=0D=0A=20=20= mplsTunnelExtReversePerfHCBytes=20=20=20=20=20Counter64=0D=0A}=0D=0A=0D=0A= mplsTunnelExtReversePerfPackets=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= Counter32=0D=0A=20=20MAX-ACCESS=20read-only=0D=0A=0D=0A.in=208=0D=0A= STATUS=20=20current=0D=0ADESCRIPTION=0D=0A=20=20"Number=20of=20packets=20= forwarded=20on=20the=20tunnel=20in=20the=20reverse=0D=0A=20=20=20= direction=20if=20it=20is=20bidirectional.=0D=0A=0D=0A.in=2011=0D=0AThis=20= object=20represents=20the=2032-bit=20value=20of=20the=20least=0D=0A= significant=20part=20of=20the=2064-bit=20value=20if=20both=0D=0A= mplsTunnelExtReversePerfHCPackets=20and=20this=20object=0D=0Aare=20= returned.=0D=0A=0D=0A.in=206=0D=0A=20=20=20=20=20For=20links=20that=20do=20= not=20transport=20packets,=20this=20packet=0D=0A=20=20=20=20=20counter=20= cannot=20be=20maintained.=20=20For=20such=20links,=20this=20value=0D=0A=20= =20=20=20=20will=20return=20noSuchInstance."=0D=0A::=3D=20{=20= mplsTunnelExtReversePerfEntry=201=20}=0D=0A=0D=0A= mplsTunnelExtReversePerfHCPackets=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= Counter64=0D=0A=20=20MAX-ACCESS=20read-only=0D=0A=20=20STATUS=20=20= current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20"High-capacity=20counter=20= for=20number=20of=20packets=20forwarded=20on=0D=0A=20=20=20=20=20the=20= tunnel=20in=20the=20reverse=20direction=20if=20it=20is=0D=0A=20=20=20=20=20= bidirectional.=0D=0A=0D=0A=20=20=20=20=20For=20links=20that=20do=20not=20= transport=20packets,=20this=20packet=0D=0A=20=20=20=20=20counter=20= cannot=20be=20maintained.=20=20For=20such=20links,=20this=20value=0D=0A=20= =20=20=20=20will=20return=20noSuchInstance."=0D=0A::=3D=20{=20= mplsTunnelExtReversePerfEntry=202=20}=0D=0A=0D=0A= mplsTunnelExtReversePerfErrors=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= Counter32=0D=0A=20=20MAX-ACCESS=20read-only=0D=0A=20=20STATUS=20=20= current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20"Number=20of=20errored=20= packets=20received=20on=20the=20tunnel=20in=0D=0A=20=20=20=20=20the=20= reverse=20direction=20if=20it=20is=20bidirectional.=20=20For=20links=0D=0A= =20=20=20=20=20that=20do=20not=20transport=20packets,=20this=20packet=20= counter=20cannot=0D=0A=20=20=20=20=20be=20maintained.=20=20For=20such=20= links,=20this=20value=20will=20return=0D=0A=20=20=20=20=20= noSuchInstance."=0D=0A::=3D=20{=20mplsTunnelExtReversePerfEntry=203=20}=0D= =0A=0D=0AmplsTunnelExtReversePerfBytes=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20= =20Counter32=0D=0A=20=20MAX-ACCESS=20read-only=0D=0A=20=20STATUS=20=20= current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20"Number=20of=20bytes=20= forwarded=20on=20the=20tunnel=20in=20the=20reverse=0D=0A=20=20=20=20=20= direction=20if=20it=20is=20bidirectional.=0D=0A=0D=0A.fi=0D=0A.in=2011=0D= =0AThis=20object=20represents=20the=2032-bit=20value=20of=20the=20least=20= significant=20part=20of=20the=2064-bit=20value=20if=20both=20= mplsTunnelExtReversePerfHCBytes=20and=20this=20object=20are=20returned.=0D= =0A=0D=0A.nf=0D=0A.in=206=0D=0A=20=20=20=20=20For=20links=20that=20do=20= not=20transport=20packets,=20this=20packet=0D=0A=20=20=20=20=20counter=20= cannot=20be=20maintained.=20=20For=20such=20links,=20this=20value=0D=0A=20= =20=20=20=20will=20return=20noSuchInstance."=0D=0A::=3D=20{=20= mplsTunnelExtReversePerfEntry=204=20}=0D=0A=0D=0A= mplsTunnelExtReversePerfHCBytes=20OBJECT-TYPE=0D=0A=20=20SYNTAX=20=20= Counter64=0D=0A=20=20MAX-ACCESS=20read-only=0D=0A=20=20STATUS=20=20= current=0D=0A=20=20DESCRIPTION=0D=0A=20=20=20=20"High-capacity=20counter=20= for=20number=20of=20bytes=20forwarded=20on=20the=0D=0A=20=20=20=20=20= tunnel=20in=20the=20reverse=20direction=20if=20it=20is=20bidirectional.=0D= =0A=0D=0A=20=20=20=20=20For=20links=20that=20do=20not=20transport=20= packets,=20this=20packet=0D=0A=20=20=20=20=20counter=20cannot=20be=20= maintained.=20=20For=20such=20links,=20this=20value=0D=0A=20=20=20=20=20= will=20return=20noSuchInstance."=0D=0A::=3D=20{=20= mplsTunnelExtReversePerfEntry=205=20}=0D=0A=0D=0A.in=205=0D=0A--=20= Notifications.=0D=0A--=20Notification=20objects=20need=20to=20be=20added=20= here.=0D=0A--=20End=20of=20notifications.=0D=0A=0D=0A--=20Module=20= compliance.=0D=0A=0D=0AmplsTeExtGroups=0D=0A=20=20=20OBJECT=20IDENTIFIER=20= ::=3D=20{=20mplsTeExtConformance=201=20}=0D=0A=0D=0AmplsTeExtCompliances=0D= =0A=20=20=20OBJECT=20IDENTIFIER=20::=3D=20{=20mplsTeExtConformance=202=20= }=0D=0A=0D=0A--=20Compliance=20requirement=20for=20fully=20compliant=20= implementations.=0D=0A=0D=0AmplsTeExtModuleFullCompliance=20= MODULE-COMPLIANCE=0D=0A=20=20=20STATUS=20current=0D=0A=20=20=20= DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20"Compliance=20statement=20for=20= agents=20that=20provide=20full=0D=0A=20=20=20=20=20=20=20=20=20=20= support=20the=20MPLS-TE-EXT-STD-MIB=20module."=0D=0A=0D=0A.ti=208=0D=0A= MODULE=20--=20this=20module=0D=0A=0D=0A.in=2011=0D=0A--=20The=20= mandatory=20group=20has=20to=20be=20implemented=20by=20all=0D=0A--=20= LSRs=20that=20originate/terminate=20MPLS-TP=20tunnels.=0D=0A--=20In=20= addition,=20depending=20on=20the=20type=20of=20tunnels=0D=0A--=20= supported,=20other=20groups=20become=20mandatory=20as=0D=0A=0D=0A--=20= explained=20below.=0D=0A=0D=0AMANDATORY-GROUPS=20=20=20=20{=0D=0A=20=20=20= mplsTunnelExtGroup=0D=0A}=0D=0A=0D=0AGROUP=20= mplsTunnelExtIpOperatorGroup=0D=0A=0D=0ADESCRIPTION=0D=0A=20=20=20=20= "This=20group=20is=20mandatory=20for=20devices=20which=20support=0D=0A=20= =20=20=20=20configuration=20of=20IP=20based=20identifier=20tunnels."=0D=0A= =0D=0AGROUP=20mplsTunnelExtIccOperatorGroup=0D=0A=0D=0A=0D=0A=0D=0A= DESCRIPTION=0D=0A=20=20=20=20"This=20group=20is=20mandatory=20for=20= devices=20which=20support=0D=0A=20=20=20=20=20configuration=20of=20ICC=20= based=20tunnels."=0D=0A=0D=0A.ti=2012=0D=0A::=3D=20{=20= mplsTeExtCompliances=201=20}=0D=0A=0D=0A.ti=205=0D=0A--=20Compliance=20= requirement=20for=20read-only=20implementations.=0D=0A=0D=0A.in=205=0D=0A= mplsTeExtModuleReadOnlyCompliance=20MODULE-COMPLIANCE=0D=0A=20=20=20= STATUS=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20=20=20=20=20= "Compliance=20statement=20for=20agents=20that=20provide=20full=0D=0A=20=20= =20=20=20=20=20=20=20=20support=20the=20MPLS-TE-EXT-STD-MIB=20module."=0D= =0A=0D=0A.ti=208=0D=0AMODULE=20--=20this=20module=0D=0A=0D=0A.in=2011=0D=0A= --=20The=20mandatory=20group=20has=20to=20be=20implemented=20by=20all=0D=0A= --=20LSRs=20that=20originate/terminate=20MPLS-TP=20tunnels.=0D=0A--=20In=20= addition,=20depending=20on=20the=20type=20of=20tunnels=0D=0A--=20= supported,=20other=20groups=20become=20mandatory=20as=0D=0A--=20= explained=20below.=0D=0A=0D=0AMANDATORY-GROUPS=20=20=20=20{=0D=0A=20=20=20= mplsTunnelExtGroup=0D=0A}=0D=0A=0D=0AGROUP=20= mplsTunnelExtIpOperatorGroup=0D=0ADESCRIPTION=0D=0A=20=20=20=20"This=20= group=20is=20mandatory=20for=20devices=20which=20support=0D=0A=20=20=20=20= =20configuration=20of=20IP=20based=20identifier=20tunnels."=0D=0A=0D=0A= GROUP=20mplsTunnelExtIccOperatorGroup=0D=0A=0D=0ADESCRIPTION=0D=0A=20=20=20= =20"This=20group=20is=20mandatory=20for=20devices=20which=20support=0D=0A= =20=20=20=20=20configuration=20of=20ICC=20based=20tunnels."=0D=0A=0D=0A= .ti=2010=0D=0A::=3D=20{=20mplsTeExtCompliances=202=20}=0D=0A=0D=0A.ti=20= 7=0D=0A--=20Units=20of=20conformance.=0D=0A=0D=0A=0D=0A.in=207=0D=0A= mplsTunnelExtGroup=20OBJECT-GROUP=0D=0A=20=20=20OBJECTS=20{=0D=0A=20=20=20= =20=20mplsTunnelExtOppositeDirPtr,=0D=0A=20=20=20=20=20= mplsTunnelExtOppositeDirTnlValid,=0D=0A=20=20=20=20=20= mplsTunnelExtDestTnlIndex,=0D=0A=20=20=20=20=20= mplsTunnelExtDestTnlLspIndex,=0D=0A=20=20=20=20=20= mplsTunnelExtDestTnlValid,=0D=0A=20=20=20=20=20= mplsTunnelExtIngressLSRLocalIdValid,=0D=0A=20=20=20=20=20= mplsTunnelExtEgressLSRLocalIdValid,=0D=0A=20=20=20=20=20= mplsTunnelExtReversePerfPackets,=0D=0A=20=20=20=20=20= mplsTunnelExtReversePerfHCPackets,=0D=0A=20=20=20=20=20= mplsTunnelExtReversePerfErrors,=0D=0A=20=20=20=20=20= mplsTunnelExtReversePerfBytes,=0D=0A=20=20=20=20=20= mplsTunnelExtReversePerfHCBytes=0D=0A=20}=0D=0A=0D=0A.in=208=0D=0ASTATUS=20= =20current=0D=0ADESCRIPTION=0D=0A=20=20=20=20=20"Necessary,=20but=20not=20= sufficient,=20set=20of=20objects=20to=0D=0A=20=20=20=20=20=20=20= implement=20tunnels.=20=20In=20addition,=20depending=20on=20the=0D=0A=20=20= =20=20=20=20=20operating=20environment,=20the=20following=20groups=20are=0D= =0A=20=20=20=20=20=20=20mandatory."=0D=0A::=3D=20{=20mplsTeExtGroups=201=20= }=0D=0A=0D=0A.in=205=0D=0AmplsTunnelExtIpOperatorGroup=20=20OBJECT-GROUP=0D= =0A=20=20=20OBJECTS=20{=20mplsTunnelExtNodeConfigGlobalId,=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20mplsTunnelExtNodeConfigNodeId,=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20mplsTunnelExtNodeConfigRowStatus,=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20mplsTunnelExtNodeConfigStorageType,=0D=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20mplsTunnelExtNodeIpMapLocalId=0D=0A= =20=20=20}=0D=0A=20=20=20STATUS=20=20current=0D=0A=20=20=20DESCRIPTION=0D= =0A=20=20=20=20=20=20=20=20"Object(s)=20needed=20to=20implement=20IP=20= compatible=20tunnels."=0D=0A=20=20=20::=3D=20{=20mplsTeExtGroups=202=20}=0D= =0A=0D=0AmplsTunnelExtIccOperatorGroup=20=20OBJECT-GROUP=0D=0A=20=20=20= OBJECTS=20{=20mplsTunnelExtNodeConfigIccId,=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20=20mplsTunnelExtNodeConfigRowStatus,=0D=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20mplsTunnelExtNodeConfigStorageType,=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20mplsTunnelExtNodeIccMapLocalId=0D=0A=20=20=20}=0D= =0A=20=20=20STATUS=20=20current=0D=0A=20=20=20DESCRIPTION=0D=0A=20=20=20=20= =20=20=20=20"Object(s)=20needed=20to=20implement=20ICC=20based=20= tunnels."=0D=0A=20=20=20::=3D=20{=20mplsTeExtGroups=203=20}=0D=0A=0D=0A= --=20MPLS-TE-EXT-STD-MIB=20module=20ends=0D=0AEND=0D=0A=0D=0A.ti=200=0D=0A= 14.=20Security=20Consideration=0D=0A=0D=0A.fi=0D=0A.in=206=0D=0AThere=20= is=20a=20number=20of=20management=20objects=20defined=20in=20this=20MIB=20= module=20that=20has=20a=20MAX-ACCESS=20clause=20of=20read-write..=20Such=20= objects=20may=20be=20considered=20sensitive=20or=20vulnerable=20in=20= some=20network=20environments.=20The=20support=20for=20SET=20operations=20= in=20a=20non-secure=20environment=20without=20proper=20protection=20can=20= have=20a=20negative=20effect=20on=20network=20operations.=0D=0A=0D=0A.nf=0D= =0ASome=20of=20the=20readable=20objects=20in=20this=20MIB=20module=20= (i.e.,=20objects=0D=0Awith=20a=20MAX-ACCESS=20other=20than=20= not-accessible)=20may=20be=20considered=0D=0Asensitive=20or=20vulnerable=20= in=20some=20network=20environments.=0D=0AIt=20is=20thus=20important=20to=20= control=20even=20GET=20and/or=20NOTIFY=20access=20to=0D=0Athese=20= objects=20and=20possibly=20to=20even=20encrypt=20the=20values=20of=20= these=0D=0Aobjects=20when=20sending=20them=20over=20the=20network=20via=20= SNMP.=20=20These=20are=0D=0Athe=20tables=20and=20objects=20and=20their=20= sensitivity/vulnerability:=0D=0A=0D=0ASNMP=20versions=20prior=20to=20= SNMPv3=20did=20not=20include=20adequate=20security.=0D=0AEven=20if=20the=20= network=20itself=20is=20secure=20(for=20example=20by=20using=20IPsec),=0D= =0Aeven=20then,=20there=20is=20no=20control=20as=20to=20who=20on=20the=20= secure=20network=20is=0D=0Aallowed=20to=20access=20and=20GET/SET=20= (read/change/create/delete)=0D=0Athe=20objects=20in=20this=20MIB=20= module.=0D=0A=0D=0A.fi=0D=0AIt=20is=20recommended=20that=20implementers=20= consider=20the=20security=20features=20as=20provided=20by=20the=20SNMPv3=20= framework=20(see=20[RFC3410],=20section=208),=20including=20full=20= supports=20for=20the=20SNMPv3=20cryptographic=20mechanisms=20(for=20= authentication=20and=20privacy).=0D=0A=0D=0A.nf=0D=0AFurther,=20= deployment=20of=20SNMP=20versions=20prior=20to=20SNMPv3=20is=20not=0D=0A= recommended.=20=20Instead,=20it=20is=20recommended=20to=20deploy=20= SNMPv3=20and=20to=0D=0Aenable=20cryptographic=20security.=20=20It=20is=20= then=20a=20customer/operator=0D=0Aresponsibility=20to=20ensure=20that=20= the=20SNMP=20entity=20giving=20access=20to=20an=0D=0Ainstance=20of=20= this=20MIB=20module=20is=20properly=20configured=20to=20give=0D=0Aaccess=20= to=20the=20objects=20only=20to=20those=20principles=20(users)=20that=0D=0A= have=20legitimate=20rights=20to=20indeed=20GET=20or=20SET=20= (change/create/delete)=0D=0Athem.=0D=0A.bp=0D=0A.ti=200=0D=0A15.=20IANA=20= Considerations=0D=0A=0D=0A.ti=203=0D=0ATo=20be=20added=20in=20a=20later=20= version=20of=20this=20document.=0D=0A=0D=0A.ti=200=0D=0A16.=20References=0D= =0A=0D=0A.ti=200=0D=0A16.1.=20Normative=20References=0D=0A=0D=0A.fi=0D=0A= .in=2016=0D=0A.ti=204=0D=0A[RFC2119]=20Bradner,=20S.,=20"Key=20words=20= for=20use=20in=20RFCs=20to=20Indicate=20Requirement=20Levels",=20BCP=20= 14,=20RFC=202119,=20March=201997.=0D=0A=0D=0A.ti=204=0D=0A[RFC2578]=20= McCloghrie,=20K.,=20Perkins,=20D.,=20and=20J.=20Schoenwaelder,=20= "Structure=20of=20Management=20Information=20Version=202=20(SMIv2)",=20= STD=2058,=20RFC=202578,=20April=201999.=0D=0A=0D=0A.ti=204=0D=0A= [RFC2579]=20McCloghrie,=20K.,=20Perkins,=20D.,=20and=20J.=20= Schoenwaelder,=20"Textual=20Conventions=20for=20SMIv2",=20STD=2058,=20= RFC=202579,=20April=201999.=0D=0A=0D=0A.ti=204=0D=0A[RFC2580]=20= McCloghrie,=20K.,=20Perkins,=20D.,=20and=20J.=20Schoenwaelder,=0D=0A=0D=0A= "Conformance=20Statements=20for=20SMIv2",=20STD=2058,=20RFC=202580,=20= April=201999.=0D=0A=0D=0A.ti=204=0D=0A[RFC3031]=20=20Rosen,=20E.,=20= Viswanathan,=20A.,=20and=20R.=20Callon,=20"Multiprotocol=20Label=20= Switching=20Architecture",=20RFC=203031,=20January=202001.=0D=0A=0D=0A= .ti=200=0D=0A16.2.=20=20Informative=20References=0D=0A=0D=0A.nf=0D=0A.in=20= 4=0D=0A[RFC3812]=20Srinivasan,=20C.,=20Viswanathan,=20A.,=20and=20T.=20= Nadeau,=0D=0A=20=20=20=20=20=20=20=20=20=20=20"Multiprotocol=20Label=20= Switching=20(MPLS)=20Traffic=20Engineering=0D=0A=20=20=20=20=20=20=20=20=20= =20=20=20(TE)=20Management=20Information=20Base=20(MIB)",=20RFC=203812,=20= June=0D=0A=20=20=20=20=20=20=20=20=20=20=20=202004.=0D=0A=0D=0A[RFC3813]=20= Srinivasan,=20C.,=20Viswanathan,=20A.,=20and=20T.=20Nadeau,=0D=0A=20=20=20= =20=20=20=20=20=20=20=20"Multiprotocol=20Label=20Switching=20(MPLS)=20= Label=20Switching=0D=0A=20=20=20=20=20=20=20=20=20=20(LSR)=20Router=20= Management=20Information=20Base=20(MIB)",=20RFC=203813,=0D=0A=20=20=20=20= =20=20=20=20=20=20=20=20June=202004.=0D=0A=0D=0A.fi=0D=0A.in=2016=0D=0A= .ti=204=0D=0A[RFC3410]=20J.=20Case,=20R.=20Mundy,=20D.=20pertain,=20= B.Stewart,=20"Introduction=20and=20Applicability=20Statement=20for=20= Internet=20Standard=20Management=20Framework",=20RFC=203410,=20December=20= 2002.=0D=0A=0D=0A.ti=204=0D=0A[RFC3811]=20Nadeau,=20T.,=20Ed.,=20and=20= J.=20Cucchiara,=20Ed.,=20"Definitions=20of=20Textual=20Conventions=20= (TCs)=20for=20Multiprotocol=20Label=20Switching=20(MPLS)=20Management",=20= RFC=203811,=20June=202004.=0D=0A=0D=0A.ti=204=0D=0A[RFC4802]=20Nadeau,=20= T.,=20Ed.,=20and=20A.=20Farrel,=20Ed.,=20"Generalized=0D=0A=0D=0A.nf=0D=0A= .in=203=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20Multiprotocol=20= Label=20Switching=20(GMPLS)=20Traffic=0D=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20Engineering=20=20=20=20=20=20=20=20=20=20Management=20= Information=20Base",=20RFC=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= 4802,=20February=202007.=0D=0A[RFC5654]=20Niven-Jenkins,=20B.,=20Ed.,=20= Brungard,=20D.,=20Ed.,=20Betts,=20M.,=20Ed.,=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20Sprecher,=20N.,=20and=20S.=20Ueno,=20"Requirements=20of=20an=20= MPLS=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Transport=20Profile",=20= RFC=205654,=20September=202009.=0D=0A=0D=0A.fi=0D=0A.in=2015=0D=0A.ti=20= 3=0D=0A[RFC6370]=20Bocci,=20M.,=20Swallow,=20G.,=20and=20E.=20Gray,=20= "MPLS=20Transport=20Profile=20=20=20=20=20=20=20(MPLS-TP)=20= Identifiers",=20RFC=206370,=20September=202011.=0D=0A=0D=0A.fi=0D=0A.in=20= 15=0D=0A.ti=203=0D=0A[I-D.ietf-mpls-tp-itu-t-identifiers]=20Winter,=20= R.,=20Gray,=20E.,=20Helvoort,=20H.,=20and=20M.=20Betts,=20"MPLS-TP=20= Identifiers=20Following=20ITU-T=20Conventions",=20= draft-ietf-mpls-tp-itu-t-identifiers-07=20(work=20in=20progress),=20= August=202012.=0D=0A=0D=0A.ti=200=0D=0A17.=20Acknowledgments=0D=0A=0D=0A= .in=203=0D=0AThe=20authors=20would=20like=20to=20thank=20Francesco=20= Fondelli,=20Josh=20Littlefield,=20Agrahara=20Kiran=20Koushik,=20Metrri=20= Jain,=20Muly=20Ilan,=20Joan=20Cucchiara=20and=20Randy=20Presuhn=20for=20= their=20valuable=20comments.=0D=0A=0D=0A.ti=200=0D=0A18.=20Authors'=20= Addresses=0D=0A=0D=0A.nf=0D=0ASam=20Aldrin=0D=0AHuawei=20Technologies=0D=0A= 2330=20Central=20Express=20Way,=0D=0ASanta=20Clara,=20CA=2095051,=20USA=0D= =0AEmail:=20=20aldrin.ietf@gmail.com=0D=0A=0D=0AThomas=20D.=20Nadeau=0D=0A= Juniper=20Networks=0D=0A10=20Technology=20Park=20Drive,=20Westford,=20MA=20= 01886=0D=0AEmail:=20tnadeau@juniper.net=0D=0A=0D=0AVenkatesan=20= Mahalingam=0D=0ADell=20Inc.=0D=0A350=20Holger=20way,=20San=20Jose,=20CA,=20= USA=0D=0AEmail:=20venkat.mahalingams@gmail.com=0D=0A=0D=0AKannan=20KV=20= Sampath=0D=0ARedeem=0D=0AIndia=0D=0AEmail:=20kannankvs@gmail.com=0D=0A= --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Disposition: attachment; filename=TP-TE-MIB-Comments-13-Jan-2013.xls Content-Type: application/vnd.ms-excel; name="TP-TE-MIB-Comments-13-Jan-2013.xls" Content-Transfer-Encoding: quoted-printable =D0=CF=11=E0=A1=B1=1A=E1=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00>=00= =03=00=FE=FF=09= =00=06=00=00=00=00=00=00=00=00=00=00=00=01=00=00=00t=00=00=00=00=00=00=00=00= =10=00=00=FE=FF=FF=FF=00=00=00=00=FE=FF=FF=FF=00=00=00=00s=00=00=00=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=09=08=10=00=00=06=05=00g2=CD=07=D9=00=03=00=06=06=00=00=E1=00= =02=00=B0=04=C1=00=02=00=00=00=E2=00=00=00\=00p=00=15=00=00Mahalinga,=20= Venkatesan=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= B=00=02=00=B0=04a=01=02=00=00=00=C0=01=00=00=3D=01=02=00=01=00=9C=00=02=00= =11=00=19=00=02=00=00=00=12=00=02=00=00=00=13=00=02=00=00=00=AF=01=02=00=00= =00=BC=01=02=00=00=00=3D=00=12=00=00=00M=FE=DD@=DB$8=00=00=00=00=00=01=00X= =02@=00=02=00=00=00=8D=00=02=00=00=00"=00=02=00=00=00=0E=00=02=00=01=00=B7= =01=02=00=00=00=DA=00=02=00=00=001=00=1E=00=DC=00=00=00=08=00=90=01=00=00=00= =02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=00=00=08=00=90= =01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=00= =00=08=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E= =00=DC=00=00=00=08=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00= i=001=00=1E=00=DC=00=00=00=08=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00= i=00b=00r=00i=001=00=1E=00=DC=00=00=00=09= =00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC= =00=00=00=0E=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001= =00=1E=00=DC=00=01=004=00=BC=02=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00= r=00i=001=00=1E=00=DC=00=01=00=09= =00=BC=02=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC= =00=02=00=17=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001= =00=1E=00=DC=00=00=00=11=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b= =00r=00i=001=00=1E=00,=01=01=00>=00=BC=02=00=00=00=02=00=A2=07=01C=00a=00l= =00i=00b=00r=00i=001=00=1E=00=04=01=01=00>=00=BC=02=00=00=00=02=00=A2=07=01= C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=01=00>=00=BC=02=00=00=00=02=00= =A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=00=00>=00=90=01=00=00= =00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=00=004=00=90= =01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00=DC=00=00= =00<=00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=001=00=1E=00= =DC=00=01=00?=00=BC=02=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=00= 1=00=1E=00h=01=01=00>=00=BC=02=00=00=00=02=00=A2=07=01C=00a=00m=00b=00r=00= i=00a=001=00=1E=00=DC=00=01=00=08=00=BC=02=00=00=00=02=00=A2=07=01C=00a=00= l=00i=00b=00r=00i=001=00=1E=00=DC=00=00=00=0A= =00=90=01=00=00=00=02=00=A2=07=01C=00a=00l=00i=00b=00r=00i=00=1E=04=1C=00=05= =00=17=00=00"$"#,##0_);\("$"#,##0\)=1E=04!=00=06=00=1C=00=00"$"#,##0_);[Re= d]\("$"#,##0\)=1E=04"=00=07=00=1D=00=00"$"#,##0.00_);\("$"#,##0.00\)=1E=04= '=00=08=00"=00=00"$"#,##0.00_);[Red]\("$"#,##0.00\)=1E=047=00*=002=00=00_(= "$"*=20#,##0_);_("$"*=20\(#,##0\);_("$"*=20"-"_);_(@_)=1E=04.=00)=00)=00=00= _(*=20#,##0_);_(*=20\(#,##0\);_(*=20"-"_);_(@_)=1E=04?=00,=00:=00=00_("$"*= =20#,##0.00_);_("$"*=20\(#,##0.00\);_("$"*=20"-"??_);_(@_)=1E=046=00+=001=00= =00_(*=20#,##0.00_);_(*=20\(#,##0.00\);_(*=20"-"??_);_(@_)=E0=00=14=00=00=00= =00=00=F5=FF=20=00=00=00=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00= =00=F5=FF=20=00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00= =F5=FF=20=00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5= =FF=20=00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF= =20=00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=00=00=00=00=01=00=20= =00=00=00=00=00=00=00=00=00=00=02=C0=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=89=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AF=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=9A=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=89=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=9B=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AF=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=96=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=9D=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AB=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=96=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AC=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AF=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B1=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=9D=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AB=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=96=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B1=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AF=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B1=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=93=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=93=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B6=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B1=20=E0=00=14=00=06=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=B5=20=E0=00=14=00=07=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AD=20=E0=00=14=00=08=00=00=00=F5=FF=20= =00=00=94=11=11=97=0B=97=0B=00=04=89=20=E0=00=14=00=09=00=00=00=F5=FF=20= =00=00=94ff=BF=1F=BF=1F=00=04=B7=20=E0=00=14=00=05=00+=00=F5=FF=20= =00=00=F8=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00)=00=F5=FF=20= =00=00=F8=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00,=00=F5=FF=20= =00=00=F8=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=05=00*=00=F5=FF=20= =00=00=F8=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=0A=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=0B=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AA=20=E0=00=14=00=0C=00=00=00=F5=FF=20= =00=00=D4=00P=00=00=80=18=00=00=C0=20=E0=00=14=00=0D=00=00=00=F5=FF=20= =00=00=D4=00P=00=00=00=0B=00=00=C0=20=E0=00=14=00=0E=00=00=00=F5=FF=20= =00=00=D4=00=20=00=00=80=18=00=00=C0=20=E0=00=14=00=0E=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=0F=00=00=00=F5=FF=20= =00=00=94=11=11=97=0B=97=0B=00=04=AF=20=E0=00=14=00=10=00=00=00=F5=FF=20= =00=00=D4=00`=00=00=00=1A=00=00=C0=20=E0=00=14=00=11=00=00=00=F5=FF=20= =00=00=B4=00=00=00=00=00=00=00=04=AB=20=E0=00=14=00=05=00=00=00=F5=FF=20= =00=00=9C=11=11=16=0B=16=0B=00=04=9A=20=E0=00=14=00=12=00=00=00=F5=FF=20= =00=00=94=11=11=BF=1F=BF=1F=00=04=89=20=E0=00=14=00=05=00=09=00=F5=FF=20= =00=00=F8=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=13=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=14=00=00=00=F5=FF=20= =00=00=D4=00a=00=00=B1=18=00=00=C0=20=E0=00=14=00=15=00=00=00=F5=FF=20= =00=00=F4=00=00=00=00=00=00=00=00=C0=20=E0=00=14=00=00=00=00=00=01=00(=00=00= 0=11=11@=20@=20=00=02=C0=20=E0=00=14=00=00=00=00=00=01=00(=00=00=10=00=00=00= =00=00=00=00=02=C0=20=E0=00=14=00=14=00=00=00=01=00=1A=00=00x=11=11@=20@=20= =00=06"=20=E0=00=14=00=14=00=00=00=01=00=18=00=00X=00=00=00=00=00=00=00=06= "=20=E0=00=14=00=14=00=00=00=01=00=1A=00=00x=01=11@=00@=20=00=06"=20= =E0=00=14=00=00=00=00=00=01=00(=00=000=01=11@=00@=20=00=02=C0=20= =E0=00=14=00=14=00=00=00=01=00=18=00=00x=11=11@=20@=20=00=06"=20= |=08=14=00|=08=00=00=00=00=00=00=00=00=00=00=00=00E=00'=86|=1F}=08-=00}=08= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=01=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=02=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=03=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=04=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=05=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=06=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=07=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=08=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=09=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0A=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0B=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0C=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0D=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0E=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=0F=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08A=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00=10=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= ef=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =11=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00ef=05=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=00=12=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= ef=06=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =13=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00ef=07=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=00=14=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= ef=08=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =15=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00ef=09=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=00=16=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =CCL=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =17=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=CCL=05=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00=18=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =CCL=06=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =19=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=CCL=07=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00=1A=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =CCL=08=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =1B=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=CCL=09=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00=1C=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= 23=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =1D=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=0023=05=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=00=1E=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= 23=06=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= =1F=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=0023=07=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=00=20=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= 23=08=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= !=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02= =04=00=14=00=03=0023=09=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00= =00=00=00=00=00=00"=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =00=00=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00= =00#=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=00=00=05=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00$=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =00=00=06=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00= =00%=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=00=00=07=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00&=00=00=00=03=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=03=00= =00=00=08=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00= =00'=00=00=00=03=00=0D=00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=03=00=00=00=09=00=00=00;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00(=00=00=00=03=00=0D= =00=14=00=02=00=00=00=9C=00=06=FF00\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=FF=C7=CE=FF;_(@_)=20=20}=08=91=00}=08=00=00=00=00=00=00=00=00=00=00= =00=00)=00=00=00=07=00=0D=00=14=00=02=00=00=00=FA}=00=FF00\);_(*=0E=00=05=00= =02=04=00=14=00=02=00=00=00=F2=F2=F2=FF;_(@_)=20=20=07=00=14=00=02=00=00=00= =7F=7F=7F=FF=20=20=20=20=20=20=20=20=08=00=14=00=02=00=00=00=7F=7F=7F=FF=20= =20=20=20=20=20=20=20=09=00=14=00=02=00=00=00=7F=7F=7F=FF=00=00=00=00=00=00= =00=00=0A=00=14=00=02=00=00=00=7F=7F=7F=FF=00=00=00=00=00=00=00=00}=08=91=00= }=08=00=00=00=00=00=00=00=00=00=00=00=00*=00=00=00=07=00=0D= =00=14=00=03=00=00=00=00=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=A5=A5=A5=FF;_(@_)=20=20=07=00=14=00=02=00=00=00???=FF=20=20=20=20=20= =20=20=20=08=00=14=00=02=00=00=00???=FF=20=20=20=20=20=20=20=20=09= =00=14=00=02=00=00=00???=FF=00=00=00=00=00=00=00=00=0A= =00=14=00=02=00=00=00???=FF=00=00=00=00=00=00=00=00}=08-=00}=08=00=00=00=00= =00=00=00=00=00=00=00=00+=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00,=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00-=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00.=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00/=00=00=00=02=00=0D= =00=14=00=02=00=00=00=7F=7F=7F=FF00\);_(*=0E=00=05=00=02}=08A=00}=08=00=00= =00=00=00=00=00=00=00=00=00=000=00=00=00=03=00=0D= =00=14=00=02=00=00=00=00a=00=FF00\);_(*=0E=00=05=00=02=04=00=14=00=02=00=00= =00=C6=EF=CE=FF;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= 1=00=00=00=03=00=0D=00=14=00=03=00=00=00=03=00=00=0000\);_(*=0E=00=05=00=02= =08=00=14=00=03=00=00=00=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00= =00=00=00=00=00=00=002=00=00=00=03=00=0D= =00=14=00=03=00=00=00=03=00=00=0000\);_(*=0E=00=05=00=02=08=00=14=00=03=00= =FF?=04=00=00=00;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= 3=00=00=00=03=00=0D=00=14=00=03=00=00=00=03=00=00=0000\);_(*=0E=00=05=00=02= =08=00=14=00=03=0023=04=00=00=00;_(@_)=20=20}=08-=00}=08=00=00=00=00=00=00= =00=00=00=00=00=004=00=00=00=02=00=0D= =00=14=00=03=00=00=00=03=00=00=0000\);_(*=0E=00=05=00=02}=08=91=00}=08=00=00= =00=00=00=00=00=00=00=00=00=005=00=00=00=07=00=0D= =00=14=00=02=00=00=00??v=FF00\);_(*=0E=00=05=00=02=04=00=14=00=02=00=00=00= =FF=CC=99=FF;_(@_)=20=20=07=00=14=00=02=00=00=00=7F=7F=7F=FF=20=20=20=20=20= =20=20=20=08=00=14=00=02=00=00=00=7F=7F=7F=FF=20=20=20=20=20=20=20=20=09= =00=14=00=02=00=00=00=7F=7F=7F=FF=00=00=00=00=00=00=00=00=0A= =00=14=00=02=00=00=00=7F=7F=7F=FF=00=00=00=00=00=00=00=00}=08A=00}=08=00=00= =00=00=00=00=00=00=00=00=00=006=00=00=00=03=00=0D= =00=14=00=02=00=00=00=FA}=00=FF00\);_(*=0E=00=05=00=02=08=00=14=00=02=00=00= =00=FF=80=01=FF;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00= 7=00=00=00=03=00=0D=00=14=00=02=00=00=00=9Ce=00=FF00\);_(*=0E=00=05=00=02=04= =00=14=00=02=00=00=00=FF=EB=9C=FF;_(@_)=20=20}=08=91=00}=08=00=00=00=00=00= =00=00=00=00=00=00=008=00=00=00=07=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=FF=FF=CC=FF;_(@_)=20=20=07=00=14=00=02=00=00=00=B2=B2=B2=FF=20=20=20= =20=20=20=20=20=08=00=14=00=02=00=00=00=B2=B2=B2=FF=20=20=20=20=20=20=20=20= =09=00=14=00=02=00=00=00=B2=B2=B2=FF=00=00=00=00=00=00=00=00=0A= =00=14=00=02=00=00=00=B2=B2=B2=FF=00=00=00=00=00=00=00=00}=08=91=00}=08=00= =00=00=00=00=00=00=00=00=00=00=009=00=00=00=07=00=0D= =00=14=00=02=00=00=00???=FF00\);_(*=0E=00=05=00=02=04=00=14=00=02=00=00=00= =F2=F2=F2=FF;_(@_)=20=20=07=00=14=00=02=00=00=00???=FF=20=20=20=20=20=20=20= =20=08=00=14=00=02=00=00=00???=FF=20=20=20=20=20=20=20=20=09= =00=14=00=02=00=00=00???=FF=00=00=00=00=00=00=00=00=0A= =00=14=00=02=00=00=00???=FF=00=00=00=00=00=00=00=00}=08-=00}=08=00=00=00=00= =00=00=00=00=00=00=00=00:=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00;=00=00=00=02=00=0D= =00=14=00=03=00=00=00=03=00=00=0000\);_(*=0E=00=05=00=01}=08U=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00<=00=00=00=04=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=07=00=14=00=03=00= =00=00=04=00=00=00;_(@_)=20=20=08=00=14=00=03=00=00=00=04=00=00=00=20=20=20= =20=20=20=20=20}=08-=00}=08=00=00=00=00=00=00=00=00=00=00=00=00=3D=00=00=00= =02=00=0D=00=14=00=02=00=00=00=FF=00=00=FF00\);_(*=0E=00=05=00=02}=08-=00}= =08=00=00=00=00=00=00=00=00=00=00=00=00>=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08-=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00?=00=00=00=02=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02}=08A=00}=08=00=00= =00=00=00=00=00=00=00=00=00=00@=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=FF=FF=00=FF;_(@_)=20=20}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00= =00A=00=00=00=03=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02=04=00=14=00=02=00=00=00=FF=FF=00=FF;_(@_)=20=20= }=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00B=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=FF=FF=00=FF;_(@_)=20=20}=08-=00}=08=00=00=00=00=00=00=00=00=00=00=00= =00C=00=00=00=02=00=0D=00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00= =02}=08A=00}=08=00=00=00=00=00=00=00=00=00=00=00=00D=00=00=00=03=00=0D= =00=14=00=03=00=00=00=01=00=00=0000\);_(*=0E=00=05=00=02=04=00=14=00=02=00= =00=00=FF=FF=00=FF;_(@_)=20=20=93=02=12=00=10=00=0D=00=0020%=20-=20= Accent1=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04=1E=FF=0D= =002=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=001=00=00=00=03=00=01= =00=0C=00=07=04ef=DC=E6=F1=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00= =02=93=02=12=00=11=00=0D=00=0020%=20-=20Accent2=92=08M=00=92=08=00=00=00=00= =00=00=00=00=00=00=01=04"=FF=0D=002=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=002=00=00=00=03=00=01=00=0C=00=07=05ef=F2=DC=DB=FF= =05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00=02=93=02=12=00=12=00=0D= =00=0020%=20-=20Accent3=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= &=FF=0D=002=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=003=00=00=00=03= =00=01=00=0C=00=07=06ef=EB=F1=DE=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00= =05=00=02=93=02=12=00=13=00=0D=00=0020%=20-=20= Accent4=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04*=FF=0D= =002=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=004=00=00=00=03=00=01= =00=0C=00=07=07ef=E4=DF=EC=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00= =02=93=02=12=00=14=00=0D=00=0020%=20-=20Accent5=92=08M=00=92=08=00=00=00=00= =00=00=00=00=00=00=01=04.=FF=0D=002=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=005=00=00=00=03=00=01=00=0C=00=07=08ef=DA=EE=F3=FF= =05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00=02=93=02=12=00=15=00=0D= =00=0020%=20-=20Accent6=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= 2=FF=0D=002=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=006=00=00=00=03= =00=01=00=0C=00=07=09ef=FD=E9=D9=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00= =05=00=02=93=02=12=00=16=00=0D=00=0040%=20-=20= Accent1=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04=1F=FF=0D= =004=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=001=00=00=00=03=00=01= =00=0C=00=07=04=CCL=B8=CC=E4=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05= =00=02=93=02=12=00=17=00=0D=00=0040%=20-=20Accent2=92=08M=00=92=08=00=00=00= =00=00=00=00=00=00=00=01=04#=FF=0D=004=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=002=00=00=00=03=00=01=00=0C=00=07=05=CCL=E6=B8=B7= =FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00=02=93=02=12=00=18=00=0D= =00=0040%=20-=20Accent3=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= '=FF=0D=004=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=003=00=00=00=03= =00=01=00=0C=00=07=06=CCL=D8=E4=BC=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%= =00=05=00=02=93=02=12=00=19=00=0D=00=0040%=20-=20= Accent4=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04+=FF=0D= =004=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=004=00=00=00=03=00=01= =00=0C=00=07=07=CCL=CC=C0=DA=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05= =00=02=93=02=12=00=1A=00=0D=00=0040%=20-=20Accent5=92=08M=00=92=08=00=00=00= =00=00=00=00=00=00=00=01=04/=FF=0D=004=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=005=00=00=00=03=00=01=00=0C=00=07=08=CCL=B7=DE=E8= =FF=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00=02=93=02=12=00=1B=00=0D= =00=0040%=20-=20Accent6=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= 3=FF=0D=004=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=006=00=00=00=03= =00=01=00=0C=00=07=09=CCL=FC=D5=B4=FF=05=00=0C=00=07=01=00=00=00=00=00=FF%= =00=05=00=02=93=02=12=00=1C=00=0D=00=0060%=20-=20= Accent1=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04=20=FF=0D= =006=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=001=00=00=00=03=00=01= =00=0C=00=07=0423=95=B3=D7=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00= =02=93=02=12=00=1D=00=0D=00=0060%=20-=20Accent2=92=08M=00=92=08=00=00=00=00= =00=00=00=00=00=00=01=04$=FF=0D=006=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=002=00=00=00=03=00=01=00=0C=00=07=0523=DA=96=94=FF= =05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=12=00=1E=00=0D= =00=0060%=20-=20Accent3=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= (=FF=0D=006=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=003=00=00=00=03= =00=01=00=0C=00=07=0623=C4=D7=9B=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00= =05=00=02=93=02=12=00=1F=00=0D=00=0060%=20-=20= Accent4=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04,=FF=0D= =006=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=004=00=00=00=03=00=01= =00=0C=00=07=0723=B1=A0=C7=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00= =02=93=02=12=00=20=00=0D=00=0060%=20-=20Accent5=92=08M=00=92=08=00=00=00=00= =00=00=00=00=00=00=01=040=FF=0D=006=000=00%=00=20=00-=00=20= =00A=00c=00c=00e=00n=00t=005=00=00=00=03=00=01=00=0C=00=07=0823=92=CD=DC=FF= =05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=12=00!=00=0D= =00=0060%=20-=20Accent6=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= 4=FF=0D=006=000=00%=00=20=00-=00=20=00A=00c=00c=00e=00n=00t=006=00=00=00=03= =00=01=00=0C=00=07=0923=FA=BF=8F=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00= =05=00=02=93=02=0C= =00"=00=07=00=00Accent1=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= =1D=FF=07=00A=00c=00c=00e=00n=00t=001=00=00=00=03=00=01=00=0C=00=07=04=00=00= O=81=BD=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=0C= =00#=00=07=00=00Accent2=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= !=FF=07=00A=00c=00c=00e=00n=00t=002=00=00=00=03=00=01=00=0C=00=07=05=00=00= =C0PM=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=0C= =00$=00=07=00=00Accent3=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= %=FF=07=00A=00c=00c=00e=00n=00t=003=00=00=00=03=00=01=00=0C=00=07=06=00=00= =9B=BBY=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=0C= =00%=00=07=00=00Accent4=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= )=FF=07=00A=00c=00c=00e=00n=00t=004=00=00=00=03=00=01=00=0C=00=07=07=00=00= =80d=A2=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=0C= =00&=00=07=00=00Accent5=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= -=FF=07=00A=00c=00c=00e=00n=00t=005=00=00=00=03=00=01=00=0C=00=07=08=00=00= K=AC=C6=FF=05=00=0C=00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=0C= =00'=00=07=00=00Accent6=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=04= 1=FF=07=00A=00c=00c=00e=00n=00t=006=00=00=00=03=00=01=00=0C=00=07=09= =00=00=F7=96F=FF=05=00=0C= =00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=93=02=08=00(=00=03=00=00Bad=92=08= 9=00=92=08=00=00=00=00=00=00=00=00=00=00=01=01=1B=FF=03=00B=00a=00d=00=00=00= =03=00=01=00=0C=00=05=FF=00=00=FF=C7=CE=FF=05=00=0C=00=05=FF=00=00=9C=00=06= =FF%=00=05=00=02=93=02=10=00)=00=0B=00=00Calculation=92=08=81=00=92=08=00=00= =00=00=00=00=00=00=00=00=01=02=16=FF=0B=00C=00a=00l=00c=00u=00l=00a=00t=00= i=00o=00n=00=00=00=07=00=01=00=0C=00=05=FF=00=00=F2=F2=F2=FF=05=00=0C= =00=05=FF=00=00=FA}=00=FF%=00=05=00=02=06=00=0E=00=05=FF=00=00=7F=7F=7F=FF= =01=00=07=00=0E=00=05=FF=00=00=7F=7F=7F=FF=01=00=08=00=0E=00=05=FF=00=00=7F= =7F=7F=FF=01=00=09=00=0E=00=05=FF=00=00=7F=7F=7F=FF=01=00=93=02=0F=00*=00=0A= =00=00Check=20Cell=92=08=7F=00=92=08=00=00=00=00=00=00=00=00=00=00=01=02=17= =FF=0A=00C=00h=00e=00c=00k=00=20=00C=00e=00l=00l=00=00=00=07=00=01=00=0C= =00=05=FF=00=00=A5=A5=A5=FF=05=00=0C= =00=07=00=00=00=FF=FF=FF=FF%=00=05=00=02=06=00=0E=00=05=FF=00=00???=FF=06=00= =07=00=0E=00=05=FF=00=00???=FF=06=00=08=00=0E=00=05=FF=00=00???=FF=06=00=09= =00=0E=00=05=FF=00=00???=FF=06=00=93=02=04=00+=80=03=FF=92=08=20= =00=92=08=00=00=00=00=00=00=00=00=00=00=01=05=03=FF=05=00C=00o=00m=00m=00a= =00=00=00=00=00=93=02=04=00,=80=06=FF=92=08(=00=92=08=00=00=00=00=00=00=00= =00=00=00=01=05=06=FF=09=00C=00o=00m=00m=00a=00=20= =00[=000=00]=00=00=00=00=00=93=02=04=00-=80=04=FF=92=08&=00=92=08=00=00=00= =00=00=00=00=00=00=00=01=05=04=FF=08=00C=00u=00r=00r=00e=00n=00c=00y=00=00= =00=00=00=93=02=04=00.=80=07=FF=92=08.=00=92=08=00=00=00=00=00=00=00=00=00= =00=01=05=07=FF=0C=00C=00u=00r=00r=00e=00n=00c=00y=00=20= =00[=000=00]=00=00=00=00=00=93=02=15=00/=00=10=00=00Explanatory=20= Text=92=08G=00=92=08=00=00=00=00=00=00=00=00=00=00=01=025=FF=10=00E=00x=00= p=00l=00a=00n=00a=00t=00o=00r=00y=00=20=00T=00e=00x=00t=00=00=00=02=00=05=00= =0C=00=05=FF=00=00=7F=7F=7F=FF%=00=05=00=02=93=02=09= =000=00=04=00=00Good=92=08;=00=92=08=00=00=00=00=00=00=00=00=00=00=01=01=1A= =FF=04=00G=00o=00o=00d=00=00=00=03=00=01=00=0C=00=05=FF=00=00=C6=EF=CE=FF=05= =00=0C=00=05=FF=00=00=00a=00=FF%=00=05=00=02=93=02=0E=001=00=09=00=00Headi= ng=201=92=08G=00=92=08=00=00=00=00=00=00=00=00=00=00=01=03=10=FF=09= =00H=00e=00a=00d=00i=00n=00g=00=20=001=00=00=00=03=00=05=00=0C= =00=07=03=00=00=1FI}=FF%=00=05=00=02=07=00=0E=00=07=04=00=00O=81=BD=FF=05=00= =93=02=0E=002=00=09=00=00Heading=202=92=08G=00=92=08=00=00=00=00=00=00=00=00= =00=00=01=03=11=FF=09=00H=00e=00a=00d=00i=00n=00g=00=20=002=00=00=00=03=00= =05=00=0C=00=07=03=00=00=1FI}=FF%=00=05=00=02=07=00=0E=00=07=04=FF?=A7=BF=DE= =FF=05=00=93=02=0E=003=00=09=00=00Heading=203=92=08G=00=92=08=00=00=00=00=00= =00=00=00=00=00=01=03=12=FF=09=00H=00e=00a=00d=00i=00n=00g=00=20= =003=00=00=00=03=00=05=00=0C=00=07=03=00=00=1FI}=FF%=00=05=00=02=07=00=0E=00= =07=0423=95=B3=D7=FF=02=00=93=02=0E=004=00=09=00=00Heading=20= 4=92=089=00=92=08=00=00=00=00=00=00=00=00=00=00=01=03=13=FF=09= =00H=00e=00a=00d=00i=00n=00g=00=20=004=00=00=00=02=00=05=00=0C= =00=07=03=00=00=1FI}=FF%=00=05=00=02=93=02=0A= =005=00=05=00=00Input=92=08u=00=92=08=00=00=00=00=00=00=00=00=00=00=01=02=14= =FF=05=00I=00n=00p=00u=00t=00=00=00=07=00=01=00=0C=00=05=FF=00=00=FF=CC=99= =FF=05=00=0C=00=05=FF=00=00??v=FF%=00=05=00=02=06=00=0E=00=05=FF=00=00=7F=7F= =7F=FF=01=00=07=00=0E=00=05=FF=00=00=7F=7F=7F=FF=01=00=08=00=0E=00=05=FF=00= =00=7F=7F=7F=FF=01=00=09=00=0E=00=05=FF=00=00=7F=7F=7F=FF=01=00=93=02=10=00= 6=00=0B=00=00Linked=20Cell=92=08K=00=92=08=00=00=00=00=00=00=00=00=00=00=01= =02=18=FF=0B=00L=00i=00n=00k=00e=00d=00=20=00C=00e=00l=00l=00=00=00=03=00=05= =00=0C=00=05=FF=00=00=FA}=00=FF%=00=05=00=02=07=00=0E=00=05=FF=00=00=FF=80= =01=FF=06=00=93=02=0C= =007=00=07=00=00Neutral=92=08A=00=92=08=00=00=00=00=00=00=00=00=00=00=01=01= =1C=FF=07=00N=00e=00u=00t=00r=00a=00l=00=00=00=03=00=01=00=0C=00=05=FF=00=00= =FF=EB=9C=FF=05=00=0C= =00=05=FF=00=00=9Ce=00=FF%=00=05=00=02=93=02=04=00=00=80=00=FF=92=083=00=92= =08=00=00=00=00=00=00=00=00=00=00=01=01=00=FF=06=00N=00o=00r=00m=00a=00l=00= =00=00=02=00=05=00=0C=00=07=01=00=00=00=00=00=FF%=00=05=00=02=93=02=09= =008=00=04=00=00Note=92=08b=00=92=08=00=00=00=00=00=00=00=00=00=00=01=02=0A= =FF=04=00N=00o=00t=00e=00=00=00=05=00=01=00=0C= =00=05=FF=00=00=FF=FF=CC=FF=06=00=0E=00=05=FF=00=00=B2=B2=B2=FF=01=00=07=00= =0E=00=05=FF=00=00=B2=B2=B2=FF=01=00=08=00=0E=00=05=FF=00=00=B2=B2=B2=FF=01= =00=09=00=0E=00=05=FF=00=00=B2=B2=B2=FF=01=00=93=02=0B= =009=00=06=00=00Output=92=08w=00=92=08=00=00=00=00=00=00=00=00=00=00=01=02= =15=FF=06=00O=00u=00t=00p=00u=00t=00=00=00=07=00=01=00=0C=00=05=FF=00=00=F2= =F2=F2=FF=05=00=0C= =00=05=FF=00=00???=FF%=00=05=00=02=06=00=0E=00=05=FF=00=00???=FF=01=00=07=00= =0E=00=05=FF=00=00???=FF=01=00=08=00=0E=00=05=FF=00=00???=FF=01=00=09= =00=0E=00=05=FF=00=00???=FF=01=00=93=02=04=00:=80=05=FF=92=08$=00=92=08=00= =00=00=00=00=00=00=00=00=00=01=05=05=FF=07=00P=00e=00r=00c=00e=00n=00t=00=00= =00=00=00=93=02=0A=00;=00=05=00=00Title=92=081=00=92=08=00=00=00=00=00=00=00= =00=00=00=01=03=0F=FF=05=00T=00i=00t=00l=00e=00=00=00=02=00=05=00=0C= =00=07=03=00=00=1FI}=FF%=00=05=00=01=93=02=0A= =00<=00=05=00=00Total=92=08M=00=92=08=00=00=00=00=00=00=00=00=00=00=01=03=19= =FF=05=00T=00o=00t=00a=00l=00=00=00=04=00=05=00=0C= =00=07=01=00=00=00=00=00=FF%=00=05=00=02=06=00=0E=00=07=04=00=00O=81=BD=FF= =01=00=07=00=0E=00=07=04=00=00O=81=BD=FF=06=00=93=02=11=00=3D=00=0C= =00=00Warning=20Text=92=08?=00=92=08=00=00=00=00=00=00=00=00=00=00=01=02=0B= =FF=0C=00W=00a=00r=00n=00i=00n=00g=00=20=00T=00e=00x=00t=00=00=00=02=00=05= =00=0C= =00=05=FF=00=00=FF=00=00=FF%=00=05=00=02=8E=08X=00=8E=08=00=00=00=00=00=00= =00=00=00=00=90=00=00=00=11=00=11=00T=00a=00b=00l=00e=00S=00t=00y=00l=00e=00= M=00e=00d=00i=00u=00m=009=00P=00i=00v=00o=00t=00S=00t=00y=00l=00e=00L=00i=00= g=00h=00t=001=006=00=92=00=E2=008=00=00=00=00=00=FF=FF=FF=00=DD=08=06=00=1F= =B7=14=00=00=00=D4=00=FC=F3=05=00=F2=08=84=00=00=AB=EA=00=90=00=00=00=00d=11= =00=00=00=90=00=90q:=00F=00=A5=00=00=80=80=00=C0=C0=C0=00=80=80=80=00=99=99= =FF=00=993f=00=FF=FF=CC=00=CC=FF=FF=00f=00f=00=FF=80=80=00=00f=CC=00=CC=CC= =FF=00=00=00=80=00=FF=00=FF=00=FF=FF=00=00=00=FF=FF=00=80=00=80=00=80=00=00= =00=00=80=80=00=00=00=FF=00=00=CC=FF=00=CC=FF=FF=00=CC=FF=CC=00=FF=FF=99=00= =99=CC=FF=00=FF=99=CC=00=CC=99=FF=00=FF=CC=99=003f=FF=003=CC=CC=00=99=CC=00= =00=FF=CC=00=00=FF=99=00=00=FFf=00=00ff=99=00=96=96=96=00=003f=003=99f=00=00= 3=00=0033=00=00=993=00=00=993f=0033=99=00333=00\=10=0E=00=03=00=00=00=00=00= =FF=FF=FF=00=00=00=00=00`=01=02=00=00=00=85=00=16=00p=A8=00=00=00=00=0E=00= TP-TE-Comments=9A=08=18=00=9A=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=04=00=00=00=A3=08=10=00=A3=08=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=8C=00=04=00=01=00=01=00=C1=01=08=00=C1=01=00=00=1D=EB=01=00=FC=00= =20=20=99=00=00=00V=00=00=00=04=00=00S.No=08=00=00Comments=09=00=00Raised=20= by=0A=00=00Resolution=04=00=00Open[=01=00Comments=20on=20the=20= mplsTunnelExtTable=20in=20draft-ietf-mpls-tp-te-mib-04.txt=0AThe=20text=20= describes=20the=20tunnel=20as=20adding=20MPLS-TP=20tunnel=20specific=20= additional=20objects;=20however,=20it=20may=20also=20be=20appropriate=20= to=20identify=20the=20reverse=20direction=20tunnel=20for=20MPLS-TE.=20=20= =20The=20table=20name=20is=20correct=20for=20non=20MPLS-TP=20tunnel=20= specific=20objects,=20so=20can=20we=20change=20the=20= description?=B5=01=00Comments=20on=20the=20mplsTunnelExtTable=20in=20= draft-ietf-mpls-tp-te-mib-04.txt=0AThere=20are=20currently=20two=20= methods=20for=20specifying=20the=20opposite=20direction=20LSP:=20one=20= using=20a=20row=20pointer=20and=20the=20other=20using=20a=20subset=20of=20= the=20mplsTunnelTable=20indices.=20=20This=20is=20a=20potential=20source=20= of=20confusion,=20so=20I=20suggest=20that=20the=20table=20is=20redefined=20= to=20use=20a=20single=20method,=20for=20example=20by=20specifying=20all=20= of=20the=20indices=20of=20the=20mplsTunnelEntry=20for=20the=20opposite=20= direction=20LSP.=1A=00=00John=20Salloway=20(MetaSwitch)=0F=00=00Muly=20= Ilan=20(Rad)v=00=01S=00e=00c=00t=00i=00o=00n=00=20=009=00.=002=00.=006=00=20= =00s=00h=00o=00u=00l=00d=00=20=00b=00e=00=20=00r=00e=00n=00a=00m=00e=00d=00= =20=00t=00o=00=20=00=1C=20R=00e=00v=00e=00r=00s=00e=00=20= =00d=00i=00r=00e=00c=00t=00i=00o=00n=00=20= =00m=00p=00l=00s=00T=00u=00n=00n=00e=00l=00E=00n=00t=00r=00y=00=1D=20=20= =00i=00n=00s=00t=00e=00a=00d=00=20=00o=00f=00=20=00=1C=20F=00o=00r=00w=00a= =00r=00d=00=20=00d=00i=00r=00e=00c=00t=00i=00o=00n=00=20= =00m=00p=00l=00s=00T=00u=00n=00n=00e=00l=00E=00n=00t=00r=00y=00=1D=20= .=00=91=00=01=20=00I=00n=00=20=00s=00e=00c=00t=00i=00o=00n=00=20= =009=00.=002=00.=001=000=00=20=00c=00h=00a=00n=00g=00e=00=20=00=1C=20= m=00p=00l=00s=00X=00C=00E=00x=00t=00T=00u=00n=00n=00e=00l=00P=00o=00i=00n=00= t=00e=00r=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=3D=00=20= =00m=00p=00l=00s=00T=00u=00n=00n=00e=00l=00N=00a=00m=00e=00.=001=00.=001=00= .=001=00.=002=00=1D=20=20=00t=00o=00=20=00=1C=20= m=00p=00l=00s=00X=00C=00E=00x=00t=00T=00u=00n=00n=00e=00l=00P=00o=00i=00n=00= t=00e=00r=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=20=00=3D=00=20= =00m=00p=00l=00s=00T=00u=00n=00n=00e=00l=00N=00a=00m=00e=00.=002=00.=001=00= .=002=00.=001=00=1D=20.=00=E7=17=00I=20would=20like=20to=20express=20= that=20I=20can=20see=20why=20the=20MIB=20Modules=0Aare=20designed=20as=20= they=20are.=20=20Namely,=20so=20mplsTunnelTable=20(in=20rfc3812)=0Acan=20= be=20used=20for=20MPLS-TP=20Tunnels=20also.=20=20I=20do=20see=20there=20= is=20likely=20to=0Abe=20value=20in=20doing=20that.=20=20However,=20my=20= concern=20is=20that=0Athe=20semantic=20definition=20of=20two=20indices=20= for=20mplsTunnelTable=0A(mplsTunnelIngressLSRId,=20=20= mplsTunnelEgressLSRId)=0Aare=20being=20semantically=20redefined=20in=20= the=20MPLS-TE-EXT-STD-MIB,=20and=20this=0Abreaks=20the=20rules=20of=20= the=20SMI=20and=20there=20is=20a=20chance=20that=20legacy=0A= implementations=20could=20be=20jeopardized.=0A=0AThe=20index=20being=20= proposed=20is:=20mplsNodeConfigLocalId=0A=0A=20=20=20=20=20=20=20=20= mplsNodeConfigLocalId=20=20OBJECT-TYPE=0A=20=20=20=20=20=20=20=20=20=20=20= SYNTAX=20=20=20=20=20=20=20=20MplsLocalId=0A=20=20=20=20=20=20=20=20=20=20= =20MAX-ACCESS=20=20=20=20not-accessible=0A=20=20=20=20=20=20=20=20=20=20=20= STATUS=20=20=20=20=20=20=20=20current=0A=20=20=20=20=20=20=20=20=20=20=20= DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20=20=20=20"This=20object=20= allows=20the=20administrator=20to=20assign=20a=20unique=0A=20=20=20=20=20= =20=20=20=20=20=20=20=20=20local=20identifier=20to=20map=20= Global_Node_ID=20or=20ICC."=0A=20=20=20=20=20=20=20=20=20=20=20::=3D=20{=20= mplsNodeConfigEntry=201=20}=0A=0AWhere=20the=20TC=20MplsLocalId=20is:=0A=0A= =20=20=20=20=20MplsLocalId=20::=3D=20TEXTUAL-CONVENTION=0A=20=20=20=20=20= =20=20=20DISPLAY-HINT=20"d"=0A=20=20=20=20=20=20=20=20STATUS=20=20=20=20=20= =20current=0A=20=20=20=20=20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20=20= =20=20"This=20textual=20convention=20is=20used=20in=20accommodating=20= the=20bigger=0A=20=20=20=20=20=20=20=20=20=20=20size=20Global_Node_ID=20= and/or=20ICC=20with=20lower=20size=20LSR=0A=20=20=20=20=20=20=20=20=20=20= =20identifier=20in=20order=20to=20index=20the=20mplsTunnelTable.=0A=0A=20= =20=20=20=20=20=20=20=20=20=20The=20Local=20Identifier=20is=20configured=20= between=201=20and=2016777215,=0A=20=20=20=20=20=20=20=20=20=20=20as=20= valid=20IP=20address=20range=20starts=20from=2016777216(01.00.00.00).=0A=20= =20=20=20=20=20=20=20=20=20=20This=20range=20is=20chosen=20to=20identify=20= the=20mplsTunnelTable's=0A=20=20=20=20=20=20=20=20=20=20=20= Ingress/Egress=20LSR-id=20is=20IP=20address=20or=20Local=20identifier,=0A= =20=20=20=20=20=20=20=20=20=20=20if=20the=20configured=20range=20is=20= not=20IP=20address,=20administrator=20is=0A=20=20=20=20=20=20=20=20=20=20= =20expected=20to=20retrieve=20the=20complete=20information=0A=20=20=20=20= =20=20=20=20=20=20(Global_Node_ID=20or=20ICC)=20from=20= mplsNodeConfigTable.=20This=20way,=0A=20=20=20=20=20=20=20=20=20=20=20= existing=20mplsTunnelTable=20is=20reused=20for=20bidirectional=20tunnel=0A= =20=20=20=20=20=20=20=20=20=20=20extensions=20for=20MPLS=20based=20= transport=20networks.=0A=0A=20=20=20=20=20=20=20=20=20=20=20This=20Local=20= Identifier=20allows=20the=20administrator=20to=20assign=0A=20=20=20=20=20= =20=20=20=20=20=20a=20unique=20identifier=20to=20map=20Global_Node_ID=20= and/or=20ICC."=0A=20=20=20=20=20=20=20=20SYNTAX=20=20= Unsigned32(1..16777215)=0A=0A=0A=0AThe=20MPLS-TE-STD-MIB=20(rfc3812)=20= and=20the=20MPLS-TC-STD-MIB=20(rfc3811)=0Ahave=20described=20the=20= MplsExtendedTunnelId=20as:=0A=0A=20=20MplsTunnelEntry=20::=3D=20SEQUENCE=20= {=0A.....=0A=20=20=20=20=20=20=20=20mplsTunnelIngressLSRId=20=20=20=20=20= =20=20MplsExtendedTunnelId,=0A=20=20=20=20=20=20=20=20= mplsTunnelEgressLSRId=20=20=20=20=20=20=20=20MplsExtendedTunnelId,=0A=0A=0A= =0A=20=20mplsTunnelIngressLSRId=20OBJECT-TYPE=0A=20=20=20=20=20SYNTAX=20=20= =20=20=20=20=20=20MplsExtendedTunnelId=0A=20=20=20=20=20MAX-ACCESS=20=20=20= =20not-accessible=0A=20=20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0A= =20=20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20"Identity=20= of=20the=20ingress=20LSR=20associated=20with=20this=0A=20=20=20=20=20=20=20= =20=20=20=20=20tunnel=20instance.=20When=20the=20MPLS=20signalling=20= protocol=0A=20=20=20=20=20=20=20=20=20=20=20=20is=20rsvp(2)=20this=20= value=20SHOULD=20be=20equal=20to=20the=20Tunnel=0A=20=20=20=20=20=20=20=20= =20=20=20=20Sender=20Address=20in=20the=20Sender=20Template=20object=20= and=20MAY=0A=20=20=20=20=20=20=20=20=20=20=20=20be=20equal=20to=20the=20= Extended=20Tunnel=20Id=20field=20in=20the=0A=20=20=20=20=20=20=20=20=20=20= =20=20SESSION=20object.=20When=20the=20MPLS=20signalling=20protocol=20is=0A= =20=20=20=20=20=20=20=20=20=20=20=20crldp(3)=20this=20value=20SHOULD=20= be=20equal=20to=20the=20Ingress=0A=20=20=20=20=20=20=20=20=20=20=20=20= LSR=20Router=20ID=20field=20in=20the=20LSPID=20TLV=20object."=0A=20=20=20= =20=20REFERENCE=0A=20=20=20=20=20=20=20=20=20=20"1.=20RSVP-TE:=20= Extensions=20to=20RSVP=20for=20LSP=20Tunnels,=0A=20=20=20=20=20=20=20=20=20= =20=20=20Awduche=20et=20al,=20RFC=203209,=20December=202001=0A=20=20=20=20= =20=20=20=20=20=20=202.=20Constraint-Based=20LSP=20Setup=20using=20LDP,=20= Jamoussi=0A=20=20=20=20=20=20=20=20=20=20=20=20(Editor),=20RFC=203212,=20= January=202002"=0A=20=20=20=20=20::=3D=20{=20mplsTunnelEntry=203=20}=0A=0A= =20=20mplsTunnelEgressLSRId=20OBJECT-TYPE=0A=20=20=20=20=20SYNTAX=20=20=20= =20=20=20=20=20MplsExtendedTunnelId=0A=20=20=20=20=20MAX-ACCESS=20=20=20=20= not-accessible=0A=20=20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0A=20= =20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20"Identity=20of=20= the=20egress=20LSR=20associated=20with=20this=0A=20=20=20=20=20=20=20=20=20= =20=20=20tunnel=20instance."=0A=20=20=20=20=20::=3D=20{=20= mplsTunnelEntry=204=20}=0A=0A=0AThe=20TC=20from=20MPLS-TC-STD-MIB=20= (rfc3811)=20is:=0A=20=20=20=20=20=20MplsExtendedTunnelId=20::=3D=20= TEXTUAL-CONVENTION=0A=20=20=20=20=20=20=20=20=20STATUS=20=20=20=20=20=20=20= =20current=0A=20=20=20=20=20=20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20= =20=20=20=20=20"A=20unique=20identifier=20for=20an=20MPLS=20Tunnel.=20=20= This=20may=0A=20=20=20=20=20=20=20=20=20=20=20=20=20represent=20an=20= IPv4=20address=20of=20the=20ingress=20or=20egress=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20LSR=20for=20the=20tunnel.=20=20This=20value=20is=20= derived=20from=20the=0A=20=20=20=20=20=20=20=20=20=20=20=20=20Extended=20= Tunnel=20Id=20in=20RSVP=20or=20the=20Ingress=20Router=20ID=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20for=20CR-LDP."=0A=20=20=20=20=20=20=20=20=20= REFERENCE=0A=20=20=20=20=20=20=20=20=20=20=20=20"RSVP-TE:=20Extensions=20= to=20RSVP=20for=20LSP=20Tunnels,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= [RFC3209].=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20Constraint-Based=20= LSP=20Setup=20using=20LDP,=20[RFC3212]."=0A=20=20=20=20=20=20=20=20=20= SYNTAX=20=20Unsigned32(0..4294967295)=0A=0A=0ASo,=20while=20I=20agree=20= that=20mplsTunnelIngressLSRID=20and=20mplsTunnelEgressLSRId=0Aand=20= mplsNodeConfigLocalId=20are=20all=2032-bit=20values,=20=20the=20= following=202=20TCs=20are=20not=20semantically=20the=20same:=0A=0A=0A=20=20= =20=20=20=20MplsExtendedTunnelId=20::=3D=20TEXTUAL-CONVENTION=0A=20=20=20= =20=20=20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0A=20=20=20=20=20= =20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20=20=20"A=20= unique=20identifier=20for=20an=20MPLS=20Tunnel.=20=20This=20may=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20represent=20an=20IPv4=20address=20of=20the=20= ingress=20or=20egress=0A=20=20=20=20=20=20=20=20=20=20=20=20=20LSR=20for=20= the=20tunnel.=20=20This=20value=20is=20derived=20from=20the=0A=20=20=20=20= =20=20=20=20=20=20=20=20=20Extended=20Tunnel=20Id=20in=20RSVP=20or=20the=20= Ingress=20Router=20ID=0A=20=20=20=20=20=20=20=20=20=20=20=20=20for=20= CR-LDP."=0A=20=20=20=20=20=20=20=20=20REFERENCE=0A=20=20=20=20=20=20=20=20= =20=20=20=20"RSVP-TE:=20Extensions=20to=20RSVP=20for=20LSP=20Tunnels,=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20[RFC3209].=0A=0A=20=20=20=20=20=20=20= =20=20=20=20=20=20Constraint-Based=20LSP=20Setup=20using=20LDP,=20= [RFC3212]."=0A=20=20=20=20=20=20=20=20=20SYNTAX=20=20= Unsigned32(0..4294967295)=0A=0A=20=20=20=20=20MplsLocalId=20::=3D=20= TEXTUAL-CONVENTION=0A=20=20=20=20=20=20=20=20DISPLAY-HINT=20"d"=0A=20=20=20= =20=20=20=20=20STATUS=20=20=20=20=20=20current=0A=20=20=20=20=20=20=20=20= DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20"This=20textual=20convention=20= is=20used=20in=20accommodating=20the=20bigger=0A=20=20=20=20=20=20=20=20=20= =20=20size=20Global_Node_ID=20and/or=20ICC=20with=20lower=20size=20LSR=0A= =20=20=20=20=20=20=20=20=20=20=20identifier=20in=20order=20to=20index=20= the=20mplsTunnelTable.=0A=0A=20=20=20=20=20=20=20=20=20=20=20The=20Local=20= Identifier=20is=20configured=20between=201=20and=2016777215,=0A=20=20=20=20= =20=20=20=20=20=20=20as=20valid=20IP=20address=20range=20starts=20from=20= 16777216(01.00.00.00).=0A=20=20=20=20=20=20=20=20=20=20=20This=20range=20= is=20chosen=20to=20identify=20the=20mplsTunnelTable's=0A=20=20=20=20=20=20= =20=20=20=20=20Ingress/Egress=20LSR-id=20is=20IP=20address=20or=20Local=20= identifier,=0A=20=20=20=20=20=20=20=20=20=20=20if=20the=20configured=20= range=20is=20not=20IP=20address,=20administrator=20is=0A=20=20=20=20=20=20= =20=20=20=20=20expected=20to=20retrieve=20the=20complete=20information=0A= =20=20=20=20=20=20=20=20=20=20(Global_Node_ID=20or=20ICC)=20from=20= mplsNodeConfigTable.=20This=20way,=0A=20=20=20=20=20=20=20=20=20=20=20= existing=20mplsTunnelTable=20is=20reused=20for=20bidirectional=20tunnel=0A= =20=20=20=20=20=20=20=20=20=20=20extensions=20for=20MPLS=20based=20= transport=20networks.=0A=0A=20=20=20=20=20=20=20=20=20=20=20This=20Local=20= Identifier=20allows=20the=20administrator=20to=20assign=0A=20=20=20=20=20= =20=20=20=20=20=20a=20unique=20identifier=20to=20map=20Global_Node_ID=20= and/or=20ICC."=0A=20=20=20=20=20=20=20=20SYNTAX=20=20= Unsigned32(1..16777215)=0A=0ATherefore,=20I=20believe=20this=20is=20a=20= semantic=20redefinition=20and=20could=20potentially=20cause=0Aissues=20= for=20some=20legacy=20implementations.=0D=00=00Joan=20(MIB=20Dr)=84=00=00=0A= *)=20There=20were=20some=20warning=20generated=20by=20smiLint=20that=20= should=20probably=0Abe=20fixed=20(please=20see=20individual=20MIB=20= Modules=20discussion=20below.)[=00=00=0A*)=20MIB=20should=20be=20= capitalized=20consistently.=20=20Sometimes=20mib=20is=20used,=20so=0A= please=20use=20capitals.=FC=00=00*)=20There=20are=204=20MIB=20Modules=20= in=20this=20document=20which=20pertain=20to=0AMPLS-TP.=20=20The=20= proposal=20is=20to=20root=20them=20under=20mplsStdMIB.=0AThis=20has=20= not=20been=20the=20convention=20for=20sometime.=20=20However,=20if=20the=0A= authors=20feel=20strongly=20about=20using=20mplsStdMIB,=20then=20please=20= let=20me=0Aknow.=AE=00=00=0A*)=20The=20word=20"traps"=20appears=20as=20a=20= MIB=20comment=20in=20the=20MIB=20Modules.=20=20Please=20either=20remove=0A= the=20comment=20or=20use=20the=20notifications=20where=20appropriate.=20=20= Traps=20are=20a=20SNMPv1=0Amechanis<=00=20=20=00m.=AE=01=00=0A*)=20MIB=20= Guidelines=20suggest=20naming=20conventions=20to=20be=20used=0Awithin=20= a=20MIB=20Module=20(for=20tables,=20rows=20and=20objects=20within=20a=20= row),=0AThis=20was=20not=20followed=20in=20these=20MIB=20Modules.=20=20= As=20an=20example:=0A=0AMPLS-TE-EXT-STD-MIB=20has=20the=20following=20= table=20names:=0A=0AmplsNodeConfigTable=0AmplsNodeIpMapTable=0A= mplsNodeIccMapTable=0AmplsTunnelExtTable=0A=0AThis=20is=20also=20the=20= case=20in=20the=20other=20MIB=20Module(s).=20=20Please=20take=20a=20look=0A= at=20Appendix=20C=20of=20the=20MIB=20Guidelines=20(rfc4181).=AD=01=00Secti= on=204.=20Motivations=0A----------------------=0AAwkward.=20=20Section=20= doesn't=20specify=20motivations,=20expect=20something=0Alike,=20This=20= document=20provides=20a=20MIB=20Module=20which=20supports=0A= configuration=20of=20....=20and=20monitoring=20of=20....etc.=0A=0A=0A= Section=207.=20MIB=20Module=20Interdependencies=0A=0A=0AHow=20is=20this=20= possible,=20since=20MPLS-TE-STD-MIB=20was=20defined=20so=20long=20ago?=0A= =0A..=20=20=20=20=20=20=20=20-=20=20MPLS-TE-STD-MIB=20[RFC3812]=20= contains=20references=20to=20objects=20in=0A=20=20=20=20=20=20=20=20=20=20= MPLS-ID-STD-MIB.<=01=00=0AMPLS-TC-EXT-STD-MIB=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=0A=0A*)=20The=20name=20of=20this=20MIB=20Module=20is=20misleading.=0A= The=20TCs=20defined=20are=20specific=20to=20MPLS-TP=20so=20could=20this=20= name=0Abe=20more=20specific,=20for=20example,=20=20MPLS-TP-TC-STD-MIB=20= ?=0A=0A*)=20These=20TCs=20should=20have=20references.=20=20They=20are=0A= originally=20defined=20elsewhere,=20so=20why=20aren't=20their=20= references?U=00=00*)=20MplsNodeId=0A=0ADESCRIPTION=0A...LSR's=20/32=20= IPv4=20loopback=20address=0A=0AWhat=20is=20meant=20by=20/32=20= ?D=03=00MPLS-ID-STD-MIB=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0ASMILINT=0A-------=0A=0A= mibs/MPLS-ID-STD-MIB:70:=20[5]=20{identifier-external-case-match}=20= warning:=20identifier=20`mplsGlobalId'=20differs=20from=20= `MPLS-TC-EXT-STD-MIB::MplsGlobalId'=20only=20in=20case=0A= mibs/MPLS-TC-EXT-STD-MIB:61:=20[6]=20{previous-definition}=20info:=20= previous=20definition=20of=20`MplsGlobalId'=0Amibs/MPLS-ID-STD-MIB:94:=20= [5]=20{identifier-external-case-match}=20warning:=20identifier=20= `mplsNodeId'=20differs=20from=20`MPLS-TC-EXT-STD-MIB::MplsNodeId'=20only=20= in=20case=0Amibs/MPLS-TC-EXT-STD-MIB:88:=20[6]=20{previous-definition}=20= info:=20previous=20definition=20of=20`MplsNodeId'=0A=0A= mibs/MPLS-ID-STD-MIB:4:=20[5]=20{import-unused}=20warning:=20identifier=20= `NOTIFICATION-TYPE'=20imported=20from=20module=20`SNMPv2-SMI'=20is=20= never=20used=0Amibs/MPLS-ID-STD-MIB:6:=20[5]=20{import-unused}=20= warning:=20identifier=20`NOTIFICATION-GROUP'=20imported=20from=20module=20= `SNMPv2-CONF'=20is=20never=20used=E0=01=00MPLS-LSR-EXT-MIB=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A*)=20The=20= name=20of=20this=20MIB=20Module=20is=20too=20broad=20because=20MIB=20= Module=0Ais=20specific=20to=20MPLS-TP,=20so=20something=20like=20= MPLS-TP-LSR-EXT-MIB=0Awould=20be=20more=20appropriate=20IMHO.=0A=0A*)=20= Is=20mplsXCExtTunnelPointer=20supposed=20to=20be=20read-only?=0AThe=20= DESCRIPTION=20seems=20to=20indicate=20read-create?=0A(leads=20to=20= following=20question=20regarding=20compliance=20stmts....)=0A=0A=0A*)=20= The=20FullCompliance=20and=20ReadOnlyCompliance=0Aare=20confusing.=20=20= Why=20does=20the=20mplsXCExtTunnelPointer=20object=0Aappear=20in=20= both?=8B=03=00MPLS-TE-EXT-MIB=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A=0ASMILINT=0Amibs/MPLS-TE-EXT-STD-MIB:22:=20[4]=20= {module-identity-registration}=20warning:=20uncontrolled=20IETF=20module=20= identity=20registration=0Amibs/MPLS-TE-EXT-STD-MIB:4:=20[5]=20= {import-unused}=20warning:=20identifier=20`Unsigned32'=20imported=20from=20= module=20`SNMPv2-SMI'=20is=20never=20used=0Amibs/MPLS-TE-EXT-STD-MIB:5:=20= [5]=20{import-unused}=20warning:=20identifier=20`Gauge32'=20imported=20= from=20module=20`SNMPv2-SMI'=20is=20never=20used=0A= mibs/MPLS-TE-EXT-STD-MIB:5:=20[5]=20{import-unused}=20warning:=20= identifier=20`NOTIFICATION-TYPE'=20imported=20from=20module=20= `SNMPv2-SMI'=20is=20never=20used=0Amibs/MPLS-TE-EXT-STD-MIB:9:=20[5]=20= {import-unused}=20warning:=20identifier=20`NOTIFICATION-GROUP'=20= imported=20from=20module=20`SNMPv2-CONF'=20is=20never=20used=0A=0A=0A*)=20= Warnings=20of=20severity=20[5]=20should=20be=20fixed.=0A=0A=0A*)=20The=20= name=20of=20this=20MIB=20Module=20is=20too=20broad=20also.=20MIB=20is=20= specific=0Ato=20MPLS-TP=20and=20the=20name=20of=20the=20MIB=20Module=20= should=20reflect=20that.=0AOne=20example=20is,=20= MPLS-TP-TE-EXT-MIB..=07=00Unfortunately,=20my=20linux=20box=20is=20= giving=20me=20grief=20this=20week=20(and=20I=20don't=20have=20access=20= to=20my=20MIB=20tools).=20=20=20I'm=20getting=20some=20assistance=0A=0A= with=20it=20but=20won't=20be=20resolved=20until=20(hopefully)=20during=20= the=20weekend.=0A=0A=20=0A=0AHowever,=20I=20looked=20over=20the=20doc=20= and=20wanted=20to=20let=20you=20know=20that=20I=20still=20have=20the=20= same=20issue=20wrt=20to=20both=20SYNTAX=20and=20semantic=20=0A=0A= redefinition=20as=20before.=20=20=20You=20cannot=20narrow=20the=20range=20= of=20values=20in=20a=20DESCRIPTION=20clause=20which=20I=20see=20happens=20= in=20mplsTunnelExtNodeConfigLocalId=0A=0Aand=20maybe=20=20in=20= MplsNodeId=20TC=20as=20it=20says=20zero=20must=20not=20be=20used,=20but=20= then=20you=20have=20it=20as=20part=20of=20allowable=20values=20in=20the=20= SYNTAX.=0A=0A=20=0A=0AWhatever=20is=20specified=20in=20the=20DESCRIPTION=20= clause=20for=20values,=20should=20be=20reflected=20by=20the=20SYNTAX,=20= right?=0A=0A=20=0A=0AAdditionally,=20the=20SYNTAX=20below=20for=20= MplsExtendedTunnelId=20allows=20any=20Unsigned32=20and=20says=20"may=20= represent=20an=20IPv4=20address".=20=20=20=20If=20(for=20whatever=20= reason)=20an=0A=0Aoperator=20has=20configured=20something=20in=20the=20= 1..16777216=20(i.e.=20Local=20Id)=20range,=20for=20a=20regular=20TE=20= Tunnel,=20that=20is=20perfectly=20legal,=20right?=0A=0A=0A=20=0A=0A=20=0A= =0A=20MplsExtendedTunnelId=20::=3D=20TEXTUAL-CONVENTION=0A=20=20=20=20=20= =20=20=20=20=20STATUS=20=20=20=20=20=20=20=20current=0A=20=20=20=20=20=20= =20=20=20=20DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20=20=20=20"A=20= unique=20identifier=20for=20an=20MPLS=20Tunnel.=20=20This=20may=0A=20=20=20= =20=20=20=20=20=20=20=20=20=20=20represent=20an=20IPv4=20address=20of=20= the=20ingress=20or=20egress=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= LSR=20for=20the=20tunnel.=20=20This=20value=20is=20derived=20from=20the=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20Extended=20Tunnel=20Id=20in=20= RSVP=20or=20the=20Ingress=20Router=20ID=0A=20=20=20=20=20=20=20=20=20=20=20= =20=20=20for=20CR-LDP."=0A=20=20=20=20=20=20=20=20=20=20REFERENCE=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20"RSVP-TE:=20Extensions=20to=20RSVP=20= for=20LSP=20Tunnels,=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= [RFC3209].=0A=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Constraint-Based=20LSP=20Setup=20using=20LDP,=20[RFC3212]."=0A=20=20=20=20= =20=20=20=20=20=20SYNTAX=20=20Unsigned32(0..4294967295)=0A=0A=0A=20=0A=0A= If=20the=20answer=20is=20Yes,=20then=20how=20would=20you=20add=20TP=20= Tunnels=20using=20your=20draft=20if=20an=20operator=20has=20a=20regular=20= MPLS=20TE=20Tunnel=20configured=0A=0Ain=20the=20range=201..16777216=20= without=20having=20to=20ensure=20that=20any=20and=20all=20legacy=20= equipment=20be=20queried=20first?=20=20=20=B9=05=00The=20SMIv2=20= specifies=20that=20once=20a=20TC=20is=20defined,=20then=20the=20= definition=20cannot=20change=20in=20the=20way=20being=0Aproposed=20by=20= the=20draft-ietf-mpls-tp-te-mib-04.=0A=0A=46rom=20RFC2579:=0A3.3.=20=20= Mapping=20of=20the=20DESCRIPTION=20clause=0A=20The=20DESCRIPTION=20= clause,=20which=20must=20be=20present,=20contains=20a=20textual=0A=20=20= definition=20of=20the=20textual=20convention,=20which=20provides=20all=20= semantic=0A=20=20definitions=20necessary=20for=20implementation,=20and=20= should=20embody=20any=0A=20=20information=20which=20would=20otherwise=20= be=20communicated=20in=20any=20ASN.1=0A=20=20commentary=20annotations=20= associated=20with=20the=20object.=0A=0A=0AMy=20concern=20is=20that=20= MPLS-TC-STD-MIB=20defines=20MplsExtendedTunnelId=20and=20this=20draft=20= is=20changing=20that=20original=20definition.=0AIf=20RFC3811=20does=20= not=20contain=20"all=20semantic=20definitions=20necessary=20for=20= implementation"=20then=20the=20problem=20is=20to=20update=20RFC3811=0A= and=20maybe=20other=20associated=20RFCs=20as=20needed,=20not=20to=20= propose=20additional=20semantics=20in=20draft-ietf-mpls-tp-te-mib.=0A=0A= The=20draft=20is=20proposing=20to=20bifurcate=20the=20values=20and=20= also=20not=20use=20zero=20for=20the=20MplsExtendedTunnelId,=20that=20is=20= not=20the=20original=0Adefinition=20of=20MplsExtendedTunnelId,=20so=20= why=20is=20this=20draft=20using=20MplsExtendedTunnelId?=0A=0APlease=20= include=20the=20MIB=20Dr's=20on=20your=20email=20because=20this=20is=20a=20= MIB=20concern=20and=20one=20which=20I've=20had=20since=0Abefore=20this=20= draft=20was=20adopted=20as=20a=20WG=20document.=0A=0AThe=20options=20are=20= (as=20I=20see=20them):=0A1)=20create=20a=20specific=20MPLS=20TP=20table=20= for=20TP=20Tunnels=20(which=20was=20originally=20proposed=20by=20Adrian=20= Farrel)=0A2)=20update=20RFC3811=20to=20accurately=20reflect=20= MplsExtendedTunnelId=20and=20other=20RFCs=20which=20utilize=20this=20TC.=0A= 3)=20??c=06=00Thank=20you=20for=20adding=20the=20example=20to=20show=20= what=20happens=20wrt=20these=20MIB=20Modules=0A=0Awhen=20a=20MPLS=20TE=20= TP=20Tunnel=20is=20signaled,=20however,=20I=20think=20the=20example=20is=20= incomplete.=0A=0A=20=0A=0AThe=20example=20does=20not=20show=20how=20rows=20= are=20created=20in=20the=20mplsTunnelExtNodeConfigTable=0A=0Aor=20= mention=20that=20rows=20shoud=20be=20created=20in=20the=20mapping=20= tables,=20although=20the=20following=20snippet=0A=0Aof=20the=20example=20= in=20Section=209.3=20indicates=20that=20rows=20are=20created=20in=20= these=20tables:=0A=0A=20=0A=0A"--=20Local=20map=20number=20created=20in=20= mplsTunnelExtNodeConfigTable=20for=0A=20=20=20--=20Ingress=20LSR-Id=0A=20= =20=20=20=20mplsTunnelIngressLSRId=20=20=20=20=20=20=20=3D=201,=0A=0A=20=0A= =0A=20=20=20--=20Local=20map=20number=20created=20in=20= mplsTunnelExtNodeConfigTable=20for=0A=20=20=20--=20Egress=20LSR-Id=0A=20=20= =20=20=20mplsTunnelEgressLSRId=20=20=20=20=20=20=20=20=3D=202,"=0A=0A=20=0A= =0A=20=0A=0A=0AAdditionally,=20these=20are=20the=20same=20index=20values=20= used=20in=20the=20previous=20example=20and=20there=20is=20no=0A=0A= discussion=20on=20why=20these=20values=20were=20chosen.=20=20=20=20How=20= are=20these=20values=20chosen?=20=20=20What=20is=20the=0A=0Aalgorithm=20= or=20method=20for=20choosing=20these?=20=20=20If=20the=20local=20= management=20entity=20just=20picks=20the=20first=20available=0A=0A= indexes=20which=20are=20not=20already=20in=20the=20MplsTunnelTable,=20= then=20that=20should=20be=20stated.=20=20=20=20=0A=0A=20=0A=0ALooking=20= further=20in=20this=20example:=0A=0A=20=0A=0A=20=20=20=20= "mplsTunnelSignallingProto=20=20=20=20=3D=20none=20(1),"=0A=0A=20=0A=0A= Why=20is=20the=20signaling=20protocol=20marked=20as=20"none"?=20=20=20=20= =20=0A=0A=20=0A=0AThe=20MPLS=20RFCs=20which=20this=20draft=20references=20= (e.g.=20RFC3811,=20RFC6370)=20use=20the=20term=20"operator"=20rather=20= than=20"administrator".=0A=0APlease=20use=20the=20term=20"operator"=20to=20= be=20consistent=20with=20the=20RFCs.=0A=0A=20=0A=0AAlso,=20we<=00=20=20=00= =20have=20already=20discussed=20using=20the=20term=20"local=20management=20= entity"=20and=20not=20"implementor".=0A=0ALocal=20Management=20Entity=20= is=20appropos=20for=20a=20MIB.=20=20=20=20Please=20replace=20this=20in=20= the=20draft,=20particularly=20in=20the=0A=0AmplsExtTunnelTable=20= DESCRIPTIONS.=20=20=20=20=F3=09=00Since=20the=20example=20is=20= incomplete=20and=20the=20DESCRIPTION=20clauses=20related=20to=20the=0A= MplsExtendedTunnelId=20TC=20will=20change,=20I=20don't=20see=20the=20= point=20of=20reviewing=20and=20giving=20a=0Athumbs=20up/down.=20=20=20I=20= can't=20in=20good=20conscience=20ask=20other=20MIB=20Drs=0Afor=20their=20= guidance=20at=20this=20point=20because=20=20I=20feel=20like=20that=20= would=20be=20a=20waste=20of=20their=20time.=0A=0AAdditionally,=20not=20= all=20of=20the=20comments=20in=20the=20original=20review=20during=20LC=20= were=0Ataken=20into=20account=20--=20one=20is=20to=20change=20names=20to=20= contain=20"TP"=20since=20this=20MIB=0Adeals=20exclusively=20with=20= additions=20due=20to=20Transport=20Protocol.=20=20=20That=20was=20agreed=20= to=0Aby=20the=20authors=20and=20has=20not=20been=20done.=20=20It=20is=20= also=20in=20the=20MIB=20review=20guidelines=20as=20I=20have=0Apointed=20= out=20in=20a=20prior=20email.=20=20=20=20I=20haven't=20asked=20for=20= this=20again,=20because=20I=20just=0Awant=20the=20example=20and=20= wording=20to=20be=20correct,=20but=20my=20understanding=20of=20the=20= IETF=20process=0Ais=20that=20LC=20comments=20should=20be=20discussed,=20= agreed=20to,=20and=20incorporated.=20=20=20They=20have=0Abeen=20= discussed=20and=20the=20authors=20agree=20to=20incorporate=20this=20= change,=20but=20it=20has=20not=0Abeen=20done.=0A=0AAlso,=20there=20are=20= extremely=20few=20REFERENCE=20clauses=20(about=204=20or=205)=20and=0A= those=20that=20exist=20reference=20an=20entire=20Document=20where=20I=20= would=20expect=20to=20see=0Aa=20section=20or=20subsection=20referenced.=20= =20=20=20=20That=20doesn't=20make=20things=20easier=0Afor=20a=20reviewer=20= (or=20future=20readers)=20of=20this=20doc.=0A=0AAdditionally,=20there=20= were=20comments=20by=20another=20WG=20member=20=20(repeated=20here=20for=20= convience)=0Athat=20have=20not=20been=20updated=20but=20the=20authors=20= agreed=20to=20do=20so:=0A=0A"Subject:=20[mpls]=20Typos=20in=20= draft-ietf-mpls-tp-te-mib-04=0ADate:=20Tue,=2017=20Jul=202012=2010:47:32=20= +0000=0AFrom:=20Muly=20Ilan=20=0ATo:=20mpls@ietf.org=20= =0A=0A=0A=0AHi,=0A=0A1.Section=209.2.6=20should=20be=20= renamed=20to=20"Reverse=20direction=20mplsTunnelEntry"=0Ainstead=20of=20= "Forward=20direction=20mplsTunnelEntry".=0A=0A2.In=20section=209.2.10=20= change=20"mplsXCExtTunnelPointer=20=20=20=20=20=20=20=20=20=3D=0A= mplsTunnelName.1.1.1.2"=20to=20"mplsXCExtTunnelPointer=20=20=20=20=20=20=20= =20=20=3D=0AmplsTunnelName.2.1.2.1".=0A=0AMuly"=0A=0AI=20think=20Muly=20= is=20being=20kind,=20these=20aren't=20typos=20in=20my=20opinion,=20they=20= are=20fixes=20to=20mistakes.=0A=0AThese=20are=20just=20a=20few=20items=20= off=20the=20top=20of=20my=20head=20and=20not=20a=20complete=20list.=0A=0A= So,=20in=20truth,=20I=20haven't=20focused=20on=20all=20these=20other=20= updates=20that=20need=20to=20happen=20because=20I=0Ahave=20been=20= waiting=20for=20the=20wording=20and=20examples=20related=20to=20the=20= MplsExtendedTunnelId=0Ato=20become=20stable.=0A=0AI=20would=20like=20to=20= ask=20that=20one=20of=20you=20becomes=20editor=20for=20this=20document,=20= because=20all=20this=20back-n-forth=0Ais=20counterproductive.=20=20=20= Many=20of=20the=20requests=20by=20myself=20and=20others=20are=20just=20= falling=20to=20the=20wayside.=0AI=20would=20expect=20that=20an=20editor=20= is=20willing=20to=20keep=20a=20list=20of=20all=20the=20updates=20that=20= have=20been=20agreed=20to=20and=0Amake=20sure=20that=20these=20are=20= incorporated=20into=20the=20document.=05=00=00Fixed=06=00=00Edited3=00=00E= dited=20the=20MIB=20file=20with=20new=20text.=20Ready=20for=20= review=06=00=00Reason=A0=00=00This=20model=20was=20dervied=20due=20to=20= different=20vendors=20asking=20for=20different=20model.=20We=20want=20to=20= retain=20these=20two=20methods=20as=20there=20are=20already=20= implementations=20using=20them.=13=00=00Corrected=20the=20= error=F9=01=00Proposed=20the=20new=20solution=20without=20changing=20any=20= semantics.=20The=20defined=20range=20is=20applicable=20to=20the=20TP=20= tunnels=20as=20well.=20MIB=20suggests=20to=20use=20a=20non-IP=20address,=20= so,=20that=20it=20will=20not=20conflict=20with=20the=20legacy=20= implementation=20of=20the=20MIB.=20This=20is=20only=20a=20suggestion=20= and=20not=20mandated=20by=20the=20MIB.=20In=20order=20to=20identify=20= whether=20the=20MIB=20used=20local=20identifiers=20for=20Egress=20and=20= Ingress=20LSR=20ID,=20two=20new=20objects,=20= mplsTunnelExtIngressLSRLocalIdValid=20=20and=20= mplsTunnelExtEgressLSRLocalIdValid=20=20indicating=20the=20same,=20were=20= introduced.=11=00=00Changed=20the=20words=E5=00=00The=20reason=20we=20= chose=20this=20model=20is=20because=20the=20extensions=20by=20this=20MIB=20= are=20not=20just=20TP=20only,=20but=20could=20be=20used=20for=20other=20= MPLS=20tunnels=20as=20well.=20But=20if=20MIB=20doctors=20feel=20to=20= have=20this=20changed,=20please=20suggest=20and=20we=20would=20gladly=20= oblige.=06=00=00edited$=00=00Edited=20the=20content.=20Ready=20for=20= review=A1=00=00We=20initially=20had=20TP=20in=20the=20MIB=20definitions=20= but=20later=20removed=20due=20to=20comments=20from=20routing=20AD=20and=20= MPLS=20WG=20chair.=20Will=20forward=20their=20emails=20to=20clairify=20= the=20reason.=91=00=00We=20are=20getting=20the=20first=20waring=20even=20= for=20standard=20mib.=20Need=20help=20how=20to=20resolve.=20Regd=20the=20= name,=20we=20will=20refer=20to=20the=20comments=20of=20AD=20and=20WG=20= chair.=90=00=00We=20would=20like=20to=20re-use=20the=20existing=20MIB=20= itself=20as=20it=20suffice=20the=20need=20for=20MPLS-TP.=20New=20MIB=20= is=20pretty=20much=20redundant=20for=20all=20the=20common=20= objects.=06=00=00Status=18=00=00MIB=20DR's=20review=20= comments=04=00=00done=17=00=00Resolved=20compile=20issuesP=00=00We=20= removed=20the=20confusing=20text=20which=20specifies=20incorrect=20= range.=20Should=20be=20OK=20now.(=00=00With=20new=20text,=20it=20should=20= not=20be=20an=20issuei=00=00We=20fixed=20compile=20errors.=20One=20of=20= the=20warning=20we=20are=20getting=20even=20for=20standard=20MIB.=20Need=20= help=20in=20resolving.=AD=01=00We=20edited=20the=20text=20to=20resolve=20= the=20issues.=20In=20regards=20to=20REFERENCE=20clauses,=20do=20you=20= feel=20we=20need=20to=20add=20more.=20If=20so,=20could=20you=20please=20= provide=20guidance=20on=20where=20and=20all=20we=20should=20be=20adding?=20= A=20reference=20MIB=20RFC=20will=20help.=20Really=20appreciate=20that.=20= In=20regards=20to=20changing=20names=20to=20'TP',=20as=20detailed=20for=20= other=20comments,=20we=20removed=20having=20TP=20within=20the=20names,=20= upon=20comments=20from=20AD=20and=20WG=20chair.=20Details=20of=20= reasoing=20are=20within=20the=20emails.=BE=00=001)=20Naming....so=20I=20= am=20okay=20with=20not=20including=20TP=20as=20part=20of=20the=0AMIB=20= Module's=20name=20or=20Managed=20Objects.=20=20I=20think=20it=20may=20be=20= important=20to=0Aexplain=20why=20someplace=20(maybe=20in=20the=20= Terminology=20Section).=F7=00=002)=20Several=20places=20in=20this=20= draft,=20the=20MIB=20Module=20is=20referred=20to=0AMPLS-TP=20MIB,=20= please=20use=20the=20name=20of=20the=20MIB=20Module,=20especially=20= since=0Ayou=20have=20made=20a=20point=20that=20you=20don't=20want=20to=20= include=20the=20term,=20TP,=0Aas=20part=20of=20the=20MIB=20Module's=20= names=20or=20MO's=20names.=C4=00=003)=20In=20general=20need=20more=20= REFERENCES=20and=20more=20specific=20REFERENCES=20for=20TCs=20and=20=0A= OBJECTS.=20=20=20Specifying=20an=20entire=20RFC=20is=20not=20very=20= helpful.=20=20=0APlease=20be=20more=20specific=20and=20include=20a=20= section=20or=20subsection.W=02=005)=20Inconsistent=20use=20of=20RFC=20= names.=20=20For=20example=20in=20Section=203.2=0A"This=20document=20uses=20= terminology=20from=20the=20MPLS=20architecture=20document=0A[RFC3031],=20= MPLS=20Traffic=20Engineering=20Management=20information=20[RFC3812],=0A= MPLS=20Label=20Switch=20Router=20MIB=20[RFC3813]=20and=20MPLS-TP=20= Identifiers=20document=0A[RFC6370]."=0A=20=0ASometimes=20a=20very=20= informal=20name=20for=20document=20title,=20sometimes=20part=20of=0Aa=20= title=20and=20sometimes=20the=20full=20title.=20=20Please=20consistently=20= give=0Athe=20full=20title,=20so:=0AMPLS=20Label=20Switching=20= Architecture=20[RFC3031],=20=0AMPLS=20Label=20Switching=20(MPLS)=20Label=20= Switching=20Router=20(LSR)=20Management=0AInformation=20Base=20(MIB)=20= [RFC3812]=20and=20so=20forth.u=01=006)=20Similar=20to=20the=20above,=20= please=20reference=20MIB=20Modules=20by=20the=20=0AModule=20Name.=20=20= Someplaces=20do=20this,=20but=20some=20say=20MPLS=20Traffic=20= Engineering=20MIB=0Aor=20LSR=20MIB.=20=20Again,=20please=20just=20be=20= consistent.=0A=20=0AFor=20example:=0ASection=204.=20Motivations=0A=20=0A= As=20already=20mentioned=20in=20the=20above=20"General=20Issues=20= Section"=0APlease=20clarify,=20"as=20the=20existing=20MIB"=20to=20= something=20like=0A"as=20the=20existing=20= MPLS-TE-STD-MIB"=9D=00=00MPLS-ID-STD-MIB=0A=20=0A*)=20MODULE's=20= REVISION=20DESCRIPTION=0A=20=20=20=20=20=20=20=20=20=20"MPLS=20= identifiers=20MIB=20object=20extension"=0A=20=0AWhat=20does=20this=20= mean?=20=20What=20exactly=20is=20the=20'extension'?=E7=00=00*)=20Node_ID=20= is=20assigned=20within=20the=20scope=20of=20the=20Global_ID,=20so=20can=0A= Node_ID=20be=20derived=20from=20Global_ID=20?=20=20=20I'm=20wondering=20= if=20this=20does=20need=0Ato=20be=20read-write,=20or=20cannot=20it=20= just=20be=20read-only=20based=20on=20what=20an=0Aoperator=20assigns=20to=20= Global_ID?T=01=00*)=20There=20are=20only=203=20scalars=20in=20this=20MIB=20= Module=20and=20these=20are=20=0AIMPORTED=20into=20the=20MPLS-TE-EXT-MIB=20= Module,=20why=20are=20they=20not=20included=0Ain=20the=20= MPLS-TE-EXT-MIB?=20=20=20In=20other=20words,=20why=20is=20there=20a=20= separate=0AMIB=20Module=20for=20only=203=20scalars?=20=20(Certainly,=20= this=20is=20a=20design=20choice=0Aand=20I'm=20not=20saying=20this=20is=20= incorrect,=20but=20am=20wondering=20what=20the=20benefit=20= is?)=B3=02=00COMPILER=20OUTPUT=0A--------------------=0A=20=0A= MPLS-LSR-EXT-STD-MIB.my=0A=20=0ASMICNG=20PRO=0AE:=20= f(MPLS-LSR-EXT-STD-MIB.my),=20(195,10)=20Item=20"mplsInterfaceGroup"=20= should=20be=20IMPORTed=0AW:=20f(MPLS-LSR-EXT-STD-MIB.my),=20(209,18)=20= For=20"mplsXCExtTunnelPointer",=20syntax=20is=20identical=0AW:=20= f(MPLS-LSR-EXT-STD-MIB.my),=20(208,18)=20MIN-ACCESS=20value=20identical=20= to=20access=20specified=20for=20"mplsXCExtTunnelPointer"=0A=20=0A=0A= MPLS-TE-EXT-STD-MIB.my=0A=20=0ASMICNG=20PRO=0AE:=20= f(MPLS-TE-EXT-STD-MIB.my),=20(108,7)=20Row=20= "mplsTunnelExtNodeConfigEntry"=20may=20not=20have=20columns=20with=20= MAX-ACCESS=20of=20read-write=20if=20any=20column=20is=20read-create=0AE:=20= f(MPLS-TE-EXT-STD-MIB.my),=20(276,17)=20Index=20item=20= "mplsTunnelExtNodeIpMapNodeId"=20must=20be=20defined=20with=20syntax=20= that=20includes=20a=20range=0A=20{=00=00Global_ID=20and=20Node_ID=20= identifiers=20are=20common=20for=20Tunnels=20&=20PWs.=20So,=20keeping=20= these=20objects=20in=20a=20separate=20MIB=20is=20recommended<=00=C5=09= =00.s=00=00Node_ID=20is=20not=20derived=20from=20Global_ID,=20both=20are=20= different=20objects,=20we=20certainly=20need=20read-write=20object=20for=20= Node_ID.&=00=00Added=20text=20in=20the=20Introduction=20section)=00=00Edit= ed=20but=20need=20to=20check=20entire=20document.T=00=00Added=20the=20= RFC=20with=20section=20whereever=20possible,=20need=20to=20scan=20= through=20entire=20document.=17=00=00Kannan's=20comment=20to=20= Sam=04=00=00DoneY=02=00Its=20better=20to=20add=20the=20following=20= description=20for=20mplsTunnelExtOppositeDirPtr.=0A"Note=20that=20there=20= are=20two=20different=20ways=20to=20represent=20the=20Opposite=20= direction=20tunnel=20entry.=20One=20method=20is=20to=20use=20this=20= object=20'mplsTunnelExtOppositeDirPtr'=20as=20RowPointer=20and=20make=20= it=20point=20to=20the=20other=20tunnel.=20Other=20method=20is=20to=20use=20= the=20'mplsTunnelExtDestTnlIndex'=20and=20'mplsTunnelExtDestTnlLspIndex'=20= instead=20of=20using=20this=20mplsTunnelExtOppositeDirPtr.=20= Implemention=20can=20choose=20either=20one=20of=20the=20methods=20to=20= represent=20the=20opposite=20direction=20tunnel.=20Duplicate=20methods=20= are=20provided=20to=20provide=20easy=20ways=20for=20different=20= implementations".=05=00=00Done.B=00=00I=20assume=20that=20you=20have=20= run=20the=20same=20tool=20and=20corrected=20the=20errors.$=00=00No=20= change=20done.=20Reason=20give.=20Closed.C=00=00I=20searched=20the=20= word=20Trap=20in=20the=20file.=20Its=20not=20there.=20So,=20it=20= closed.2=00=00I=20verified=20that=20you=20have=20corrected=20the=20= names.=20Done?=00=00I=20verified=20that=20you=20have=20added=20= Motivations=20points=20clearly.=20Done=A8=00=00I=20guess=20you=20have=20= not=20done=20any=20name=20change.=20But,=20you=20have=20mentioned=20= "Edited"=20in=20the=20columnD.=20I=20guess=20you=20wanted=20to=20say=20= "Reason"=20or=20"Open".=20Please=20confirm=20and=20correct=20it.|=00=00I=20= assume=20that=20you=20have=20run=20the=20same=20tool=20and=20corrected=20= the=20errors=20that=20are=20not=20related=20to=20the=20already=20= existing=20standard=20MIB.=9B=00=00I=20see=20that=20you=20have=20added=20= required=20description=20and=20references=20to=20make=20it=20simple=20to=20= understand.=20They=20need=20to=20verify=20and=20confirm=20whether=20it=20= is=20OK.=20I=20am=20fine.=C2=00=00Done.=20I=20see=20that=20you=20have=20= added=20"This=20MIB=20module=20extends=20the=0A=0Aexisting=20MPLS=20MIB=20= objects=20for=20both=20MPLS-TP=20and=20Non-MPLS-TP=20operations,=0A=0Aso=20= the=20MPLS-TP=20name=20is=20not=20included=20in=20the=20MIB=20module=20= name."=B5=00=00I=20searched=20for=20"MPLS-TP=20MIB"=20in=20the=20doc=20= and=20found=20that,=20it=20is=20used=20only=20as=20the=20heading=20for=20= the=20document.=20No=20other=20place=20is=20referring=20this=20MIB=20as=20= MPLS-TP=20MIB.=20Hence,=20it=20should=20be=20OK.'=00=00I=20did=20a=20= quick=20scan.=20We=20are=20OK=20it=20seems.F=00=00I=20did=20a=20search=20= for=203812=20and=20found=20that=20you=20have=20given=20full=20names.=20= Donem=00=00I=20see=20that=20you=20have=20corrected=20it.=20Done.=20Any=20= reason=20for=20not=20filling=20the=20columnD,=20E,=20F=20in=20this=20xls=20= in=20this=20row?'=00=00I=20see=20that=20you=20have=20corrected=20it.=20= Done.'=00=00Nothing=20to=20change.=20Reason=20Given.=20ClosedA=00=00I=20= assume=20that=20you=20have=20run=20the=20tool=20to=20reconfirm=20the=20= errors.=20Done"=00=00Added=20this=20text=20in=20the=20draft.=20Done=0B= =00=00FinalStatus=FF=00Z=00=08=00=F20=00=00=0C=00=00=00W4=00=00q=03=00=00[= P=00=00u=1F=00=00=C1^=00=00=B7=0D=00=00_|=00=001=0B= =00=00=E4=80=00=00=B6=0F=00=00=CE=82=00=00=A0=11=00=00=DE=8B=00=00=B0=1A=00= =00z=92=00=00(=01=00=00=E6=95=00=00=94=04=00=00=E0=99=00=00=8E=08=00=00c=08= =16=00c=08=00=00=00=00=00=00=00=00=00=00=16=00=00=00=00=00=00=00=02=00=D6=08= =10=00=D6=08=00=00=00=00=00=00=00=00=00=00=02=00=00=00=96=08=99=0C= =96=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00PK=03=04=14=00=06=00=08=00= =00=00!=00=E9=DE=0F=BF=FF=00=00=00=1C=02=00=00=13=00=00=00[Content_Types].= xml=AC=91=CBN=C30=10E=F7H=FC=83=E5-J=9C=B2@=08%=E9=82=C7=8E=C7=A2|=C0=C8=99= $=16=C9=D8=B2=A7U=FB=F7L=D2TB=A8=20= =16l,=D93=F7=9E;=E3r=BD=1F=07=B5=C3=98=9C=A7J=AF=F2B+$=EB=1BG]=A5=DF7O=D9=AD= V=89=81=1A=18M=A0=08=8A=D4=AF=C0=9B=99=DD=F5N=91=9B= =B8=19DJ=A5=9B++2=84a,/=F3=94$=F0n=C4E=8C=15<=8A=F1=CAP=E0#=D0=1B=B3=95=D5= Je}%=C64=09P=82cP{g4=A2!A}=AD2=D8=CA=95w=18<&J=EA=81=90=89=9EVM=1C=09= =83=1D=1ET5BNe=9B=09t=88Y3=80y=86=FC=A8O=8EU=80=18=96=0A^4=83=8A=F9=0B= V=B6=AE=AE=E0=CDL=88=A9=05=B2%=B9=AE=F9=CB=E42=81=E1=C1=AA=99S=8C=07=C5=A4= =D5n=ADqe=A7=D0o=00L=CD=E3:=9DN=BBS-=F4=19=00=0EC=F0=D4=DAR=D6Y=EBnT[=B9=CE= =12=C8=FE=9C=D7=DD=AE=D4+5=17_=D2=BF6gs=A3=D5j=D5=1B=99-V=A9=01=D9=9F=B59=FC= Fe=BD=B6=BD=EA=E0=0D=C8=E2=EBs=F8Zk=BB=DD^w=F0=06d=F1=EBs=F8=EE=95=C6z=CD=C5= =1BP=C4hr0=87=D6=01=EDv3=ED=05d=C4=D9=0D/|=03=E0=1B=95=0C= >CA6=14=D9=A5=A7=18=F1D-=CA=B5=18?=E0=A2=0B=00=0DdX=D1=04=A9iJF8=84,n=E3x=20= (=D6=13=E0M=82Ko=ECP(=E7=86=F4\H=86=82=A6=AA=19=BC=9Fb=A8=88=99=BEW=CF=BF}= =F5=FC)z=F5=FC=C9=C9=C3g'=0F=7F8y=F4=E8=E4=E1=F7V=97#x=03'=E3=B2=E0=CB=AF?= =F9=FD=CB=0F=D1oO=BFz=F9=F83?^=96=F1?=7F=F7=D1O?~=EA=07B=05=CD,z=F1=F9=93_= =9E=3Dy=F1=C5=C7=BF~=F3=D8=03=DF=16xP=86=F7iL$=BAM=8E=D0>=8F=C17C=8Ck9=19=88= =F3I=F4#L=1D=09= =1C=81n=8F=EA=8E=8A=1C=E0=ED)f>\=8B=B8=E4=DD=13=D0<|=C0=EB=93=07=8E=AD=BDH= L=14=F5=CC|3=8A=1D=E0.=E7=AC=C5=85=97=80=9Bz=AE=12=C3=FDI2=F6O.&e=DC>=C6=87= =BE=B9=DB8qB=DB=99=A4=D05=F3=A4t=B8oG=C41s=8F=E1D=E11I=88B=FA=1D?=20= =C4=E3=DD}J=1D^wi(=B8=E4#=85=EES=D4=C2=D4KI=9F=0E=9CD=9A=09= =DD=A01=C4e=EA=F3=19B=EDp=B3{=0F=B58=F3y=BDC=0E]$=14=04f=1E=E3=FB=8494^=C7= =13=85c=9F=CA>=8EY=99=F0[XE>#{S=11=96q=1D=A9=20=D2c=C28=EA=0C= =89=94>=99;=02=FC-=05=FD&=86~=E5=0D=FB.=9B=C6.R(z=E0=D3y=0B= s^F=EE=F0=83v=84=E3=D4=87=ED=D1$*c=DF=93=07=90=A2=18=EDq=E5=83=EFr=B7B=F43= =C4=01'=0B=C3}=8F=12'=DCg7=82=BBt=EC=984K=10=FDf"<=B1=BCN=B8=93=BF=BD)=1Ba= b=BA=0C= =B4t=A7S=C74y]=DBf=14=FA=B6=9D=E1m=DBn=06=DB=B0=88=F9=8A=E7=C6=A9f=BD=08=F7= /l=D1;x=92=EC=11=A8=8A=F9%=EAm=87~=DB=A1=83=FF|=87^T=CB=17=DF=97g=AD=18=BA= =B4=DE=90=D8=BD=B6=D9y=C7=0B7=DE#=CAXOM=19=B9%=CD=DE[=C2=024=EC=C2=A0=963=87= NR=1C=C4=D2=08~=EAJ=86=09=1C=DCX`#=83=04W=1FP=15=F5"=9C=C2=BE=BD=1Ah%c=99=A9= =1EK=94r=09= =E7E3=EC=D5=AD=F1=B0=F7W=F6=B4Y=D7=E7=10=DB9$V=BB|h=87=D7=F4p~=DC(=D4=18=AB= =C6=E6L=9BO=B4=A6=15,;=D9=DA=95L)=F8=F6&=93U=B5QK=CFV5=A6=99=A6=E8=CCV=B8=AC= )6=E7r=A0=BCp=0D=06=0B6ag=83`?=04,=AF=C3=B1_O=0D=E7=1D=CC=C8P=F3nc=94=87=C5= D=E1=AF=09Q=E6=B5u$=C2CbC=E4=0C= =97=D8=AC=9A=D8=E5)4=E7=9Fv=CF=E6=C8=F9=D8,X=03=D2=CE6=C2=A4=C5=E2=FCY=92=E4= \=C1=8Cd=10<]M,)=D7=16K=D0Q3h=D4W=EB=01=0Aq=DA=0CFp=D2=85=9Fq=0A= A=93z/=88=D9=18=AE=8BB%l=D6=9EY=8B=A6Hg=1E7=FCYU=85=CB=8B=05=05=E3=94q*=A4= =DA=C12=B214=AF=B2P=B1D=CFd=ED_=AD=D7t=B2]=8C=03=9Ef=B2=9C=15k=1B=90"=FF=98= =15=10j7=B4d4"=A1*=07=BB4=A2=B9=B3=8FY'=E4=13ED/=1A=1E=A1=01=9B=88}=0C= =E1=07N=B5?C*=E1=C2=C2=14=B4~=80=DB5=CD=B6y=E5=F6=D6=AC=D3=94=EF=B4=0C= =CE=8Ec=96F8=EB=96=FAv&=AF8=0B= 7=FD=A4=B0=C1<=95=CC=03=DF=BC=B6=1B=E7=CE=EF=8A=AE=F8=8Br=A5=9C=C6=FF3W=F4= r=007=08kC=1D=81=10.w=05F=BAR=9A=01=17*=E2=D0=85=D2=88=86]=01=EB=BE=E9=1D=90= -pC=0B=AF=81|=B8b6=FF=0B= r=A8=FF=B75gu=98=B2=86=83=A0=DA=A7c$(,'*=12=84=ECA[2=D9w=86=B2j=B6=F4X=95,= Sd2=AAd=AEL=AD=D9=03rHX_=F7=C0u=DD=83=03=14A=AA=9Bn=92=B5=01=83;=9D=7F=EEs= VA=83=B1=DE=A3=94=EB=CD=E9d=C5=D2ik=E0=EF=DE=B8=D8b=06=A7N=ED%t=FE=E6=FC=17= &=16=AB=FBl=F5=B3=F2F<_#=CB=8E=E8=17=B3]R-=AF=0A= g=F1k4=B2=A9=DE=D0=84e=16=E0=D2Zk;=D6=9C=C7=AB=F5=DC8=88=E2=BC=C70X=ECgR=B8= =07B=FA=1FX=FF=A8=08=99=FD^=A1=17=D4>=DF=87=DE=8A=E0=F3=83=E5=0FAV_=D2]=0D= 2H7H=FBk=00=FB=1E;h=93I=AB=B2=D4f;=1F=CDZ=BEX_=F0F=B5=98=F7=14=D9=DA=B2e=E2= }N=B2=8BM=94;=9DS=8B=17Iv=C6=B0=C3=B5=1D[H5D=F6t=89=C2=D0(?=87=98=C0=98=0F= ]=E5oQ|=F0=00=02=BD=03=B7=FE=13f=BFN=C9=14=9EL=1D=A4{=C2d=D7=80=0F=A7=D9O&= =ED=82k=B3N=9Fa4=92%=FBd=84=E8=F08?=7F=14L=D8=12=B2_H=F2-=B2Ak1=9Dh=85=E0=9A= =EF=D0=E0=0Afx-jW=CBBx=F5l=E1B=C2=CC=0C= -=BB=106=17j>=05=F0},k=DC=FAh=07x=DBd=AD=D7=BA=B8r=A6X=F2g([=C2x?e=DE=93=CF= =B2=94=D9=83=E2k=03=F5=06=94=A9=E3=D7S=961=05=E4=CD'=1E|=E1=14=18=8E^=3D=D3= =7Fa=D1=B1=99nRv=EB=0F=00=00=00=FF=FF=03=00PK=03=04=14=00=06=00=08=00=00=00= !=00=0D=D1=90=9F=B6=00=00=00=1B=01=00=00'=00=00=00theme/theme/_rels/themeM= anager.xml.rels=84=8FM=0A=C20=14=84=F7=82w=08oo=D3=BA=10=91&=DD=88=D0=AD=D4= =03=84=E45=0D6?$Q=EC=ED=0D= =AE,=08.=87a=BE=99i=BB=97=9D=C9=13c2=DE1h=AA=1A=08:=E9=95q=9A=C1m=B8=EC=8E= @R=16N=89=D9;d=B0`=82=8Eo7=ED=15g=91K(M&$R(.1=98r=0E'J=93=9C=D0=8AT=F9=80=AE= 8=A3=8FV=E4"=A3=A6A=C8=BB=D0H=F7u}=A0=F1=9B=01|=C5$=BDb=10{=D5=00=19=96P=9A= =FF=B3=FD8=1A=89g/=1F=16]=FEQAs=D9=85=05(=A2=C6=CC=E0#=9B=AAL=04=CA[=BA=BA= =C4=DF=00=00=00=FF=FF=03=00PK=01=02-=00=14=00=06=00=08=00=00=00!=00=E9=DE=0F= =BF=FF=00=00=00=1C=02=00=00=13=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00[Content_Types].xmlPK=01=02-=00=14=00=06=00=08=00=00=00!=00=A5=D6=A7= =E7=C0=00=00=006=01=00=00=0B= =00=00=00=00=00=00=00=00=00=00=00=00=000=01=00=00_rels/.relsPK=01=02-=00=14= =00=06=00=08=00=00=00!=00ky=96=16=83=00=00=00=8A=00=00=00=1C=00=00=00=00=00= =00=00=00=00=00=00=00=00=19=02=00=00theme/theme/themeManager.xmlPK=01=02-=00= =14=00=06=00=08=00=00=00!=000=0F=88k=11=07=00=00=DE=1D=00=00=16=00=00=00=00= =00=00=00=00=00=00=00=00=00=D6=02=00=00theme/theme/theme1.xmlPK=01=02-=00=14= =00=06=00=08=00=00=00!=00=0D=D1=90=9F=B6=00=00=00=1B=01=00=00'=00=00=00=00= =00=00=00=00=00=00=00=00=00=1B=0A= =00=00theme/theme/_rels/themeManager.xml.relsPK=05=06=00=00=00=00=05=00=05= =00]=01=00=00=16=0B=00=00=00=00=9B=08=10=00=9B=08=00=00=00=00=00=00=00=00=00= =00=01=00=00=00=8C=08=10=00=8C=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =0A=00=00=00=09=08=10=00=00=06=10=00g2=CD=07=D9=00=03=00=06=06=00=00=0B= =02=18=00=00=00=00=00=00=00=00=00'=00=00=00=94=B4=00=00=0E=C3=00=00|=C4=00= =00=0D=00=02=00=01=00=0C= =00=02=00d=00=0F=00=02=00=01=00=11=00=02=00=00=00=10=00=08=00=FC=A9=F1=D2M= bP?_=00=02=00=01=00*=00=02=00=00=00+=00=02=00=00=00=82=00=02=00=01=00=80=00= =08=00=00=00=00=00=00=00=00=00%=02=04=00=00=00,=01=81=00=02=00=C1=04=14=00= =00=00=15=00=00=00=83=00=02=00=00=00=84=00=02=00=00=00&=00=08=00ffffff=E6?= '=00=08=00ffffff=E6?(=00=08=00=00=00=00=00=00=00=E8?)=00=08=00=00=00=00=00= =00=00=E8?M=00=06=0B=00=00C=00a=00n=00o=00n=00=20= =00L=00B=00P=003=003=000=000=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=01=04= =0A=03=DC=00(=0A=03=D7=01=00=01=00=01=00=EA=0A= o=08d=00=01=00=07=00X=02=01=00=01=00=00=00=01=00=01=00L=00e=00t=00t=00e=00= r=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =01=00=00=00=02=00=00=00=01=00=00=00=02=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00Canon=00=00=00=FC=08=00=00=00=00=00=00=00=01=00=00=01= =00=00=00=02=06=00=00=09=04=BC=03=00=C0=09=08G=00C=00a=00n=00o=00n=00=20= =00L=00B=00P=003=003=000=000=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =02=00=00=00=FF=07=00=00=EC=01=F9=00=00=00=01d=01=03=02=01=03=03=04=02=05=02= =06d=01=01=02=01=03=0F=04=10=05=06=00=07d=01=01=02=01=03=0F=04=10=05=06=00= =08=03=09=01=0A=01=0B=02=0C=02=0D=02=0E=02=0F=03=00=0Ad=01=01=02=02=03=02=04= =02=05=02=06=02=07=02=08=02=09d=01=03=02=02=03=02=04=01=00=0Ad=01=02=02=01= =03=01=04=01=05=0A=06d=01=07=02=07=03=07=04=02=05=08=20=00=00=00=0B= d=01=01=02=02=03=02=04=02=05=02=06=02=07=02=08=02=00=0C=0D=0D= d=01=03=02=02=04=02=05=02=06=02=07=01=00=0Ed=01=03=02=02=03=02=04=02=05=01= =06=04=80=07=04@=08=04@=00=0Fd=01=03=02=08=20=03=08=20=04d=01=07=02=07=03=07= =04=02=05=08=20=00=05=0A=06=0E=07=01=00=10d=01=03=02=02=03=01=04=01=05=01=06= =01=07=01=08=08=12=09=02=00=11d=01=01=00=12d=01=08=20= =00=13d=01=02=02=04"=00ed=01d=08=03=01=03=03=02=04=02=07=02=09=01=0B=02=0C= =02=0D=02=0E=02=0F=02=0Ad=01=02=02=02=03=02=00=10=03=11=03=12=02=13=02=14=02= =15=02=16=02=17d=01=02=02=02=03=02=00=18=02=19=01=1A=01=1B=01=1C=01=1D=02=1E= =02=1F=02=20=02!=02"=02#=02$=02%=01&=02'=02(=02)=02*=07=00=02d=01=03=02=02= =03=02=05=02=06=02=07=02=08=02=09=02=0A=02=0B=02=0C=02=0D= =01=0E=02=04=04"=0F=02=00=04d=04=03=05=06=06=02=07=02=09=02=0A=02=0B=02=0C= =02=0F=02=10=02=11=02=00=05d=01=03=02=02=03=02=04=02=05=02=06=02=07=02=08=02= =09=02=0A=06=14=0B=02=0C=06=0D=02=0E=02=00=06d=01=08!=02=08=11=00=07d=08=03= =00=09d=01=02=02=02=03=02=04=03=05=08!=06=03=07=02=08=02=09=02=0A=02=0B= =02=00=0Ad=01=02=02=02=03=08=10=04=08=10=00=08=03=0B=02=FF=FF=02=00=00@8=00= =20=01=00=00=00=04=00=00=00=01=00=01=00o=08=00=00=EA=0A=00=003=00=00=003=00= =00=00<=08=00=00=B7=0A=00=00=B2=9B=01=00=01=00o=08=00=00=EA=0A= =00=003=00=00=003=00=00=00<=08=00=00=B7=0A= =00=00=B2=9B=01=02=80=00X=02X=02=00=01=01=18=01=00=00=00d=00=00=00=00=00=00= =00=00=00=00=00=00=0F=002=00=01=01=00=01=00=01=00=00=00=00=00=0B= =00=00=00=00=00=00=00=90=01=00=00=00A=00r=00i=00a=00l=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=07=00= =01=00=00=01=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=02=01=00\CNZ005.= ICC=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=02=01=00\CNZ005.ICC= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=01=00\CNZ005.ICC=00= =00=00=00=00=00=00=00=02=01=01=01=01=02=02=00=00=01=00=00=00=09= =00=00=00=FF=FF=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=92=00=00=00C=00= O=00N=00F=00I=00D=00E=00N=00T=00I=00A=00L=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00C=00O=00N=00F=00I=00D=00E=00N=00T=00I=00A=00L=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00H=00=00=00=00=00=00=00=90=01=00=00=00A=00= r=00i=00a=00l=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=80=80=80=00=00=00=00=00=00=00=00=00=C2=01=00=00= =00=00=00=07=00=07=00=07=00=04=00=07=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=02= =00=00D=00e=00f=00a=00u=00l=00t=00=20= =00S=00e=00t=00t=00i=00n=00g=00s=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=02=00=00=00=00=00=00=00=00=0B=00=00=00=03=00=02=06=00=01=02=02= =01=02=80=00=00=00=00=00=01=0B= =03=00=01=01=02=02=01=07=00=07=00=07=00=07=00=03=03=03=03=03=03=03=03X=02=00= =00=03=03=00=00=00=00=00=10=00=00=02=01=00=00=00=00=00=00=00=00=FF=FF=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=01=00=00= =00=00=00=02=02=02=04=02=02=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=82=07=00=02=1B=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =A1=00"=00=01=00d=00=01=00=01=00=01=00=02=00X=02X=02333333=D3?333333=D3?=01= =00=9C=08&=00=9C=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00<3=00=00=00=00=00=00=00=00U=00=02=00=08=00}=00=0C= =00=00=00=00=00$=07?=00=02=00=00=00}=00=0C=00=01=00=01=00mS?=00=02=00=00=00= }=00=0C=00=02=00=02=00=00=0F?=00=02=00=00=00}=00=0C=00=03=00=03=00=B6=09= ?=00=06=00=00=00}=00=0C=00=04=00=04=00m=20?=00=02=00=00=00}=00=0C= =00=05=00=05=00=00&?=00=02=00=00=00}=00=0C=00=06=00=06=00=B6#>=00=02=00=00= =00}=00=0C=00=07=00=07=00=B6=0A?=00=02=00=00=00}=00=0C= =00=08=00=00=01=DB=08?=00=00=00=00=00=00=02=0E=00=00=00=00=00'=00=00=00=00= =00=08=00=00=00=08=02=10=00=00=00=00=00=08=00X=02=00=00=00=00=80=01A=00=08= =02=10=00=01=00=00=00=08=00=DC=05=00=00=00=00=00=01=0F=00=08=02=10=00=02=00= =00=00=08=00D=16=00=00=00=00=00=01=0F=00=08=02=10=00=03=00=00=00=08=00/=02= =00=00=00=00@=01=0F=00=08=02=10=00=04=00=00=00=08=00X=02=00=00=00=00=00=01= =0F=00=08=02=10=00=05=00=00=00=08=00=FE=1F=00=00=00=00=00=01=0F=00=08=02=10= =00=06=00=00=00=08=00=84=03=00=00=00=00=00=01=0F=00=08=02=10=00=07=00=00=00= =08=00=84=03=00=00=00=00=00=01=0F=00=08=02=10=00=08=00=00=00=08=00=08=07=00= =00=00=00=00=01=0F=00=08=02=10=00=09=00=00=00=08=00=B0=04=00=00=00=00=00=01= =0F=00=08=02=10=00=0A=00=00=00=08=00h=10=00=00=00=00=00=01=0F=00=08=02=10=00= =0B=00=00=00=08=00h=10=00=00=00=00=00=01=0F=00=08=02=10=00=0C=00=00=00=08=00= =B8=0B=00=00=00=00=00=01=0F=00=08=02=10=00=0D= =00=00=00=08=00=08=07=00=00=00=00=00=01=0F=00=08=02=10=00=0E=00=00=00=08=00= D=16=00=00=00=00=00=01=0F=00=08=02=10=00=0F=00=00=00=08=00=94=11=00=00=00=00= =00=01=0F=00=08=02=10=00=10=00=00=00=08=00=C8=19=00=00=00=00=00=01=0F=00=08= =02=10=00=11=00=00=00=08=00=FE=1F=00=00=00=00=00=01=0F=00=08=02=10=00=12=00= =00=00=08=00=FE=1F=00=00=00=00=00=01=0F=00=08=02=10=00=13=00=00=00=08=00=FE= =1F=00=00=00=00=00=01=0F=00=08=02=10=00=14=00=00=00=08=00=FE=1F=00=00=00=00= =00=01=0F=00=08=02=10=00=15=00=00=00=08=00=8C=0A= =00=00=00=00=00=01=0F=00=08=02=10=00=16=00=00=00=08=00=DC=05=00=00=00=00=00= =01=0F=00=08=02=10=00=17=00=00=00=08=00=84=03=00=00=00=00=00=01=0F=00=08=02= =10=00=18=00=00=00=08=00=10=0E=00=00=00=00=00=01=0F=00=08=02=10=00=19=00=00= =00=08=00=B8=0B= =00=00=00=00=00=01=0F=00=08=02=10=00=1A=00=00=00=08=00=08=07=00=00=00=00=00= =01=0F=00=08=02=10=00=1B=00=00=00=08=00=B0=04=00=00=00=00=00=01=0F=00=08=02= =10=00=1C=00=00=00=08=00=DC=05=00=00=00=00=00=01=0F=00=08=02=10=00=1D=00=00= =00=08=00=9C=18=00=00=00=00=00=01=0F=00=08=02=10=00=1E=00=00=00=08=00,=01=00= =00=00=00=00=01=0F=00=08=02=10=00=1F=00=00=00=08=00,=01=00=00=00=00=00=01=0F= =00=FD=00=0A=00=00=00=00=00@=00=00=00=00=00=FD=00=0A=00=00=00=01=00@=00=01= =00=00=00=FD=00=0A=00=00=00=02=00@=00=02=00=00=00=FD=00=0A=00=00=00=03=00@= =00*=00=00=00=FD=00=0A=00=00=00=04=00@=00+=00=00=00=FD=00=0A= =00=00=00=05=00B=00=03=00=00=00=FD=00=0A=00=00=00=06=00D=00@=00=00=00=FD=00= =0A=00=00=00=07=00A=00U=00=00=00~=02=0A=00=01=00=00=00>=00=00=00=F0?=FD=00= =0A=00=01=00=01=00>=00=05=00=00=00=FD=00=0A=00=01=00=02=00>=00=07=00=00=00= =FD=00=0A=00=01=00=03=00>=00=1D=00=00=00=01=02=06=00=01=00=04=00>=00=FD=00= =0A=00=01=00=05=00C=00=1E=00=00=00=FD=00=0A=00=01=00=06=00>=00A=00=00=00=FD= =00=0A=00=01=00=07=00?=00A=00=00=00~=02=0A=00=02=00=00=00>=00=00=00=00@=FD= =00=0A=00=02=00=01=00>=00=06=00=00=00=FD=00=0A=00=02=00=02=00>=00=07=00=00= =00=FD=00=0A=00=02=00=03=00>=00=1F=00=00=00=01=02=06=00=02=00=04=00>=00=FD= =00=0A=00=02=00=05=00C=00=20=00=00=00=FD=00=0A=00=02=00=06=00>=00B=00=00=00= =FD=00=0A=00=02=00=07=00?=00T=00=00=00~=02=0A=00=03=00=00=00>=00=00=00=08@= =FD=00=0A=00=03=00=01=00>=00=09=00=00=00=FD=00=0A=00=03=00=02=00>=00=08=00= =00=00=FD=00=0A=00=03=00=03=00>=00=1C=00=00=00=01=02=06=00=03=00=04=00>=00= =FD=00=0A=00=03=00=05=00C=00!=00=00=00=FD=00=0A=00=03=00=06=00>=00A=00=00=00= ~=02=0A=00=04=00=00=00>=00=00=00=10@=FD=00=0A=00=04=00=01=00>=00=0A=00=00=00= =FD=00=0A=00=04=00=02=00>=00=08=00=00=00=FD=00=0A=00=04=00=03=00>=00=1C=00= =00=00=01=02=06=00=04=00=04=00>=00=FD=00=0A=00=04=00=05=00C=00!=00=00=00=FD= =00=0A=00=04=00=06=00>=00A=00=00=00~=02=0A=00=05=00=00=00>=00=00=00=14@=FD= =00=0A=00=05=00=01=00>=00=0B=00=00=00=FD=00=0A=00=05=00=02=00>=00=0C= =00=00=00=FD=00=0A=00=05=00=03=00>=00=1D=00=00=00=01=02=06=00=05=00=04=00>= =00=FD=00=0A=00=05=00=05=00C=00"=00=00=00=FD=00=0A=00=05=00=06=00>=00C=00=00= =00~=02=0A=00=06=00=00=00>=00=00=00=18@=FD=00=0A=00=06=00=01=00>=00=0D= =00=00=00=FD=00=0A=00=06=00=02=00>=00=0C=00=00=00=FD=00=0A= =00=06=00=03=00>=00,=00=00=00=01=02=06=00=06=00=04=00>=00=FD=00=0A= =00=06=00=05=00C=00-=00=00=00=FD=00=0A=00=06=00=06=00>=00D=00=00=00~=02=0A= =00=07=00=00=00>=00=00=00=1C@=FD=00=0A=00=07=00=01=00>=00=0E=00=00=00=FD=00= =0A=00=07=00=02=00>=00=0C=00=00=00=FD=00=0A=00=07=00=03=00>=00=1D=00=00=00= =01=02=06=00=07=00=04=00>=00=FD=00=0A=00=07=00=05=00C=00#=00=00=00=FD=00=0A= =00=07=00=06=00>=00A=00=00=00~=02=0A=00=08=00=00=00>=00=00=00=20@=FD=00=0A= =00=08=00=01=00>=00=0F=00=00=00=FD=00=0A=00=08=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=08=00=03=00>=00=1F=00=00=00=01=02=06=00=08=00=04=00>=00=FD=00=0A= =00=08=00=05=00C=00$=00=00=00=FD=00=0A=00=08=00=06=00>=00E=00=00=00~=02=0A= =00=09=00=00=00>=00=00=00"@=FD=00=0A=00=09=00=01=00>=00=10=00=00=00=FD=00=0A= =00=09=00=02=00>=00=0C=00=00=00=FD=00=0A=00=09=00=03=00>=00=1D=00=00=00=01= =02=06=00=09=00=04=00>=00=FD=00=0A=00=09=00=05=00C=00!=00=00=00=FD=00=0A= =00=09=00=06=00>=00F=00=00=00~=02=0A=00=0A=00=00=00>=00=00=00$@=FD=00=0A= =00=0A=00=01=00>=00=11=00=00=00=FD=00=0A=00=0A=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=0A=00=03=00>=00=1D=00=00=00=01=02=06=00=0A=00=04=00>=00=FD=00=0A= =00=0A=00=05=00C=00!=00=00=00=FD=00=0A=00=0A=00=06=00>=00G=00=00=00~=02=0A= =00=0B=00=00=00>=00=00=00&@=FD=00=0A=00=0B=00=01=00>=00=12=00=00=00=FD=00=0A= =00=0B=00=02=00>=00=0C=00=00=00=FD=00=0A=00=0B=00=03=00>=00%=00=00=00=01=02= =06=00=0B=00=04=00>=00=FD=00=0A=00=0B=00=05=00C=00&=00=00=00=FD=00=0A=00=0B= =00=06=00>=00H=00=00=00~=02=0A=00=0C=00=00=00>=00=00=00(@=FD=00=0A=00=0C= =00=01=00>=00=13=00=00=00=FD=00=0A=00=0C=00=02=00>=00=0C=00=00=00=FD=00=0A= =00=0C=00=03=00>=00=1F=00=00=00=01=02=06=00=0C=00=04=00>=00=FD=00=0A=00=0C= =00=05=00C=00'=00=00=00=FD=00=0A=00=0C=00=06=00>=00I=00=00=00~=02=0A=00=0D= =00=00=00>=00=00=00*@=FD=00=0A=00=0D=00=01=00>=00=14=00=00=00=FD=00=0A=00=0D= =00=02=00>=00=0C=00=00=00=FD=00=0A=00=0D=00=03=00>=00=1D=00=00=00=01=02=06= =00=0D=00=04=00>=00=FD=00=0A=00=0D=00=05=00C=00!=00=00=00=FD=00=0A=00=0D= =00=06=00>=00A=00=00=00~=02=0A=00=0E=00=00=00>=00=00=00,@=FD=00=0A= =00=0E=00=01=00>=00=15=00=00=00=FD=00=0A=00=0E=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=0E=00=03=00>=00%=00=00=00=01=02=06=00=0E=00=04=00>=00=FD=00=0A= =00=0E=00=05=00C=000=00=00=00=FD=00=0A=00=0E=00=06=00>=00J=00=00=00~=02=0A= =00=0F=00=00=00>=00=00=00.@=FD=00=0A=00=0F=00=01=00>=00=16=00=00=00=FD=00=0A= =00=0F=00=02=00>=00=0C=00=00=00=FD=00=0A=00=0F=00=03=00>=00=1D=00=00=00=01= =02=06=00=0F=00=04=00>=00=FD=00=0A=00=0F=00=05=00C=00'=00=00=00=FD=00=0A= =00=0F=00=06=00>=00I=00=00=00~=02=0A=00=10=00=00=00>=00=00=000@=FD=00=0A= =00=10=00=01=00>=00=17=00=00=00=FD=00=0A=00=10=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=10=00=03=00>=00=04=00=00=00=01=02=06=00=10=00=04=00>=00=FD=00=0A= =00=10=00=05=00C=00(=00=00=00=FD=00=0A=00=10=00=06=00>=00J=00=00=00~=02=0A= =00=11=00=00=00>=00=00=001@=FD=00=0A=00=11=00=01=00>=00=18=00=00=00=FD=00=0A= =00=11=00=02=00>=00=0C=00=00=00=FD=00=0A=00=11=00=03=00>=00%=00=00=00=01=02= =06=00=11=00=04=00>=00=FD=00=0A=00=11=00=05=00C=00.=00=00=00=FD=00=0A= =00=11=00=06=00>=00A=00=00=00~=02=0A=00=12=00=00=00>=00=00=002@=FD=00=0A= =00=12=00=01=00>=00=19=00=00=00=FD=00=0A=00=12=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=12=00=03=00>=00=1D=00=00=00=01=02=06=00=12=00=04=00>=00=FD=00=0A= =00=12=00=05=00C=00)=00=00=00=FD=00=0A=00=12=00=06=00>=00A=00=00=00~=02=0A= =00=13=00=00=00>=00=00=003@=FD=00=0A=00=13=00=01=00>=00=1A=00=00=00=FD=00=0A= =00=13=00=02=00>=00=0C=00=00=00=FD=00=0A=00=13=00=03=00>=00=04=00=00=00=01= =02=06=00=13=00=04=00>=00=FD=00=0A=00=13=00=05=00C=00/=00=00=00=FD=00=0A= =00=13=00=06=00>=00A=00=00=00~=02=0A=00=14=00=00=00>=00=00=004@=FD=00=0A= =00=14=00=01=00>=00=1B=00=00=00=FD=00=0A=00=14=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=14=00=03=00>=00=04=00=00=00=01=02=06=00=14=00=04=00>=00=FD=00=0A= =00=14=00=05=00C=001=00=00=00=FD=00=0A=00=14=00=06=00>=00K=00=00=00~=02=0A= =00=15=00=00=00>=00=00=005@=FD=00=0A=00=15=00=01=00>=002=00=00=00=FD=00=0A= =00=15=00=02=00>=00=0C=00=00=00=FD=00=0A=00=15=00=03=00>=00=1D=00=00=00=01= =02=06=00=15=00=04=00>=00=FD=00=0A=00=15=00=05=00C=00=3D=00=00=00=FD=00=0A= =00=15=00=06=00>=00L=00=00=00~=02=0A=00=16=00=00=00>=00=00=006@=FD=00=0A= =00=16=00=01=00>=003=00=00=00=FD=00=0A=00=16=00=02=00>=00=0C=00=00=00=FD=00= =0A=00=16=00=03=00>=00=04=00=00=00=01=02=06=00=16=00=04=00>=00=FD=00=0A= =00=16=00=05=00C=00>=00=00=00=FD=00=0A=00=16=00=06=00>=00M=00=00=00~=02=0A= =00=17=00=00=00>=00=00=007@=FD=00=0A=00=17=00=01=00>=004=00=00=00=FD=00=0A= =00=17=00=02=00>=00=0C=00=00=00=FD=00=0A=00=17=00=03=00>=00=04=00=00=00=01= =02=06=00=17=00=04=00>=00=FD=00=0A=00=17=00=05=00C=00?=00=00=00=FD=00=0A= =00=17=00=06=00>=00N=00=00=00~=02=0A=00=18=00=00=00>=00=00=008@=FD=00=0A= =00=18=00=01=00>=005=00=00=00=FD=00=0A=00=18=00=02=00>=00=0C=00=00=00=FD=00= =0A=00=18=00=03=00>=00=1D=00=00=00=BE=00=0A=00=18=00=04=00>=00C=00=05=00=FD= =00=0A=00=18=00=06=00>=00O=00=00=00~=02=0A=00=19=00=00=00>=00=00=009@=FD=00= =0A=00=19=00=01=00>=006=00=00=00=FD=00=0A=00=19=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=19=00=03=00>=00=1D=00=00=00=BE=00=0A=00=19=00=04=00>=00C=00=05=00= =FD=00=0A=00=19=00=06=00>=00P=00=00=00=FD=00=0A=00=19=00=07=00?=00A=00=00=00= ~=02=0A=00=1A=00=00=00>=00=00=00:@=FD=00=0A=00=1A=00=01=00>=007=00=00=00=FD= =00=0A=00=1A=00=02=00>=00=0C=00=00=00=FD=00=0A=00=1A=00=03=00>=00=1D=00=00= =00=BE=00=0A=00=1A=00=04=00>=00C=00=05=00=FD=00=0A=00=1A=00=06=00>=00Q=00=00= =00~=02=0A=00=1B=00=00=00>=00=00=00;@=FD=00=0A=00=1B=00=01=00>=008=00=00=00= =FD=00=0A=00=1B=00=02=00>=00=0C=00=00=00=FD=00=0A=00=1B=00=03=00>=00=1F=00= =00=00=01=02=06=00=1B=00=04=00>=00=FD=00=0A=00=1B=00=05=00C=00<=00=00=00=FD= =00=0A=00=1B=00=06=00>=00R=00=00=00~=02=0A=00=1C=00=00=00>=00=00=00<@=FD=00= =0A=00=1C=00=01=00>=009=00=00=00=FD=00=0A=00=1C=00=02=00>=00=0C=00=00=00=FD= =00=0A=00=1C=00=03=00>=00=1F=00=00=00=01=02=06=00=1C=00=04=00>=00=FD=00=0A= =00=1C=00=05=00C=00;=00=00=00=FD=00=0A=00=1C=00=06=00>=00R=00=00=00~=02=0A= =00=1D=00=00=00>=00=00=00=3D@=FD=00=0A=00=1D=00=01=00>=00:=00=00=00=FD=00=0A= =00=1D=00=02=00>=00=0C=00=00=00=FD=00=0A=00=1D=00=03=00>=00=1D=00=00=00=BE= =00=0A=00=1D=00=04=00>=00C=00=05=00=FD=00=0A=00=1D=00=06=00>=00S=00=00=00=FD= =00=0A=00=1D=00=07=00?=00A=00=00=00=BE=00=12=00=1E=00=00=00>=00>=00>=00>=00= >=00C=00=05=00=BE=00=12=00=1F=00=00=00>=00>=00>=00>=00>=00C=00=05=00=D7=00= D=00=D2=0D= =00=00l=02p=00l=00l=00^=00^=00^=00^=00^=00^=00^=00^=00^=00^=00^=00^=00^=00= ^=00^=00^=00^=00^=00^=00^=00^=00T=00b=00T=00^=00^=00b=00=16=00=08=02=10=00= =20= =00=00=00=06=00,=01=00=00=00=00=00=01=0F=00=08=02=10=00!=00=00=00=06=00,=01= =00=00=00=00=00=01=0F=00=08=02=10=00"=00=00=00=06=00,=01=00=00=00=00=00=01= =0F=00=08=02=10=00#=00=00=00=06=00,=01=00=00=00=00=00=01=0F=00=08=02=10=00= $=00=00=00=06=00,=01=00=00=00=00=00=01=0F=00=08=02=10=00%=00=00=00=06=00,=01= =00=00=00=00=00=01=0F=00=08=02=10=00&=00=00=00=06=00,=01=00=00=00=00=00=01= =0F=00=BE=00=12=00=20= =00=00=00>=00>=00>=00>=00>=00C=00=05=00=BE=00=12=00!=00=00=00>=00>=00>=00>= =00>=00C=00=05=00=BE=00=12=00"=00=00=00>=00>=00>=00>=00>=00C=00=05=00=BE=00= =12=00#=00=00=00>=00>=00>=00>=00>=00C=00=05=00=BE=00=12=00$=00=00=00>=00>=00= >=00>=00>=00C=00=05=00=BE=00=12=00%=00=00=00>=00>=00>=00>=00>=00C=00=05=00= =BE=00=12=00&=00=00=00>=00>=00>=00>=00>=00C=00=05=00=D7=00=12=00&=01=00=00= x=00=16=00=16=00=16=00=16=00=16=00=16=00>=02=12=00=B4=06=00=00=02=00@=00=00= =00=00=00=00=00>=00=00=00=8B=08=10=00=8B=08=00=00=00=00=00=00=00=00=00=00=00= =00:=00=1D=00=0F=00=03=02=00=06=00=00=00=01=00=02=00=02=00=06=06=99=00=02=00= =DB=08g=08=17=00g=08=00=00=00=00=00=00=00=00=00=00=02=00=01=FF=FF=FF=FF=03= D=00=00=C8=08=11=00=C8=08=00=00=00=00@=00=00=00=00=00=08=00=00=00=00=0A= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =FE=FF=00=00=06=01=02=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=01= =00=00=00=E0=85=9F=F2=F9Oh=10=AB=91=08=00+'=B3=D90=00=00=00=C0=00=00=00=07= =00=00=00=01=00=00=00@=00=00=00=04=00=00=00H=00=00=00=08=00=00=00\=00=00=00= =12=00=00=00|=00=00=00=0C=00=00=00=A0=00=00=00=0D= =00=00=00=AC=00=00=00=13=00=00=00=B8=00=00=00=02=00=00=00=E4=04=00=00=1E=00= =00=00=0C=00=00=00vmahalingam=00=1E=00=00=00=18=00=00=00Mahalinga,=20= Venkatesan=00=00=00=1E=00=00=00=1C=00=00=00Microsoft=20Macintosh=20= Excel=00=00=00@=00=00=00=00:=0C= =7F\=8C=CD=01@=00=00=00=00=F8=CC=D2=E7=F1=CD=01=03=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=FE=FF=00=00=06=01=02=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=02=00=00=00=02=D5=CD=D5=9C.=1B=10=93=97=08=00+,=F9=AED=00=00=00= =05=D5=CD=D5=9C.=1B=10=93=97=08=00+,=F9=AE=20=01=00=00=DC=00=00=00=09= =00=00=00=01=00=00=00P=00=00=00=0F=00=00=00X=00=00=00=17=00=00=00t=00=00=00= =0B=00=00=00|=00=00=00=10=00=00=00=84=00=00=00=13=00=00=00=8C=00=00=00=16=00= =00=00=94=00=00=00=0D=00=00=00=9C=00=00=00=0C= =00=00=00=B7=00=00=00=02=00=00=00=E4=04=00=00=1E=00=00=00=14=00=00=00Force= 10=20Networks=00=00=00=00=03=00=00=00=00=00=0E=00=0B=00=00=00=00=00=00=00=0B= =00=00=00=00=00=00=00=0B=00=00=00=00=00=00=00=0B= =00=00=00=00=00=00=00=1E=10=00=00=01=00=00=00=0F=00=00=00TP-TE-Comments=00= =0C=10=00=00=02=00=00=00=1E=00=00=00=0B= =00=00=00Worksheets=00=03=00=00=00=01=00=00=00=00=00P=00=00=00=03=00=00=00= =00=00=00=00=20=00=00=00=01=00=00=002=00=00=00=02=00=00=00:=00=00=00=01=00= =00=00=02=00=00=00=06=00=00=00sflag=00=02=00=00=00=E4=04=00=00=1E=00=00=00= =0C= =00=00=001347656033=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=01=00=00=00=02=00=00=00=03=00=00=00= =04=00=00=00=05=00=00=00=06=00=00=00=07=00=00=00=08=00=00=00=09=00=00=00=0A= =00=00=00=0B=00=00=00=0C=00=00=00=0D= =00=00=00=0E=00=00=00=0F=00=00=00=10=00=00=00=11=00=00=00=12=00=00=00=13=00= =00=00=14=00=00=00=15=00=00=00=16=00=00=00=17=00=00=00=18=00=00=00=19=00=00= =00=1A=00=00=00=1B=00=00=00=1C=00=00=00=1D=00=00=00=1E=00=00=00=1F=00=00=00= =20= =00=00=00!=00=00=00"=00=00=00#=00=00=00$=00=00=00%=00=00=00&=00=00=00'=00=00= =00(=00=00=00)=00=00=00*=00=00=00+=00=00=00,=00=00=00-=00=00=00.=00=00=00/= =00=00=000=00=00=001=00=00=002=00=00=003=00=00=004=00=00=005=00=00=006=00=00= =007=00=00=008=00=00=009=00=00=00:=00=00=00;=00=00=00<=00=00=00=3D=00=00=00= >=00=00=00?=00=00=00@=00=00=00A=00=00=00B=00=00=00C=00=00=00D=00=00=00E=00= =00=00F=00=00=00G=00=00=00H=00=00=00I=00=00=00J=00=00=00K=00=00=00L=00=00=00= M=00=00=00N=00=00=00O=00=00=00P=00=00=00Q=00=00=00R=00=00=00S=00=00=00T=00= =00=00U=00=00=00V=00=00=00W=00=00=00X=00=00=00Y=00=00=00Z=00=00=00[=00=00=00= \=00=00=00]=00=00=00^=00=00=00_=00=00=00`=00=00=00a=00=00=00b=00=00=00=FE=FF= =FF=FFd=00=00=00e=00=00=00f=00=00=00g=00=00=00h=00=00=00i=00=00=00j=00=00=00= =FE=FF=FF=FFl=00=00=00m=00=00=00n=00=00=00o=00=00=00p=00=00=00q=00=00=00r=00= =00=00=FE=FF=FF=FF=FD=FF=FF=FF=FE=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FFR=00o=00o=00t=00=20= =00E=00n=00t=00r=00y=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=16=00=05=01=FF=FF=FF=FF=FF=FF=FF=FF=02=00=00=00=20= =08=02=00=00=00=00=00=C0=00=00=00=00=00=00F=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=FE=FF=FF=FF=00=00=00=00=00=00=00=00W=00o=00r=00= k=00b=00o=00o=00k=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=12=00=02=01=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=09= =C5=00=00=00=00=00=00=05=00S=00u=00m=00m=00a=00r=00y=00I=00n=00f=00o=00r=00= m=00a=00t=00i=00o=00n=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00(=00=02=01=01=00=00=00=03=00=00=00=FF=FF=FF=FF=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00c=00=00=00=00=10=00=00=00=00=00=00=05=00D=00= o=00c=00u=00m=00e=00n=00t=00S=00u=00m=00m=00a=00r=00y=00I=00n=00f=00o=00r=00= m=00a=00t=00i=00o=00n=00=00=00=00=00=00=00=00=00=00=008=00=02=01=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00k=00=00=00=00=10=00= =00=00=00=00=00= --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_BABEEDA7-3B35-41BB-AA92-346C955873C3-- From j.schoenwaelder@jacobs-university.de Mon Jan 14 08:45:35 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07D821F86C8; Mon, 14 Jan 2013 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RqTdTdchwrak; Mon, 14 Jan 2013 08:45:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B630C21F8546; Mon, 14 Jan 2013 08:45:33 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A4C320BEC; Mon, 14 Jan 2013 17:45:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1wvrotM8gZWf; Mon, 14 Jan 2013 17:45:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A068B20BE0; Mon, 14 Jan 2013 17:45:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D6BF323F6085; Mon, 14 Jan 2013 17:45:33 +0100 (CET) Date: Mon, 14 Jan 2013 17:45:33 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130114164533.GB19548@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:45:35 -0000 On Mon, Jan 14, 2013 at 04:05:21PM +0000, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > Thanks for the detailed review. > > Please see in-line the responses and proposals for update. > > For a couple of points I am waiting for answers from Mouli. > > Please let us know if the proposed resolutions answer your concerns. I will only respond to those issues where we either disagree or where further clarification may be necessary. > > d) Section 2 provides a high-level overview over the changes of > > ENTITY-MIB version 2 and 3. There is unfortunately no such text for > > the version 4. > > > [[DR]] Proposed Solution: > > Add at the end of Section 2 the following text: > > Version 3 of this MIB addresses new requirements, which have emerged > since the publication of the third Entity MIB (RFC 4133 [RFC4133]). > There is a need to add new enumerated values for physical classes, a > need to provide identification information for entity objects in > a Universal Unique Identifier (UUID) formats, and a need to describe > Constrained Resources (CR) entities. The PhysicalClass Textual > Convention (TC) was deprecated and a new IANAPhysicalClass TC was > created. A new TC UUIDorZero was created to represent a UUID and a > new object was added to the entPhysicalTable to identify the UUID. I am not sure the "need to describe Constrained Resources (CR) entities" explains it well. Perhaps there is a "need for conformance statements for Constrained Resources (CR) entities" or something like that. > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > method of context identification"? For example, "an SnmpEngineID > > and ContextName pair [RFC3411] for context identification". > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a bug I suggest to avoid such changes. It is document clarity. But I won't insist on this, I just find the current text unnecessarily confusing. > > g) Overall, replace MIBs with MIB modules. > > > [[DR]] Same as the previous point. Again, it is document clarity. It is rather obvious that this change does not break anything, no? Let Bert decide - he is the owner of the one MIB many MIB modules song. ;-) > > k) RFC 4122 is listed both as normative and informative. I think it is > > normative, no? > > > > [[DR]] yes. So I assume you will remove the informative reference, right? > > m) Since this document obsoletes older ENTITY-MIB definitions, are the > > old definitions still normative references? I would expect not. Note > > that the document header also does not state that this document > > obsoletes RFC 4133 - only the abstract does. > > [[DR]] The header should be updated. And the references to the old revisions will become informative, right? > > n) The description of revision 201212110000Z of the ENTITY-MIB has an > > incomplete sentence... And there is no point in changing previous > > revision statements (in particular revision 200508100000Z). This > > also needs to be reverted back. > > [[DR]] OK. Actually the 2012... revision will not be mentioned any longer. Yes, but there will be a 2013... revision. > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed to > > Uri imported from the URI-TC-MIB. Is is _not_ a backwards compatible > > change since entPhysicalUris used to contain a whitespace separated > > list of URIs. Interestingly, this change is not mentioned anywhere > > in the changes text. As this change is not compatible, you have to > > revert it back. > [[DR]] It's the first time this comment is made (as a few other as well). Sure, if the change is not backwards compatible, this needs to be reversed. Yes, apparently the level of review this MIB module enjoyed has not been very extensive. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Jan 15 05:07:35 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAA721F86FD; Tue, 15 Jan 2013 05:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 rL2j8e3xFVTf; Tue, 15 Jan 2013 05:07:34 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB521F86D4; Tue, 15 Jan 2013 05:07:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAIbQt1CHCzI1/2dsb2JhbAA6BwOBf221TodLFnOCHgEBAQECARIoPwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgTB4doBgGiBoxpkCMEjDwRgQSCS2EDlx2EcYo3gnKCIQ X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="384496367" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2013 07:57:49 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Jan 2013 07:42:09 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 08:07:43 -0500 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j1HkH9GpL6Iw0undeMeNNuIRZhI4EuAgAB8L4CAAQBy8A== Date: Tue, 15 Jan 2013 13:07:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> In-Reply-To: <20130114164533.GB19548@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:07:35 -0000 See in-line.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 6:46 PM > To: Romascanu, Dan (Dan) > Cc: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org; > ops-ads@tools.ietf.org; eman@ietf.org > Subject: Re: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 > On Mon, Jan 14, 2013 at 04:05:21PM +0000, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > > > Thanks for the detailed review. > > > > Please see in-line the responses and proposals for update. > > > > For a couple of points I am waiting for answers from Mouli. > > > > Please let us know if the proposed resolutions answer your concerns. >=20 > I will only respond to those issues where we either disagree or where > further clarification may be necessary. >=20 > > > d) Section 2 provides a high-level overview over the changes of > > > ENTITY-MIB version 2 and 3. There is unfortunately no such text > for > > > the version 4. > > > > > [[DR]] Proposed Solution: > > > > Add at the end of Section 2 the following text: > > > > Version 3 of this MIB addresses new requirements, which have > emerged > > since the publication of the third Entity MIB (RFC 4133 [RFC4133]). > > There is a need to add new enumerated values for physical classes, > a > > need to provide identification information for entity objects in > > a Universal Unique Identifier (UUID) formats, and a need to > describe > > Constrained Resources (CR) entities. The PhysicalClass Textual > > Convention (TC) was deprecated and a new IANAPhysicalClass TC was > > created. A new TC UUIDorZero was created to represent a UUID and a > > new object was added to the entPhysicalTable to identify the UUID. >=20 > I am not sure the "need to describe Constrained Resources (CR) entities" > explains it well. Perhaps there is a "need for conformance statements > for Constrained Resources (CR) entities" or something like that. >=20 [[DR]] OK.=20 > > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > > method of context identification"? For example, "an SnmpEngineID > > > and ContextName pair [RFC3411] for context identification". > > > > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a > bug I suggest to avoid such changes. >=20 > It is document clarity. But I won't insist on this, I just find the > current text unnecessarily confusing. >=20 > > > g) Overall, replace MIBs with MIB modules. > > > > > [[DR]] Same as the previous point. >=20 > Again, it is document clarity. It is rather obvious that this change > does not break anything, no? Let Bert decide - he is the owner of the > one MIB many MIB modules song. ;-) >=20 [[DR]] I also sing the song when I review new documents, but in this case w= e would interfere in the text of the document that is now at version 4.=20 > > > k) RFC 4122 is listed both as normative and informative. I think it > is > > > normative, no? > > > > > > > [[DR]] yes. >=20 > So I assume you will remove the informative reference, right? >=20 [[DR]] Right. > > > m) Since this document obsoletes older ENTITY-MIB definitions, are > the > > > old definitions still normative references? I would expect not. > Note > > > that the document header also does not state that this document > > > obsoletes RFC 4133 - only the abstract does. > > > > [[DR]] The header should be updated. >=20 > And the references to the old revisions will become informative, right? >=20 [[DR]] Right. > > > n) The description of revision 201212110000Z of the ENTITY-MIB has > an > > > incomplete sentence... And there is no point in changing previous > > > revision statements (in particular revision 200508100000Z). This > > > also needs to be reverted back. > > > > [[DR]] OK. Actually the 2012... revision will not be mentioned any > longer. >=20 > Yes, but there will be a 2013... revision. >=20 [[DR]] of course :-) > > > o) In the ENTITY-MIB, the syntax of entPhysicalUris has been changed > to > > > Uri imported from the URI-TC-MIB. Is is _not_ a backwards > compatible > > > change since entPhysicalUris used to contain a whitespace > separated > > > list of URIs. Interestingly, this change is not mentioned > anywhere > > > in the changes text. As this change is not compatible, you have > to > > > revert it back. > > [[DR]] It's the first time this comment is made (as a few other as > well). Sure, if the change is not backwards compatible, this needs to be > reversed. >=20 > Yes, apparently the level of review this MIB module enjoyed has not been > very extensive. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From moulchan@cisco.com Tue Jan 15 05:09:54 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F7521F8783; Tue, 15 Jan 2013 05:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 60aKFlhb6u1H; Tue, 15 Jan 2013 05:09:50 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A8C4821F86AA; Tue, 15 Jan 2013 05:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3741; q=dns/txt; s=iport; t=1358255390; x=1359464990; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7MzupuMFk6xAIErFtllXq3/IISj7lcX4fB5qRXl0ysY=; b=IS+55mDl7/Iej/EWbEDSlvUY1TXwixjKtPtFNSWpoULCbZBkAbvucWax xkEneV7zvWubNAvM0mvD2GZDuOEKx4/7hMDR4uahCJ++IBt394L94LPju clrck0rrX6iGefOE9yE/zIQGC7ZXHiVLAid+AdEThU8nElxKzv5+pK2T7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAEpU9VCtJXG+/2dsb2JhbABCA7YNhC6DRxZzgh4BAQEDAQEBATc0CwUHAgICAQgQAQQBAQsUCQcbDAsUCQgCBAENBQiICwYMqEGOTASOBoJNYQOXKI8tgnWCJA X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="162554752" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 15 Jan 2013 13:09:50 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0FD9oBb031488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 13:09:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.232]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 07:09:49 -0600 From: "Mouli Chandramouli (moulchan)" To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Thread-Topic: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN8j09YUnlfJCpFUmUM5SweCXWsZhJYgOAgADkw0A= Date: Tue, 15 Jan 2013 13:09:49 +0000 Message-ID: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ops-ads@tools.ietf.org" , "eman@ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:09:54 -0000 Hello Juergen,=20 Thanks for the review. Replies inline.=20 Regards Mouli -----Original Message----- From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: Monday, January 14, 2013 9:35 PM To: Juergen Schoenwaelder; mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis= @tools.ietf.org Cc: eman@ietf.org; ops-ads@tools.ietf.org Subject: Re: [eman] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Hi Juergen,=20 Thanks for the detailed review.=20 Please see in-line the responses and proposals for update.=20 For a couple of points I am waiting for answers from Mouli.=20 Please let us know if the proposed resolutions answer your concerns. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 14, 2013 11:55 AM > To: mib-doctors@ietf.org; draft-ietf-eman-rfc4133bis@tools.ietf.org > Cc: ops-ads@tools.ietf.org; eman@ietf.org > Subject: mib doctor review of draft-ietf-eman-rfc4133bis-05.txt >=20 [ycm] snip ...=20 > e) I think a paragraph should be added to section 2.12.1 to describe > the addition made by version 4 - and if it is just for document > consistency. >=20 > Version 4 of the Entity MIB provides [...] >=20 > This would also be a good place to explain whether UUIDs are > supposed to also be represented as URIs (and why or why not). >=20 [[DR]] I will let Mouli address this, as I am not sure 100% about the respo= nse to the issue of representation.=20 [ycm]=20 [ycm] Thanks for the comment. To be consistent, we shall add the following = paragraph on in Section 2.12.1.=20 NEW=20 =20 Version 4 of the Entity MIB provides an additional MIB object for each phy= sical entity.=20 entPhysicalUUID - This object provides an additional unique identification = about the physical entity. =20 This object contains a globally unique identifier for the physical entity w= ith the format as defined in RFC 4122 [RFC4122].=20 The UUID shall be represented as URIs.=20 To support the existing implementations of ENTITY-MIB v3, entPhyiscalUris = object which uses the URI syntax can=20 be used to store the UUID value of the physical entity. Caution should to b= e exercised since this MIB object is read-write. =20 With the implementation of ENTITY-MIB v4, the value of UUID can be stored i= n new MIB object entPhysicalUUID (which is read-only)=20 and the UUID value can also be duplicated in entPhysicalUris MIB object. To= enable this capability, the syntax of the=20 two MIB objects should be similar.=20 [ycm]=20 > j) The EMAN example (section 4.3) is full of Cisco details, I think it > is more suitable to follow the vendor neutral ACME style of the other > examples. Furthermore, it appears to me that the UUID values shown > are not RFC 4122 UUID values. :-( And what is an _MSC_ card? Please > avoid all vendor specific terms. The indexing of the line card slot > in the example also seems to be all messed up. And should the line > card slot not be contained in the chassis? >=20 [[DR]] Mouli - can you please look at these?=20 [ycm] I will remove the reference to Cisco terns and use a generic name as= ACME and also the 128 bit UUID values in the URI representation.=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman From j.schoenwaelder@jacobs-university.de Tue Jan 15 06:09:09 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA921F87C8; Tue, 15 Jan 2013 06:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 kAHHz0lxh2di; Tue, 15 Jan 2013 06:09:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1476B21F8798; Tue, 15 Jan 2013 06:09:08 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C63420BF8; Tue, 15 Jan 2013 15:09:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n3BdAq9ocZJo; Tue, 15 Jan 2013 15:09:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28B3E20BF0; Tue, 15 Jan 2013 15:09:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7584523F7CC8; Tue, 15 Jan 2013 15:09:08 +0100 (CET) Date: Tue, 15 Jan 2013 15:09:07 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130115140907.GA21588@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mib-doctors@ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:09:10 -0000 On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > > > > f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] > > > > method of context identification"? For example, "an SnmpEngineID > > > > and ContextName pair [RFC3411] for context identification". > > > > > > > > > > [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a > > bug I suggest to avoid such changes. > > > > It is document clarity. But I won't insist on this, I just find the > > current text unnecessarily confusing. > > > > > > g) Overall, replace MIBs with MIB modules. > > > > > > > [[DR]] Same as the previous point. > > > > Again, it is document clarity. It is rather obvious that this change > > does not break anything, no? Let Bert decide - he is the owner of the > > one MIB many MIB modules song. ;-) > > > > [[DR]] I also sing the song when I review new documents, but in this case we would interfere in the text of the document that is now at version 4. So what? Time to fix this. Anyway, I will not fight for this if editors believe it is best to not update vocabularity to current rules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jan 15 06:15:20 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE5921F86FD; Tue, 15 Jan 2013 06:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ypz-wdIH6vZq; Tue, 15 Jan 2013 06:15:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C21F8457; Tue, 15 Jan 2013 06:15:19 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC72020BF0; Tue, 15 Jan 2013 15:15:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z5ii84ZSe2e7; Tue, 15 Jan 2013 15:15:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 444D920BF3; Tue, 15 Jan 2013 15:15:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6F00023F7D25; Tue, 15 Jan 2013 15:15:20 +0100 (CET) Date: Tue, 15 Jan 2013 15:15:20 +0100 From: Juergen Schoenwaelder To: "Mouli Chandramouli (moulchan)" Message-ID: <20130115141520.GB21588@elstar.local> Mail-Followup-To: "Mouli Chandramouli (moulchan)" , "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "eman@ietf.org" , "ops-ads@tools.ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <852AF0ED49D9F24BBBFA1B4DEEBE3BA4286804C7@xmb-rcd-x08.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" , "mib-doctors@ietf.org" Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:15:20 -0000 On Tue, Jan 15, 2013 at 01:09:49PM +0000, Mouli Chandramouli (moulchan) wrote: > [ycm] snip ... > > > e) I think a paragraph should be added to section 2.12.1 to describe > > the addition made by version 4 - and if it is just for document > > consistency. > > > > Version 4 of the Entity MIB provides [...] > > > > This would also be a good place to explain whether UUIDs are > > supposed to also be represented as URIs (and why or why not). > > > [[DR]] I will let Mouli address this, as I am not sure 100% about the response to the issue of representation. > [ycm] > [ycm] Thanks for the comment. To be consistent, we shall add the following paragraph on in Section 2.12.1. > > > NEW > > Version 4 of the Entity MIB provides an additional MIB object for each physical entity. > > entPhysicalUUID - This object provides an additional unique identification about the physical entity. > This object contains a globally unique identifier for the physical entity with the format as defined in RFC 4122 [RFC4122]. > The UUID shall be represented as URIs. Sure? This is not what the definitions do (and I think it would even be wrong to do this). Please check your document. > To support the existing implementations of ENTITY-MIB v3, entPhyiscalUris object which uses the URI syntax can > be used to store the UUID value of the physical entity. Caution should to be exercised since this MIB object is read-write. Why caution? I suggest to either spell out what the issue is or leave this out. > With the implementation of ENTITY-MIB v4, the value of UUID can be stored in new MIB object entPhysicalUUID (which is read-only) > and the UUID value can also be duplicated in entPhysicalUris MIB object. To enable this capability, the syntax of the > two MIB objects should be similar. Again, I think the last sentence should be removed since the syntax is actually different. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dbharrington@comcast.net Tue Jan 15 07:39:49 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17B521F8633 for ; Tue, 15 Jan 2013 07:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 uZU-H0UUztKa for ; Tue, 15 Jan 2013 07:39:44 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42121F861F for ; Tue, 15 Jan 2013 07:39:44 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id oBqn1k0031vXlb854Ffk6p; Tue, 15 Jan 2013 15:39:44 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta17.westchester.pa.mail.comcast.net with comcast id oFfi1k00J3Ecudz3dFficz; Tue, 15 Jan 2013 15:39:43 +0000 From: "David Harrington" To: , , , Date: Tue, 15 Jan 2013 10:39:39 -0500 Message-ID: <00f101cdf336$889656f0$99c304d0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01CDF30C.9FC2BFF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3yixpHbzKoGLf+SiCRnFd8cCyL5Q== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358264384; bh=BTyWIwH7RMyxwVVT6dBLiL82FI5BbkTR0+xXjj7gk9o=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=WTOJx52gFD3TdFMQE6JdwZWyxXjphNWlMtKpM5Dwa4onD0H1bRv+by/xQmQeTmM0H MFbXBlTJ7uKfFCY0dJPLp2Z/vY68xBnxC6ujuvfChQcHSbRiaY2rYrycBpEhO+mGB6 7OKgdWUf/TUSsL6P+OoQnfnO/kGWdnRSRaS4LP7T/3HNz2+G+ZPNUCOXYsZKKS6E9o j7Z/E3ux1/ARyVQwlA6eTIs3Z0PeywqlTHnp5MPyddUNmQVRoOceZfqGIRD0ZJWmpJ l2nwjsZFAn2lEkoaMu0jkyYXDUepN8JM8rMNyPDrGjjtiVbJytfZBJI9ONKom3NGf3 GRG/M0drQGKsg== Cc: MIB Doctors , stbryant@cisco.com, adrian@olddog.co.uk Subject: [MIB-DOCTORS] MIB Doctor review of draft-ietf-sidr-rpki-rtr-protocol-mib-04 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:39:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01CDF30C.9FC2BFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Been a while since I've done one of these ;-) A few comments: This review is officially done for the OPS AD, and the AD needs to decide which points must be addressed. Most of the comments should be non-controversial and easy to address. There are a couple syntax questions. Most technical questions are about ensuring clear and unambiguous descriptions to ensure interoperability. I noticed that a MIB is not listed in the sidr charter, but this is a sidr document. I guess one could raise the point that development of an RPKI MIB has not been "sanctioned" by the general IETF during WG charter review. As a MIB Doctor, I of course think it's a reasonably good idea, assuming MIB management of this routing security functionality is a good fit. I assume the WG does, and the IETF will. I don't know if the OPS AD cares (or the RTG ADs care). Their business. Is LAST-UPDATED "201110140000Z" still correct? We've crossed a year boundary, so the 2012 copyright might need updating. RpkiRtrConnectionType/other: s/non/none rpkiRtrCacheServerConnectionType: to prevent any ambiguity, I think it might be better to describe this only as the connection type, and remove the "or transport security suite" from the object description. The fact that the connection type might be a transport security suite can be spelled out in the connection type T-C. Even there, I would be careful of ambiguity, to provide clear guidance/constraints to future developers of added enumerations. rpkiRtrCacheServerPreference: would a DEFVAL be a good idea to specify the 255 default? rpkiRtrCacheServerTimeToRefresh could benefit from a reference. Is the time to refresh always decremented by 1, or can an implementation choose to only reflect time to refresh in, say, 5 or 10 second increments? Is there a maximum negative value that makes sense here? Is it possible to require a wrap if no refresh is completed? Or should the value latch at the maximum negative value? rpkiRtrCacheServerId would benefit from a reference. rpkiRtrCacheServerId value is used as a relation between tables. What are the fate-sharing requirements? Must a corresponding rpkiRtrPrefixOriginCacheServerId exist? Or if rpkiRtrPrefixOriginCacheServerId exists, must a corresponding rpkiRtrCacheServerId exist? If one entry is deleted, must the corresponding entry be deleted to prevent one table from reusing an identifier that is still in use in the other table? s/debuging/debugging/ The Errors table contains counters that represent "the number of XXX errors received." This description seems to indicate that counters start at zero (and implicitly reset to zero on a discontinuity). An NMS developer certainly might interpret this text as indicating zero-based counters. I think if there is an assumption these are zero-based, there are TC-s that could be used to show that assumption. OTOH, counters typically are not zero-based because if errors occur during system startup, the counter might be initialized partway through the startup and not reflect all the errors that occurred during the startup phase. I think this table would benefit from a discussion of the expected initial values (zero or unpredictable/implementation-dependent) and the nature of expected discontinuities, so NMS developers can be sure to understand the relevant assumptions. (is the only discontinuity a restart of the management system? What about rollovers? Are all these error counters not preserved across system restarts? Or can an implementation choose to preserve them across resets to enhance debugging history?) Some of this discussion would seem to apply to all the error counters; if that is true of all current counters and should be true for an potentially new counters added to this table, this type of discussion could be captured in the Table or TableEntry description. (including the discussion of rpkiRtrDiscontinuityTimer, which seems to apply to the whole table). The errors objects might benefit from a reference to the descriptions of errors in RPKI specs, so NMS implementors are likely to interpret the counters consistently. And to be clear, these counters count the number of messages from the cache server reporting a remote error, right? These counters never count an error (found locally) in a message from the remote server? So it's not actually the number of errors received, but the number of server-generated error-reports received? Right? That could be made slightly clearer. The comment discussing ROATable probably isn't needed in the final document, since no official REVISION included ROATable, right? s/recieved/received/ rpkiRtrPrefixOriginAddressType: "Only IPv4 and IPv6 are supported." - This is an enumeration that could be extended in the future if RPKI ever supports additional address types (like ipv7 or something); the limitation of ipv4/ipv6 is presumably a limit set by RPKI; it should not be a limit set by the MIB object, which could not be updated to match an updated RPKI. Each of these objects should reference the current limit in RPKI, and allow for future SMIv2 extensibility of the enumeration so extending it would not involve obsoleting each object and defining a new object without limits. By indicating that the enumeration could legally be extended at some point in the future, NMS developers can plan accordingly; the current approach could inadvertently encourage hard-coding support for these, and only these, two enumeration values. >From RFC4001: "The InetAddressType and InetAddress objects SHOULD NOT be sub-typed in object definitions. Sub-typing binds the MIB module to specific address formats, which may cause serious problems if new address formats need to be introduced. Note that it is possible to write compliance statements indicating that only a subset of the defined address types must be implemented to be compliant." Would putting the limit in a compliance clause rather than the object description clause work? Could RPKI ever be implemented in a non-global environment, where address zoning might be needed? rpkiRtrPrefixOriginAddress says "The format of the address is defined by the value of the corresponding instance of rpkiRtrCacheServerAddressType." Shouldn't this be rpkiRtrPrefixOriginAddressType? rpkiRtrCacheServerConnectionStateChange says: " The SNMP agent MUST throttle the generation of consecutive rpkiRtrCacheServerConnectionStateChange notifications such that there is at least a 5 second gap between them." A MIB is theoretically separate from the protocol used to carry the information. What happens if the notification is being reported by something other than SNMP? Is throttling still required? I am a bit concerned by the text that describes throttling generation; should generation be throttled, or should sending be throttled? The need to recognize a status change event and request a notification be sent (i.e., generation) might be handled by the underlying instrumentation, while sending the notification would seem to be the purview of the protocol being used (i.e., the SNMP engine). If I have a down event followed by an up event 2 seconds later, should I not generate a notification reporting the state change? What if I have no subsequent up event to report? Should the NMS continue to believe the state is down? Or should I just queue the up notification for 3 seconds and then send it? (and I realize queuing could just push the excessive generation problem down the road, AND lead to untimely reports). The current text is unclear about this and I am concerned whether there might be interoperability problems caused by differing interpretations of how to throttle these notifications. I know we require a discussion of throttling; is this the best way to document the throttling for these notifications? In rpkiRtrReadOnlyCompliance, s/Implemntation/Implementation/ While read-write and read-create may not be envisioned, it is probably incorrect to state that the MIB module contains only read-only objects without specifying that this is true for the current REVISION. I have a concern about naming this so generically; what happens if new read-only objects are added in the future? The new objects cannot be added to this compliance clause, so the goal of clarity and truth in advertising will not necessarily hold up. I recommend naming the compliance clause (possibly using the assigned RFC#) so it is clear that this list of objects applies to the current REVISION of the MIB module. Are none of the objects in this MIB potentially sensitive to disclosure? None are listed. The MIB security boilerplate references 3414 and 3826. There has been some discussion of whether these should be considered normative. David Harrington dbharrington@comcast.net +1-603-828-1401 ------=_NextPart_000_00F2_01CDF30C.9FC2BFF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Been a while = since I’ve done one of these ;-)

A few comments:

 

This review = is officially done for the OPS  AD, and the AD needs to decide = which points must be addressed.

Most = of the comments should be non-controversial and easy to = address.

There are a couple syntax = questions.

Most technical questions = are about ensuring clear and unambiguous descriptions to ensure = interoperability.

 

I noticed that a = MIB is not listed in the sidr charter, but this is a sidr document. =

I guess one could = raise the point that development of an RPKI MIB has not been = “sanctioned” by the general IETF during WG charter = review.

As a MIB Doctor, I = of course think it’s a reasonably good idea, assuming MIB = management of this routing security functionality is a good fit. =

I assume the WG = does, and the IETF will.

I don’t know = if the OPS AD cares (or the RTG ADs care). Their = business.

 

Is LAST-UPDATED = "201110140000Z" still correct?

 

We’ve crossed = a year boundary, so the 2012 copyright might need = updating.

 

RpkiRtrConnectionType/other: s/non/none

 

rpkiRtrCacheServerConnectionType: to prevent any ambiguity, I = think it might be better to describe this only as the connection type, = and remove the “or transport security suite” from the object = description. The fact that the connection type might be a transport = security suite can be spelled out in the connection type T-C. Even = there, I would be careful of ambiguity, to provide clear = guidance/constraints to future developers of added = enumerations.

 

rpkiRtrCacheServerPreference: would a DEFVAL be a good idea to = specify the 255 default?

 

rpkiRtrCacheServerTimeToRefresh could benefit from a reference. Is = the time to refresh always decremented by 1, or can an implementation = choose to only reflect time to refresh in, say, 5 or 10 second = increments? Is there a maximum negative value that makes sense here? Is = it possible to require a wrap if no refresh is completed? Or should the = value latch at the maximum negative value?

 

rpkiRtrCacheServerId would benefit from a reference. =

 

rpkiRtrCacheServerId value is used as a relation between tables. = What are the fate-sharing requirements? Must a corresponding = rpkiRtrPrefixOriginCacheServerId  exist? Or if = rpkiRtrPrefixOriginCacheServerId  exists, must a corresponding = rpkiRtrCacheServerId exist? If one entry is deleted, must the = corresponding entry be deleted to prevent one table from reusing an = identifier that is still in use in the other = table?

 

s/debuging/debugging/

 

The Errors = table contains counters that represent “the number of XXX errors = received.” This description seems to indicate that counters start = at zero (and implicitly reset to zero on a discontinuity). An NMS = developer certainly might interpret this text as indicating zero-based = counters. I think if there is an assumption these are zero-based, there = are TC-s that could be used to show that assumption. OTOH, counters = typically are not zero-based because if errors occur during system = startup, the counter might be initialized partway through the startup = and not reflect all the errors that occurred during the startup phase. I = think this table would benefit from a discussion of the expected initial = values (zero or unpredictable/implementation-dependent) and the nature = of expected discontinuities, so NMS developers can be sure to understand = the relevant assumptions.  (is the only discontinuity a restart of = the management system? What about rollovers? Are all these error = counters not preserved across system restarts? Or can an implementation = choose to preserve them across resets to enhance debugging history?) = Some of this discussion would seem to apply to all the error counters; = if that is true of all current counters and should be true for an = potentially new counters added to this table, this type of discussion = could be captured in the Table or TableEntry description. (including the = discussion of rpkiRtrDiscontinuityTimer, which seems to apply to the whole = table).

 

The errors = objects might benefit from a reference to the descriptions of errors in = RPKI specs, so NMS implementors are likely to interpret the counters = consistently.

 

And to be clear, these counters count the number of = messages from the cache server reporting a remote error, right? These = counters never count an error (found locally) in a message from the = remote server? So it’s not actually the number of errors received, = but the number of server-generated error-reports received? Right? That = could be made slightly clearer.

 

The comment = discussing ROATable probably isn’t needed in the final document, = since no official REVISION included ROATable, right?

 

s/recieved/received/

 

rpkiRtrPrefixOriginAddressType: “Only IPv4 and IPv6 are = supported.” – This is an enumeration that could be extended = in the future if RPKI ever supports additional address types (like ipv7 = or something); the limitation of ipv4/ipv6 is presumably a limit set by = RPKI; it should not be a limit set by the MIB object, which could not be = updated to match an updated RPKI. Each of these objects should reference = the current limit in RPKI, and allow for future SMIv2 extensibility of = the enumeration so extending it would not involve obsoleting each object = and defining a new object without limits. By indicating that the = enumeration could legally be extended at some point in the future, NMS = developers can plan accordingly; the current approach could = inadvertently encourage hard-coding support for these, and only these, = two enumeration values.

From = RFC4001:

“The InetAddressType = and InetAddress objects SHOULD NOT be sub-typed

   in = object definitions.  Sub-typing binds the MIB module to = specific

   = address formats, which may cause serious problems if new = address

   = formats need to be introduced.  Note that it is possible to = write

   = compliance statements indicating that only a subset of the = defined

   = address types must be implemented to be = compliant.”

Would putting the = limit in a compliance clause rather than the object description clause = work?

 

Could RPKI ever be implemented in a non-global = environment, where address zoning might be needed?

 

rpkiRtrPrefixOriginAddress  says “The format of the = address is defined by the

           &= nbsp;        value of the = corresponding instance of

           &= nbsp;        = rpkiRtrCacheServerAddressType."

Shouldn’t this be rpkiRtrPrefixOriginAddressType?

 

rpkiRtrCacheServerConnectionStateChange says: =

“           &= nbsp;       The SNMP agent MUST throttle = the generation of

           &= nbsp;        consecutive = rpkiRtrCacheServerConnectionStateChange

           &= nbsp;        notifications such that = there is at least a

           &= nbsp;        5 second gap between = them.”

A MIB is = theoretically separate from the protocol used to carry the information. = What happens if the notification is being reported by something other = than SNMP? Is throttling still required?

 

I am a bit = concerned by the text that describes throttling generation; should = generation be throttled, or should sending be throttled? The need to = recognize a status change event and request a notification be sent = (i.e., generation) might be handled by the underlying instrumentation, = while sending the notification would seem to be the purview of the = protocol being used (i.e., the SNMP engine). If I have a down event = followed by an up event 2 seconds later, should I not generate a = notification reporting the state change? What if I have no subsequent up = event to report? Should the NMS continue to believe the state is down? = Or should I just queue the up notification for 3 seconds and then send = it?

(and I realize = queuing could just push the excessive generation problem down the road, = AND lead to untimely reports). The current text is unclear about this = and I am concerned whether there might be interoperability problems = caused by differing interpretations of how to throttle these = notifications. I know we require a discussion of throttling; is this the = best way to document the throttling for these notifications? =

 

In rpkiRtrReadOnlyCompliance, = s/Implemntation/Implementation/

While read-write and read-create may not be envisioned, it is = probably incorrect to state that the MIB module contains only read-only = objects without specifying that this is true for the current REVISION. I = have a concern about naming this so generically; what happens if new = read-only objects are added in the future? The new objects cannot be = added to this compliance clause, so the goal of clarity and truth in = advertising will not necessarily hold up. I recommend naming the = compliance clause (possibly using the assigned RFC#) so it is clear that = this list of objects applies to the current REVISION of the MIB = module.

 

Are none of the = objects in this MIB potentially sensitive to disclosure? None are = listed.

 

The MIB security = boilerplate references 3414 and 3826. There has been some discussion of = whether these should be considered normative.

 

 

David = Harrington

dbharrington@comcast.net

+1-603-828-14= 01

------=_NextPart_000_00F2_01CDF30C.9FC2BFF0-- From bclaise@cisco.com Wed Jan 16 01:30:11 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADCC21F869E; Wed, 16 Jan 2013 01:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 w95q9pw5uYJW; Wed, 16 Jan 2013 01:30:06 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B513821F868F; Wed, 16 Jan 2013 01:30:05 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0G9TsDn009831; Wed, 16 Jan 2013 10:29:54 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0G9T6Ri027672; Wed, 16 Jan 2013 10:29:28 +0100 (CET) Message-ID: <50F672E2.9050600@cisco.com> Date: Wed, 16 Jan 2013 10:29:06 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ietfdbh References: <50EC3ACB.8050100@cisco.com> <025001cdede4$ba097200$2e1c5600$@comcast.net> <50ED75A3.30605@cisco.com> In-Reply-To: <50ED75A3.30605@cisco.com> Content-Type: multipart/alternative; boundary="------------040504080609030104070800" Cc: "'MIB Doctors \(E-mail\)'" , ops-dir@ietf.org, 'Bert Wijnen' Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 09:30:11 -0000 This is a multi-part message in MIME format. --------------040504080609030104070800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The deadline is now passed. I received the green light from the two security ADs. Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security has been updated. And the 4 ADLSMIB documents will now progress. Regards, Benoit > Hi David, >> >> Hi Benoit, >> >> Unless it is an SNMPv3-specific MIB module, a MIB module will usually >> not be broken by using SNMPv1 or SNMPv2. >> >> And, a MIB module typically will not be broken by the use of SNMPv3 >> with a security model other than USM with AES. >> >> And, a MIB module will not be broken by using a protocol other than SNMP. >> >> Hence, I think that MUST is being used inappropriately when the >> boilerplate says SNMPv3 MUST be supported for a particular MIB module. >> >> I think what we really want to say is that we RECOMMEND SNMPv3 -- for >> purposes of security -- with USM/AES for purposes of interoperability. >> >> I recommend the text read: >> >> Implementations_SHOULD_ provide the security features described by the >> SNMPv3 framework (see [RFC3410]),_and implementations claiming compliance to the SNMPv3 standard_ MUST include full support for >> authentication and privacy via the User-based Security Model (USM) >> [RFC3414] with the AES cipher algorithm [RFC3826]. > That would be in the spirit of your proposition. Fine with me. > > Regards, Benoit >> >> Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB. >> If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well? >> >> >> As one of the developers of SNMPv3, I certainly would like to see it >> implemented, but I think this boilerplate is being heavy handed by >> saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST >> be supported. >> >> The original MIB boilerplate combination said SNMP was typically used >> for carrying MIB data, and version 3 of SNMP was RECOMMENDED because >> of its security properties. That makes sense to me. The MUST does not. >> >> That said, I am fine with the current boilerplate if that's what the >> IESG wants; I just think it's not very accurate. >> >> David Harrington >> >> ietfdbh@comcast.net >> >> +1-603-828-1401 >> >> *From:*Benoit Claise [mailto:bclaise@cisco.com] >> *Sent:* Tuesday, January 08, 2013 10:27 AM >> *To:* David Harrington >> *Cc:* Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne >> Bartholomew >> *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF >> MIB Modules: normative or informative references? >> >> Hi Dave, >> >> I understand your argument, and I tend to agree with you. >> >> The problem statement is: the following sentence is kind of broken , >> because RFC 3414 and RFC 3826 are informative references; >> >> Implementations MUST provide the security features described by the >> SNMPv3 framework (see [RFC3410]), including full support for >> authentication and privacy via the User-based Security Model (USM) >> [RFC3414] with the AES cipher algorithm [RFC3826]. >> >> >> There are two things we can do >> >> 1. do nothing, because it's not worth it. >> >> 2. Correct the sentence >> >> OLD (the 3 paragraphs are copied for completeness, while only the >> second and third one are changed): >> >> SNMP versions prior to SNMPv3 did not include adequate security. >> Even if the network itself is secure (for example by using IPsec), >> there is no control as to who on the secure network is >> allowed to access and GET/SET (read/change/create/delete) the objects >> in this MIB module. >> >> Implementations MUST provide the security features described by the >> SNMPv3 framework (see [RFC3410]), including full support for >> authentication and privacy via the User-based Security Model (USM) >> [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations >> MAY also provide support for the Transport Security Model (TSM) >> [RFC5591] in combination with a secure transport such as SSH >> [RFC5592] or TLS/DTLS [RFC6353]. >> >> Further, deployment of SNMP versions prior to SNMPv3 is NOT >> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >> enable cryptographic security. It is then a customer/operator >> responsibility to ensure that the SNMP entity giving access to an >> instance of this MIB module is properly configured to give access to >> the objects only to those principals (users) that have legitimate >> rights to indeed GET or SET (change/create/delete) them. >> >> NEW: >> >> SNMP versions prior to SNMPv3 did not include adequate security. >> Even if the network itself is secure (for example by using IPsec), >> there is no control as to who on the secure network is >> allowed to access and GET/SET (read/change/create/delete) the objects >> in this MIB module. >> Implementations MUST provide the security features described by the >> SNMPv3 framework (see [RFC3410])._When implementing SNMPv3, full support for_ >> _ authentication and privacy via the User-based Security Model (USM)_ >> _ [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._ >> Implementations MAY also provide support for the Transport Security Model (TSM) >> [RFC5591] in combination with a secure transport such as SSH >> [RFC5592] or TLS/DTLS [RFC6353]. >> Further, deployment of SNMP versions prior to SNMPv3 is NOT >> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >> enable cryptographic security. It is then a customer/operator >> responsibility to ensure that the SNMP entity giving access to an >> instance of this MIB module is properly configured to give access to >> the objects only to those principals (users) that have legitimate >> rights to indeed GET or SET (change/create/delete) them. >> >> And we move the following references from informative to normative >> >> [RFC3414] Blumenthal, U., and B. Wijnen, >> "User-based Security Model (USM) for version 3 of the >> Simple Network Management Protocol (SNMPv3)", RFC 3414, >> December 2002. >> >> [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, >> "The Advanced Encryption Standard (AES) Cipher >> Algorithm in the SNMP User-based Security Model", >> RFC 3826, June 2004. >> [RFC5591] Harrington, D., and W. Hardaker, >> "Transport Security Model for the Simple Network >> Management Protocol (SNMP)", June 2009. >> >> [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, >> "Secure Shell Transport Model for the Simple Network >> Management Protocol (SNMP)", June 2009. >> >> [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport >> Model for the Simple Network Management Protocol (SNMP)", >> July 2011. >> >> >> I want to go for solution 2. If we redo the full discussion, and the >> discussion goes nowhere, I'll go for solution 1 (I have a few >> documents in AUTH48 waiting on this) >> >> Feedback? >> Unless I hear otherwise, I will apply the changes in a week from now. >> >> Thanks Dan for helping on this issue. >> >> Regards, Benoit >> >> Hi, >> >> >> >> The mib security boilerplate changed in December of 2011, following >> >> discussion between the OPS and Security ADs and the MIB Doctors. >> >> >> >> IIRC, we always made implementation of SNMPv3 recommended but not required. >> >> No MIB module (except those specifically related to managing SNMPv3) >> >> should require SNMPv3 to work. >> >> Any MIB theoretically should work with any version of SNMP (given known >> >> interoperability issues of SNMPv1 vs SMIv2, etc.). >> >> Theoretically (and according to IAB recommendations in RFC1052), the MIB >> >> should also be able to work with protocols other than SNMP, since "The >> >> MIB" is just a database that (theoretically) is independent of the >> >> protocol used to access it. >> >> So no MIB module (with exceptions) should REQUIRE a specific protocol or >> >> protocol version to access it. >> >> (yawn. I'm sure you guys are tired of hearing this from me ;-) >> >> >> >> We deliberately made RFC3410 Informational to avoid downrefs. >> >> IIRC, you cannot implement RFC3410 because it doesn't define a protocol; >> >> it's just a roadmap. >> >> >> >> SNMPv3 was designed as something of a framework that could be built from >> >> multiple pieces - a messaging model, a security model, an ACM model, etc. >> >> RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it >> >> was definitely an SNMPv3 WG decision that this was AN architecture, not >> >> THE architecture for SNMPv3, to allow for alternative approaches (such as >> >> ISMS work on transport models) and to allow for implementation-specific >> >> decisions that would not affect the on-the-wire protocol. >> >> >> >> The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would >> >> make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which >> >> RFCs actually make up SNMPv3, and are MUST implement). >> >> But that seems to fly in the face of the SNMPv3 WG intention to NOT make a >> >> certain set of RFCs **THE** SNMPv3 definition. >> >> (Of course, the IESG approved an IETF Standard called SNMPv3, which >> >> contained the RFC34xx series as a set of RFCs within the somewhat-abstract >> >> SNMPv3 Standard, to ensure base interoperability.) >> >> >> >> I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs >> >> MUST be implemented, and make those references normative. >> >> I.e., what you would be doing is defining THE set of RFCs that define >> >> SNMPv3. >> >> >> >> I personally think it best not to require a specific version of SNMP as >> >> part of the boilerplate for a MIB module. >> >> >> >> >> >> -- >> >> David Harrington >> >> Ietfdbh@comcast.net >> >> +1-603-828-1401 >> >> >> >> >> >> >> >> >> >> >> >> On 1/2/13 7:52 AM, "Bert Wijnen" wrote: >> >> >> >> RFC3410 is an informational document and has ALWAYS been >> >> listed as informational. >> >> So... if you make it Normative, you have a >> >> downref. >> >> The 3414 and 3826 might be listed as Normative. >> >> >> >> The otehr 3 are only listed as MAY implement. So would it then >> >> have to be normative? >> >> >> >> For me the most important thing is that the pointers to all >> >> this >> >> documents are listed, so you can quickly find >> >> them. >> >> >> >> Bert >> >> >> >> >> >> ----- Original Message ----- >> >> From: >> >> Benoit Claise >> >> >> >> To:ops-dir@ietf.org ; MIB Doctors >> >> (E-mail) >> >> Cc:adslmib-chairs@ietf.org ; Lynne >> >> Bartholomew ; Edward Beili >> >> ; Moti Morgenstern >> >> >> >> Sent: Wednesday, January 02, 2013 12:33 >> >> PM >> >> Subject: [MIB-DOCTORS] Security >> >> Guidelines for IETF MIB Modules: normative or informative references? >> >> >> >> Dear all, >> >> >> >> In the AUTH48 process for >> >> draft-ietf-adslmib-gbond-mib-11.txt >> >> (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi >> >> b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), >> >> we discussed with the RFC editor whether the following RFCs should be >> >> normative or informative: >> >> Implementations MUST provide the security features described by the >> >> SNMPv3 framework (see [RFC3410]), including full support for >> >> authentication and privacy via the User-based Security Model (USM) >> >> [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they >> >> should be normative, based on the justification at >> >> http://www.ietf.org/iesg/statement/normative-informative.html >> >> Normative references specify documents that must be read to >> >> understand or implement the technology in the new RFC, or whose >> >> technology >> >> must be present for the technology in the new RFC to work. >> >> >> >> The >> >> RFC editors answered: >> >> >> >> Thank you for the email. We see your point and agree that it >> >> makes sense that the references would be listed as normative, but we >> >> do not >> >> make calls on which documents are listed as informative vs normative. >> >> We note that >> >> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists >> >> the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, >> >> and 6353 -- as informative. Please request that the wiki >> >> be >> >> updated, if necessary. >> >> >> >> >> >> So normative or informative >> >> references? >> >> Shall I update the WIKI? >> >> >> >> Regards, Benoit >> >> >> >> >> >> >> >> >> >> >> >> ________________________________________ >> >> >> >> _______________________________________________ >> >> MIB-DOCTORS mailing >> >> list >> >> MIB-DOCTORS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> >> >> >> >> _______________________________________________ >> >> OPS-DIR mailing list >> >> OPS-DIR@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ops-dir >> >> >> >> >> >> >> > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir --------------040504080609030104070800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

The deadline is now passed.
I received the green light from the two security ADs.
Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security has been  updated.
And the 4 ADLSMIB documents will now progress.

Regards, Benoit
Hi David,

Hi Benoit,

 

Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be broken by using SNMPv1 or SNMPv2.

And, a MIB module typically will not be broken by the use of SNMPv3 with a security model other than USM with AES.

And, a MIB module will not be broken by using a protocol other than SNMP.

 

Hence, I think that MUST is being used inappropriately when the boilerplate says SNMPv3 MUST be supported for a particular MIB module.

 

I think what we really want to say is that we RECOMMEND SNMPv3 – for purposes of security – with USM/AES for purposes of interoperability.

I recommend the text read:

   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].
That would be in the spirit of your proposition. Fine with me.

Regards, Benoit
 
Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB.
If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well?
 

As one of the developers of SNMPv3, I certainly would like to see it implemented, but I think this boilerplate is being heavy handed by saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported.

The original MIB boilerplate combination said SNMP was typically used for carrying MIB data, and version 3 of SNMP was RECOMMENDED because of its security properties. That makes sense to me. The MUST does not.

 

That said, I am fine with the current boilerplate if that’s what the IESG wants; I just think it’s not very accurate.

 

David Harrington

ietfdbh@comcast.net

+1-603-828-1401

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, January 08, 2013 10:27 AM
To: David Harrington
Cc: Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne Bartholomew
Subject: Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references?

 

Hi Dave,

I understand your argument, and I tend to agree with you.

The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references;

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].


There are two things we can do

1. do nothing, because it's not worth it.

2. Correct the sentence

OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed):

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.
 
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].
 
   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

NEW: 

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]). When implementing SNMPv3, full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED.
   Implementations MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].
   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

And we move the following references from informative to normative

   [RFC3414] Blumenthal, U., and B. Wijnen, 
             "User-based Security Model (USM) for version 3 of the
             Simple Network Management Protocol (SNMPv3)", RFC 3414,
             December 2002.
 
   [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie,
             "The Advanced Encryption Standard (AES) Cipher 
             Algorithm in the SNMP User-based Security Model",
             RFC 3826, June 2004.
   [RFC5591] Harrington, D., and W. Hardaker,
             "Transport Security Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.
 
   [RFC5592] Harrington, D., Saloway, J., and W. Hardaker,
             "Secure Shell Transport Model for the Simple Network 
             Management Protocol (SNMP)", June 2009.
 
   [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport 
             Model for the Simple Network Management Protocol (SNMP)",
             July 2011.


I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a few documents in AUTH48 waiting on this)

Feedback?
Unless I hear otherwise, I will apply the changes in a week from now.

Thanks Dan for helping on this issue.

Regards, Benoit

Hi,
 
The mib security boilerplate changed in December of 2011, following
discussion between the OPS and Security ADs and the MIB Doctors.
 
IIRC, we always made implementation of SNMPv3 recommended but not required.
No MIB module (except those specifically related to managing SNMPv3)
should require SNMPv3 to work.
Any MIB theoretically should work with any version of SNMP (given known
interoperability issues of SNMPv1 vs SMIv2, etc.).
Theoretically (and according to IAB recommendations in RFC1052), the MIB
should also be able to work with protocols other than SNMP, since "The
MIB" is just a database that (theoretically) is independent of the
protocol used to access it.
So no MIB module (with exceptions) should REQUIRE a specific protocol or
protocol version to access it.
(yawn. I'm sure you guys are tired of hearing this from me ;-)
 
We deliberately made RFC3410 Informational to avoid downrefs.
IIRC, you cannot implement RFC3410 because it doesn't define a protocol;
it's just a roadmap.
 
SNMPv3 was designed as something of a framework that could be built from
multiple pieces - a messaging model, a security model, an ACM model, etc.
RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it
was definitely an SNMPv3 WG decision that this was AN architecture, not
THE architecture for SNMPv3, to allow for alternative approaches (such as
ISMS work on transport models) and to allow for implementation-specific
decisions that would not affect the on-the-wire protocol.
 
The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would
make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which
RFCs actually make up SNMPv3, and are MUST implement).
But that seems to fly in the face of the SNMPv3 WG intention to NOT make a
certain set of RFCs **THE** SNMPv3 definition.
(Of course, the IESG approved an IETF Standard called SNMPv3, which
contained the RFC34xx series as a set of RFCs within the somewhat-abstract
SNMPv3 Standard, to ensure base interoperability.)
 
I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs
MUST be implemented, and make those references normative.
I.e., what you would be doing is defining THE set of RFCs that define
SNMPv3.
 
I personally think it best not to require a specific version of SNMP as
part of the boilerplate for a MIB module.
 
 
--
David Harrington
Ietfdbh@comcast.net
+1-603-828-1401
 
 
 
 
 
On 1/2/13 7:52 AM, "Bert Wijnen" <bwijnen@bwijnen.net> wrote:
 
RFC3410 is an informational document and has ALWAYS been
listed as informational.
So... if you make it Normative, you have a
downref.
The 3414 and 3826 might be listed as Normative.
 
The otehr 3 are only listed as MAY implement. So would it then
have to be normative?
 
For me the most important thing is that the pointers to all
this
documents are listed, so you can quickly find
them.
 
Bert
 
 
 ----- Original Message -----
 From: 
 Benoit Claise <mailto:bclaise@cisco.com>
 
 To: ops-dir@ietf.org ; MIB Doctors
 (E-mail) <mailto:mib-doctors@ietf.org>
 Cc: adslmib-chairs@ietf.org ; Lynne
 Bartholomew <mailto:lbartholomew@amsl.com> ; Edward Beili
<mailto:EdwardB@actelis.com> ; Moti Morgenstern
<mailto:Moti.Morgenstern@ecitele.com>
 Sent: Wednesday, January 02, 2013 12:33
 PM
 Subject: [MIB-DOCTORS] Security
 Guidelines for IETF MIB Modules: normative or informative references?
 
Dear all,
 
In the AUTH48 process for
 draft-ietf-adslmib-gbond-mib-11.txt
(https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi
b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=),
 we discussed with the RFC editor whether the following RFCs should be
 normative or informative:
  Implementations MUST provide the security features described by the
  SNMPv3 framework (see [RFC3410]), including full support for
  authentication and privacy via the User-based Security Model (USM)
  [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they
 should be normative, based on the justification at
http://www.ietf.org/iesg/statement/normative-informative.html
 Normative references specify documents that must be read to
   understand or implement the technology in the new RFC, or whose
technology 
   must be present for the technology in the new RFC to work.
 
The 
 RFC editors answered:
 
   Thank you for the email.  We see your point and agree that it
   makes sense that the references would be listed as normative, but we
do not 
   make calls on which documents are listed as informative vs normative.
    We note that 
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists
   the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592,
and 6353 -- as informative. Please request that the wiki
   be
updated, if necessary.
 
 
So normative or informative
 references?
Shall I update the WIKI?
 
Regards, Benoit
 
 
 
 
 
________________________________________
 
 _______________________________________________
MIB-DOCTORS mailing
 list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors
 
 
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
 
 
 

 




_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

--------------040504080609030104070800-- From bertietf@bwijnen.net Wed Jan 16 02:22:42 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2721F84BC; Wed, 16 Jan 2013 02:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 amCuxXfjtY8q; Wed, 16 Jan 2013 02:22:41 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9E21F8455; Wed, 16 Jan 2013 02:22:41 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TvQ8i-0005cy-Mt; Wed, 16 Jan 2013 11:22:39 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TvQ8i-0005jt-CX; Wed, 16 Jan 2013 11:22:36 +0100 Message-ID: <50F67F6B.5070007@bwijnen.net> Date: Wed, 16 Jan 2013 11:22:35 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Benoit Claise References: <50EC3ACB.8050100@cisco.com> <025001cdede4$ba097200$2e1c5600$@comcast.net> <50ED75A3.30605@cisco.com> <50F672E2.9050600@cisco.com> In-Reply-To: <50F672E2.9050600@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130116 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ffd1adac06b23e307b0f89a04e074aac Cc: "'MIB Doctors \(E-mail\)'" , ops-dir@ietf.org, 'Bert Wijnen' Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 10:22:43 -0000 SO I guess this means that all MIB documents in progress need to be updated with this new text too. Bert On 1/16/13 10:29 AM, Benoit Claise wrote: > Hi, > > The deadline is now passed. > I received the green light from the two security ADs. > Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security has been updated. > And the 4 ADLSMIB documents will now progress. > > Regards, Benoit >> Hi David, >>> >>> Hi Benoit, >>> >>> Unless it is an SNMPv3-specific MIB module, a MIB module will usually not be broken by using SNMPv1 or SNMPv2. >>> >>> And, a MIB module typically will not be broken by the use of SNMPv3 with a security model other than USM with AES. >>> >>> And, a MIB module will not be broken by using a protocol other than SNMP. >>> >>> Hence, I think that MUST is being used inappropriately when the boilerplate says SNMPv3 MUST be supported for a particular MIB >>> module. >>> >>> I think what we really want to say is that we RECOMMEND SNMPv3 – for purposes of security – with USM/AES for purposes of >>> interoperability. >>> >>> I recommend the text read: >>> >>> Implementations_SHOULD_ provide the security features described by the >>> SNMPv3 framework (see [RFC3410]),_and implementations claiming compliance to the SNMPv3 standard_ MUST include full support for >>> authentication and privacy via the User-based Security Model (USM) >>> [RFC3414] with the AES cipher algorithm [RFC3826]. >> That would be in the spirit of your proposition. Fine with me. >> >> Regards, Benoit >>> >>> Of course, it can be debated whether every MIB module document should include compliance requirements for ONE of the protocols that COULD be used to access the MIB. >>> If we are going to add SNMPv3-compliance requirements to every MIB document, and syslog and netconf and ipfix and others can also be used to carry the data described in the MIB module, should we include compliance requirements for specific versions of the syslog protocol, the netconf protocol, the ipfix protocol, and so on in the MIB boilerplate as well? >>> >>> >>> As one of the developers of SNMPv3, I certainly would like to see it implemented, but I think this boilerplate is being heavy >>> handed by saying, in every IETF MIB module published, that SNMPv3+USM+AES MUST be supported. >>> >>> The original MIB boilerplate combination said SNMP was typically used for carrying MIB data, and version 3 of SNMP was >>> RECOMMENDED because of its security properties. That makes sense to me. The MUST does not. >>> >>> That said, I am fine with the current boilerplate if that’s what the IESG wants; I just think it’s not very accurate. >>> >>> David Harrington >>> >>> ietfdbh@comcast.net >>> >>> +1-603-828-1401 >>> >>> *From:*Benoit Claise [mailto:bclaise@cisco.com] >>> *Sent:* Tuesday, January 08, 2013 10:27 AM >>> *To:* David Harrington >>> *Cc:* Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne Bartholomew >>> *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF MIB Modules: normative or informative references? >>> >>> Hi Dave, >>> >>> I understand your argument, and I tend to agree with you. >>> >>> The problem statement is: the following sentence is kind of broken , because RFC 3414 and RFC 3826 are informative references; >>> >>> Implementations MUST provide the security features described by the >>> SNMPv3 framework (see [RFC3410]), including full support for >>> authentication and privacy via the User-based Security Model (USM) >>> [RFC3414] with the AES cipher algorithm [RFC3826]. >>> >>> >>> There are two things we can do >>> >>> 1. do nothing, because it's not worth it. >>> >>> 2. Correct the sentence >>> >>> OLD (the 3 paragraphs are copied for completeness, while only the second and third one are changed): >>> >>> SNMP versions prior to SNMPv3 did not include adequate security. >>> Even if the network itself is secure (for example by using IPsec), >>> there is no control as to who on the secure network is >>> allowed to access and GET/SET (read/change/create/delete) the objects >>> in this MIB module. >>> >>> Implementations MUST provide the security features described by the >>> SNMPv3 framework (see [RFC3410]), including full support for >>> authentication and privacy via the User-based Security Model (USM) >>> [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations >>> MAY also provide support for the Transport Security Model (TSM) >>> [RFC5591] in combination with a secure transport such as SSH >>> [RFC5592] or TLS/DTLS [RFC6353]. >>> >>> Further, deployment of SNMP versions prior to SNMPv3 is NOT >>> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >>> enable cryptographic security. It is then a customer/operator >>> responsibility to ensure that the SNMP entity giving access to an >>> instance of this MIB module is properly configured to give access to >>> the objects only to those principals (users) that have legitimate >>> rights to indeed GET or SET (change/create/delete) them. >>> >>> NEW: >>> >>> SNMP versions prior to SNMPv3 did not include adequate security. >>> Even if the network itself is secure (for example by using IPsec), >>> there is no control as to who on the secure network is >>> allowed to access and GET/SET (read/change/create/delete) the objects >>> in this MIB module. >>> Implementations MUST provide the security features described by the >>> SNMPv3 framework (see [RFC3410])._When implementing SNMPv3, full support for_ >>> _ authentication and privacy via the User-based Security Model (USM)_ >>> _ [RFC3414] with the AES cipher algorithm [RFC3826] is RECOMMENDED._ >>> Implementations MAY also provide support for the Transport Security Model (TSM) >>> [RFC5591] in combination with a secure transport such as SSH >>> [RFC5592] or TLS/DTLS [RFC6353]. >>> Further, deployment of SNMP versions prior to SNMPv3 is NOT >>> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >>> enable cryptographic security. It is then a customer/operator >>> responsibility to ensure that the SNMP entity giving access to an >>> instance of this MIB module is properly configured to give access to >>> the objects only to those principals (users) that have legitimate >>> rights to indeed GET or SET (change/create/delete) them. >>> >>> And we move the following references from informative to normative >>> >>> [RFC3414] Blumenthal, U., and B. Wijnen, >>> "User-based Security Model (USM) for version 3 of the >>> Simple Network Management Protocol (SNMPv3)", RFC 3414, >>> December 2002. >>> >>> [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, >>> "The Advanced Encryption Standard (AES) Cipher >>> Algorithm in the SNMP User-based Security Model", >>> RFC 3826, June 2004. >>> [RFC5591] Harrington, D., and W. Hardaker, >>> "Transport Security Model for the Simple Network >>> Management Protocol (SNMP)", June 2009. >>> >>> [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, >>> "Secure Shell Transport Model for the Simple Network >>> Management Protocol (SNMP)", June 2009. >>> >>> [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport >>> Model for the Simple Network Management Protocol (SNMP)", >>> July 2011. >>> >>> >>> I want to go for solution 2. If we redo the full discussion, and the discussion goes nowhere, I'll go for solution 1 (I have a >>> few documents in AUTH48 waiting on this) >>> >>> Feedback? >>> Unless I hear otherwise, I will apply the changes in a week from now. >>> >>> Thanks Dan for helping on this issue. >>> >>> Regards, Benoit >>> >>> Hi, >>> >>> >>> >>> The mib security boilerplate changed in December of 2011, following >>> >>> discussion between the OPS and Security ADs and the MIB Doctors. >>> >>> >>> >>> IIRC, we always made implementation of SNMPv3 recommended but not required. >>> >>> No MIB module (except those specifically related to managing SNMPv3) >>> >>> should require SNMPv3 to work. >>> >>> Any MIB theoretically should work with any version of SNMP (given known >>> >>> interoperability issues of SNMPv1 vs SMIv2, etc.). >>> >>> Theoretically (and according to IAB recommendations in RFC1052), the MIB >>> >>> should also be able to work with protocols other than SNMP, since "The >>> >>> MIB" is just a database that (theoretically) is independent of the >>> >>> protocol used to access it. >>> >>> So no MIB module (with exceptions) should REQUIRE a specific protocol or >>> >>> protocol version to access it. >>> >>> (yawn. I'm sure you guys are tired of hearing this from me ;-) >>> >>> >>> >>> We deliberately made RFC3410 Informational to avoid downrefs. >>> >>> IIRC, you cannot implement RFC3410 because it doesn't define a protocol; >>> >>> it's just a roadmap. >>> >>> >>> >>> SNMPv3 was designed as something of a framework that could be built from >>> >>> multiple pieces - a messaging model, a security model, an ACM model, etc. >>> >>> RFC3411 ***describes*** an architecture suitable for SNMPv3 usage, but it >>> >>> was definitely an SNMPv3 WG decision that this was AN architecture, not >>> >>> THE architecture for SNMPv3, to allow for alternative approaches (such as >>> >>> ISMS work on transport models) and to allow for implementation-specific >>> >>> decisions that would not affect the on-the-wire protocol. >>> >>> >>> >>> The 12/2011 security boilerplate makes SNMPv3 support a MUST, which would >>> >>> make the defining SNMPv3 RFCs Normative (otherwise it is ambiguous which >>> >>> RFCs actually make up SNMPv3, and are MUST implement). >>> >>> But that seems to fly in the face of the SNMPv3 WG intention to NOT make a >>> >>> certain set of RFCs **THE** SNMPv3 definition. >>> >>> (Of course, the IESG approved an IETF Standard called SNMPv3, which >>> >>> contained the RFC34xx series as a set of RFCs within the somewhat-abstract >>> >>> SNMPv3 Standard, to ensure base interoperability.) >>> >>> >>> >>> I think if SNMPv3 is a MUST, the boilerplate should spell out which RFCs >>> >>> MUST be implemented, and make those references normative. >>> >>> I.e., what you would be doing is defining THE set of RFCs that define >>> >>> SNMPv3. >>> >>> >>> >>> I personally think it best not to require a specific version of SNMP as >>> >>> part of the boilerplate for a MIB module. >>> >>> >>> >>> >>> >>> -- >>> >>> David Harrington >>> >>> Ietfdbh@comcast.net >>> >>> +1-603-828-1401 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 1/2/13 7:52 AM, "Bert Wijnen" wrote: >>> >>> >>> >>> RFC3410 is an informational document and has ALWAYS been >>> >>> listed as informational. >>> >>> So... if you make it Normative, you have a >>> >>> downref. >>> >>> The 3414 and 3826 might be listed as Normative. >>> >>> >>> >>> The otehr 3 are only listed as MAY implement. So would it then >>> >>> have to be normative? >>> >>> >>> >>> For me the most important thing is that the pointers to all >>> >>> this >>> >>> documents are listed, so you can quickly find >>> >>> them. >>> >>> >>> >>> Bert >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: >>> >>> Benoit Claise >>> >>> >>> >>> To:ops-dir@ietf.org ; MIB Doctors >>> >>> (E-mail) >>> >>> Cc:adslmib-chairs@ietf.org ; Lynne >>> >>> Bartholomew ; Edward Beili >>> >>> ; Moti Morgenstern >>> >>> >>> >>> Sent: Wednesday, January 02, 2013 12:33 >>> >>> PM >>> >>> Subject: [MIB-DOCTORS] Security >>> >>> Guidelines for IETF MIB Modules: normative or informative references? >>> >>> >>> >>> Dear all, >>> >>> >>> >>> In the AUTH48 process for >>> >>> draft-ietf-adslmib-gbond-mib-11.txt >>> >>> (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi >>> >>> b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), >>> >>> we discussed with the RFC editor whether the following RFCs should be >>> >>> normative or informative: >>> >>> Implementations MUST provide the security features described by the >>> >>> SNMPv3 framework (see [RFC3410]), including full support for >>> >>> authentication and privacy via the User-based Security Model (USM) >>> >>> [RFC3414] with the AES cipher algorithm [RFC3826].I thought that they >>> >>> should be normative, based on the justification at >>> >>> http://www.ietf.org/iesg/statement/normative-informative.html >>> >>> Normative references specify documents that must be read to >>> >>> understand or implement the technology in the new RFC, or whose >>> >>> technology >>> >>> must be present for the technology in the new RFC to work. >>> >>> >>> >>> The >>> >>> RFC editors answered: >>> >>> >>> >>> Thank you for the email. We see your point and agree that it >>> >>> makes sense that the references would be listed as normative, but we >>> >>> do not >>> >>> make calls on which documents are listed as informative vs normative. >>> >>> We note that >>> >>> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists >>> >>> the six references in question -- RFCs 3410, 3414, 3826, 5591, 5592, >>> >>> and 6353 -- as informative. Please request that the wiki >>> >>> be >>> >>> updated, if necessary. >>> >>> >>> >>> >>> >>> So normative or informative >>> >>> references? >>> >>> Shall I update the WIKI? >>> >>> >>> >>> Regards, Benoit >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ________________________________________ >>> >>> >>> >>> _______________________________________________ >>> >>> MIB-DOCTORS mailing >>> >>> list >>> >>> MIB-DOCTORS@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> OPS-DIR mailing list >>> >>> OPS-DIR@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/ops-dir >>> >>> >>> >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> OPS-DIR mailing list >> OPS-DIR@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-dir > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From bclaise@cisco.com Wed Jan 16 03:12:13 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF13F21F8C74; Wed, 16 Jan 2013 03:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 i7xz1cIsQ9hy; Wed, 16 Jan 2013 03:12:11 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3821F854D; Wed, 16 Jan 2013 03:11:40 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0GAbcMF017655; Wed, 16 Jan 2013 11:37:38 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0GAalHW029523; Wed, 16 Jan 2013 11:37:10 +0100 (CET) Message-ID: <50F682BF.4060904@cisco.com> Date: Wed, 16 Jan 2013 11:36:47 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <50EC3ACB.8050100@cisco.com> <025001cdede4$ba097200$2e1c5600$@comcast.net> <50ED75A3.30605@cisco.com> <50F672E2.9050600@cisco.com> <50F67F6B.5070007@bwijnen.net> In-Reply-To: <50F67F6B.5070007@bwijnen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "'MIB Doctors \(E-mail\)'" , ops-dir@ietf.org, Lynne Bartholomew , 'Bert Wijnen' Subject: Re: [MIB-DOCTORS] [OPS-DIR] Security Guidelines for IETF MIB Modules: normative or informative references? X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 11:12:13 -0000 On 16/01/2013 11:22, Bert Wijnen (IETF) wrote: > SO I guess this means that all MIB documents in progress need to be > updated with this new text too. Yes. And the RFC editors have been warned. This is actually the RFC editors who checked the consistency with https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security Regards, Benoit > > Bert > > On 1/16/13 10:29 AM, Benoit Claise wrote: >> Hi, >> >> The deadline is now passed. >> I received the green light from the two security ADs. >> Therefore https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security >> has been updated. >> And the 4 ADLSMIB documents will now progress. >> >> Regards, Benoit >>> Hi David, >>>> >>>> Hi Benoit, >>>> >>>> Unless it is an SNMPv3-specific MIB module, a MIB module will >>>> usually not be broken by using SNMPv1 or SNMPv2. >>>> >>>> And, a MIB module typically will not be broken by the use of SNMPv3 >>>> with a security model other than USM with AES. >>>> >>>> And, a MIB module will not be broken by using a protocol other than >>>> SNMP. >>>> >>>> Hence, I think that MUST is being used inappropriately when the >>>> boilerplate says SNMPv3 MUST be supported for a particular MIB >>>> module. >>>> >>>> I think what we really want to say is that we RECOMMEND SNMPv3 – >>>> for purposes of security – with USM/AES for purposes of >>>> interoperability. >>>> >>>> I recommend the text read: >>>> >>>> Implementations_SHOULD_ provide the security features >>>> described by the >>>> SNMPv3 framework (see [RFC3410]),_and implementations claiming >>>> compliance to the SNMPv3 standard_ MUST include full support for >>>> authentication and privacy via the User-based Security Model (USM) >>>> [RFC3414] with the AES cipher algorithm [RFC3826]. >>> That would be in the spirit of your proposition. Fine with me. >>> >>> Regards, Benoit >>>> >>>> Of course, it can be debated whether every MIB module document >>>> should include compliance requirements for ONE of the protocols >>>> that COULD be used to access the MIB. >>>> If we are going to add SNMPv3-compliance requirements to every MIB >>>> document, and syslog and netconf and ipfix and others can also be >>>> used to carry the data described in the MIB module, should we >>>> include compliance requirements for specific versions of the syslog >>>> protocol, the netconf protocol, the ipfix protocol, and so on in >>>> the MIB boilerplate as well? >>>> >>>> >>>> As one of the developers of SNMPv3, I certainly would like to see >>>> it implemented, but I think this boilerplate is being heavy >>>> handed by saying, in every IETF MIB module published, that >>>> SNMPv3+USM+AES MUST be supported. >>>> >>>> The original MIB boilerplate combination said SNMP was typically >>>> used for carrying MIB data, and version 3 of SNMP was >>>> RECOMMENDED because of its security properties. That makes sense to >>>> me. The MUST does not. >>>> >>>> That said, I am fine with the current boilerplate if that’s what >>>> the IESG wants; I just think it’s not very accurate. >>>> >>>> David Harrington >>>> >>>> ietfdbh@comcast.net >>>> >>>> +1-603-828-1401 >>>> >>>> *From:*Benoit Claise [mailto:bclaise@cisco.com] >>>> *Sent:* Tuesday, January 08, 2013 10:27 AM >>>> *To:* David Harrington >>>> *Cc:* Bert Wijnen; ops-dir@ietf.org; MIB Doctors (E-mail); Lynne >>>> Bartholomew >>>> *Subject:* Re: [OPS-DIR] [MIB-DOCTORS] Security Guidelines for IETF >>>> MIB Modules: normative or informative references? >>>> >>>> Hi Dave, >>>> >>>> I understand your argument, and I tend to agree with you. >>>> >>>> The problem statement is: the following sentence is kind of broken >>>> , because RFC 3414 and RFC 3826 are informative references; >>>> >>>> Implementations MUST provide the security features described by >>>> the >>>> SNMPv3 framework (see [RFC3410]), including full support for >>>> authentication and privacy via the User-based Security Model (USM) >>>> [RFC3414] with the AES cipher algorithm [RFC3826]. >>>> >>>> >>>> There are two things we can do >>>> >>>> 1. do nothing, because it's not worth it. >>>> >>>> 2. Correct the sentence >>>> >>>> OLD (the 3 paragraphs are copied for completeness, while only the >>>> second and third one are changed): >>>> >>>> SNMP versions prior to SNMPv3 did not include adequate security. >>>> Even if the network itself is secure (for example by using IPsec), >>>> there is no control as to who on the secure network is >>>> allowed to access and GET/SET (read/change/create/delete) the >>>> objects >>>> in this MIB module. >>>> >>>> Implementations MUST provide the security features described by >>>> the >>>> SNMPv3 framework (see [RFC3410]), including full support for >>>> authentication and privacy via the User-based Security Model (USM) >>>> [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations >>>> MAY also provide support for the Transport Security Model (TSM) >>>> [RFC5591] in combination with a secure transport such as SSH >>>> [RFC5592] or TLS/DTLS [RFC6353]. >>>> >>>> Further, deployment of SNMP versions prior to SNMPv3 is NOT >>>> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >>>> enable cryptographic security. It is then a customer/operator >>>> responsibility to ensure that the SNMP entity giving access to an >>>> instance of this MIB module is properly configured to give >>>> access to >>>> the objects only to those principals (users) that have legitimate >>>> rights to indeed GET or SET (change/create/delete) them. >>>> >>>> NEW: >>>> >>>> SNMP versions prior to SNMPv3 did not include adequate security. >>>> Even if the network itself is secure (for example by using IPsec), >>>> there is no control as to who on the secure network is >>>> allowed to access and GET/SET (read/change/create/delete) the >>>> objects >>>> in this MIB module. >>>> Implementations MUST provide the security features described by >>>> the >>>> SNMPv3 framework (see [RFC3410])._When implementing SNMPv3, >>>> full support for_ >>>> _ authentication and privacy via the User-based Security Model >>>> (USM)_ >>>> _ [RFC3414] with the AES cipher algorithm [RFC3826] is >>>> RECOMMENDED._ >>>> Implementations MAY also provide support for the Transport >>>> Security Model (TSM) >>>> [RFC5591] in combination with a secure transport such as SSH >>>> [RFC5592] or TLS/DTLS [RFC6353]. >>>> Further, deployment of SNMP versions prior to SNMPv3 is NOT >>>> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >>>> enable cryptographic security. It is then a customer/operator >>>> responsibility to ensure that the SNMP entity giving access to an >>>> instance of this MIB module is properly configured to give >>>> access to >>>> the objects only to those principals (users) that have legitimate >>>> rights to indeed GET or SET (change/create/delete) them. >>>> >>>> And we move the following references from informative to normative >>>> >>>> [RFC3414] Blumenthal, U., and B. Wijnen, >>>> "User-based Security Model (USM) for version 3 of the >>>> Simple Network Management Protocol (SNMPv3)", RFC 3414, >>>> December 2002. >>>> >>>> [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, >>>> "The Advanced Encryption Standard (AES) Cipher >>>> Algorithm in the SNMP User-based Security Model", >>>> RFC 3826, June 2004. >>>> [RFC5591] Harrington, D., and W. Hardaker, >>>> "Transport Security Model for the Simple Network >>>> Management Protocol (SNMP)", June 2009. >>>> >>>> [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, >>>> "Secure Shell Transport Model for the Simple Network >>>> Management Protocol (SNMP)", June 2009. >>>> >>>> [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport >>>> Model for the Simple Network Management Protocol >>>> (SNMP)", >>>> July 2011. >>>> >>>> >>>> I want to go for solution 2. If we redo the full discussion, and >>>> the discussion goes nowhere, I'll go for solution 1 (I have a >>>> few documents in AUTH48 waiting on this) >>>> >>>> Feedback? >>>> Unless I hear otherwise, I will apply the changes in a week from now. >>>> >>>> Thanks Dan for helping on this issue. >>>> >>>> Regards, Benoit >>>> >>>> Hi, >>>> >>>> >>>> >>>> The mib security boilerplate changed in December of 2011, >>>> following >>>> >>>> discussion between the OPS and Security ADs and the MIB Doctors. >>>> >>>> >>>> >>>> IIRC, we always made implementation of SNMPv3 recommended but >>>> not required. >>>> >>>> No MIB module (except those specifically related to managing >>>> SNMPv3) >>>> >>>> should require SNMPv3 to work. >>>> >>>> Any MIB theoretically should work with any version of SNMP >>>> (given known >>>> >>>> interoperability issues of SNMPv1 vs SMIv2, etc.). >>>> >>>> Theoretically (and according to IAB recommendations in >>>> RFC1052), the MIB >>>> >>>> should also be able to work with protocols other than SNMP, >>>> since "The >>>> >>>> MIB" is just a database that (theoretically) is independent of the >>>> >>>> protocol used to access it. >>>> >>>> So no MIB module (with exceptions) should REQUIRE a specific >>>> protocol or >>>> >>>> protocol version to access it. >>>> >>>> (yawn. I'm sure you guys are tired of hearing this from me ;-) >>>> >>>> >>>> >>>> We deliberately made RFC3410 Informational to avoid downrefs. >>>> >>>> IIRC, you cannot implement RFC3410 because it doesn't define a >>>> protocol; >>>> >>>> it's just a roadmap. >>>> >>>> >>>> >>>> SNMPv3 was designed as something of a framework that could be >>>> built from >>>> >>>> multiple pieces - a messaging model, a security model, an ACM >>>> model, etc. >>>> >>>> RFC3411 ***describes*** an architecture suitable for SNMPv3 >>>> usage, but it >>>> >>>> was definitely an SNMPv3 WG decision that this was AN >>>> architecture, not >>>> >>>> THE architecture for SNMPv3, to allow for alternative >>>> approaches (such as >>>> >>>> ISMS work on transport models) and to allow for >>>> implementation-specific >>>> >>>> decisions that would not affect the on-the-wire protocol. >>>> >>>> >>>> >>>> The 12/2011 security boilerplate makes SNMPv3 support a MUST, >>>> which would >>>> >>>> make the defining SNMPv3 RFCs Normative (otherwise it is >>>> ambiguous which >>>> >>>> RFCs actually make up SNMPv3, and are MUST implement). >>>> >>>> But that seems to fly in the face of the SNMPv3 WG intention to >>>> NOT make a >>>> >>>> certain set of RFCs **THE** SNMPv3 definition. >>>> >>>> (Of course, the IESG approved an IETF Standard called SNMPv3, >>>> which >>>> >>>> contained the RFC34xx series as a set of RFCs within the >>>> somewhat-abstract >>>> >>>> SNMPv3 Standard, to ensure base interoperability.) >>>> >>>> >>>> >>>> I think if SNMPv3 is a MUST, the boilerplate should spell out >>>> which RFCs >>>> >>>> MUST be implemented, and make those references normative. >>>> >>>> I.e., what you would be doing is defining THE set of RFCs that >>>> define >>>> >>>> SNMPv3. >>>> >>>> >>>> >>>> I personally think it best not to require a specific version of >>>> SNMP as >>>> >>>> part of the boilerplate for a MIB module. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> David Harrington >>>> >>>> Ietfdbh@comcast.net >>>> >>>> +1-603-828-1401 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 1/2/13 7:52 AM, "Bert Wijnen" >>>> wrote: >>>> >>>> >>>> >>>> RFC3410 is an informational document and has ALWAYS been >>>> >>>> listed as informational. >>>> >>>> So... if you make it Normative, you have a >>>> >>>> downref. >>>> >>>> The 3414 and 3826 might be listed as Normative. >>>> >>>> >>>> >>>> The otehr 3 are only listed as MAY implement. So would it then >>>> >>>> have to be normative? >>>> >>>> >>>> >>>> For me the most important thing is that the pointers to all >>>> >>>> this >>>> >>>> documents are listed, so you can quickly find >>>> >>>> them. >>>> >>>> >>>> >>>> Bert >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: >>>> >>>> Benoit Claise >>>> >>>> >>>> >>>> >>>> To:ops-dir@ietf.org ; MIB Doctors >>>> >>>> (E-mail) >>>> >>>> >>>> Cc:adslmib-chairs@ietf.org >>>> ; Lynne >>>> >>>> Bartholomew >>>> ; Edward Beili >>>> >>>> >>>> ; Moti Morgenstern >>>> >>>> >>>> >>>> >>>> Sent: Wednesday, January 02, 2013 12:33 >>>> >>>> PM >>>> >>>> Subject: [MIB-DOCTORS] Security >>>> >>>> Guidelines for IETF MIB Modules: normative or informative >>>> references? >>>> >>>> >>>> >>>> Dear all, >>>> >>>> >>>> >>>> In the AUTH48 process for >>>> >>>> draft-ietf-adslmib-gbond-mib-11.txt >>>> >>>> (https://datatracker.ietf.org/doc/search/?name=draft-ietf-adslmib-gbond-mi >>>> >>>> b&rfcs=on&activeDrafts=on&author=&group=&area=&ad=&state=&subState=), >>>> >>>> we discussed with the RFC editor whether the following >>>> RFCs should be >>>> >>>> normative or informative: >>>> >>>> Implementations MUST provide the security features >>>> described by the >>>> >>>> SNMPv3 framework (see [RFC3410]), including full support >>>> for >>>> >>>> authentication and privacy via the User-based Security >>>> Model (USM) >>>> >>>> [RFC3414] with the AES cipher algorithm [RFC3826].I >>>> thought that they >>>> >>>> should be normative, based on the justification at >>>> >>>> http://www.ietf.org/iesg/statement/normative-informative.html >>>> >>>> Normative references specify documents that must be read to >>>> >>>> understand or implement the technology in the new RFC, >>>> or whose >>>> >>>> technology >>>> >>>> must be present for the technology in the new RFC to work. >>>> >>>> >>>> >>>> The >>>> >>>> RFC editors answered: >>>> >>>> >>>> >>>> Thank you for the email. We see your point and agree >>>> that it >>>> >>>> makes sense that the references would be listed as >>>> normative, but we >>>> >>>> do not >>>> >>>> make calls on which documents are listed as informative >>>> vs normative. >>>> >>>> We note that >>>> >>>> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security lists >>>> >>>> the six references in question -- RFCs 3410, 3414, >>>> 3826, 5591, 5592, >>>> >>>> and 6353 -- as informative. Please request that the wiki >>>> >>>> be >>>> >>>> updated, if necessary. >>>> >>>> >>>> >>>> >>>> >>>> So normative or informative >>>> >>>> references? >>>> >>>> Shall I update the WIKI? >>>> >>>> >>>> >>>> Regards, Benoit >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> MIB-DOCTORS mailing >>>> >>>> list >>>> >>>> MIB-DOCTORS@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OPS-DIR mailing list >>>> >>>> OPS-DIR@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/ops-dir >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> OPS-DIR mailing list >>> OPS-DIR@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-dir >> >> >> >> _______________________________________________ >> OPS-DIR mailing list >> OPS-DIR@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-dir >> > > From bclaise@cisco.com Mon Jan 21 14:07:17 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49D21F853C for ; Mon, 21 Jan 2013 14:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dCv+pVptjTCs for ; Mon, 21 Jan 2013 14:07:11 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 93FDB21F8536 for ; Mon, 21 Jan 2013 14:06:57 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LM6uUT020128; Mon, 21 Jan 2013 23:06:56 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LM6Gcr000414; Mon, 21 Jan 2013 23:06:27 +0100 (CET) Message-ID: <50FDBBD8.60806@cisco.com> Date: Mon, 21 Jan 2013 23:06:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica Subject: [MIB-DOCTORS] MIB doctors WIKI/page clean up X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 22:07:17 -0000 Dear all, There were actually (too) many MIB doctors pages/WIKIs - http://www.ietf.org/iesg/directorate/mib-doctors.html - http://trac.tools.ietf.org/area/ops/trac/wiki - http://trac.tools.ietf.org/group/iesg/trac/wiki/MibDoctor There were mistakes in link. For example: with a link to http://www.ops.ietf.org/mib-doctors.html which gets redirected to http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors.html, which does not exist. There were discrepancies in the MIB doctors list on the different pages. I did a little bit of clean up http://www.ietf.org/iesg/directorate/mib-doctors.html is now the primary page Some more information can be found at http://trac.tools.ietf.org/area/ops/trac/wiki, as indicated on this page Note that I made sure that all references from RFC 4181 are still alive. Please update your bookmark, and double-check the page, in case I missed something Regards, Benoit From bclaise@cisco.com Mon Jan 21 15:24:39 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216421F871D for ; Mon, 21 Jan 2013 15:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qZyeNOc7tTHl for ; Mon, 21 Jan 2013 15:24:34 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FF21F868F for ; Mon, 21 Jan 2013 15:23:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LMiI0A023518; Mon, 21 Jan 2013 23:44:18 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0LMgMKX019639; Mon, 21 Jan 2013 23:42:52 +0100 (CET) Message-ID: <50FDC44E.5050100@cisco.com> Date: Mon, 21 Jan 2013 23:42:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Harrington References: <00f101cdf336$889656f0$99c304d0$@comcast.net> In-Reply-To: <00f101cdf336$889656f0$99c304d0$@comcast.net> Content-Type: multipart/alternative; boundary="------------000002060609000107070602" Cc: keyupate@cisco.com, michael.baer@sparta.com, MIB Doctors , draft-ietf-sidr-rpki-rtr-protocol-mib@tools.ietf.org, randy@psg.com, adrian@olddog.co.uk, stbryant@cisco.com Subject: Re: [MIB-DOCTORS] MIB Doctor review of draft-ietf-sidr-rpki-rtr-protocol-mib-04 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 23:24:39 -0000 This is a multi-part message in MIME format. --------------000002060609000107070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On top of David's feedback, here is mine. - http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-26 is now RFC 6810 - Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. -> 2013 - rpkiRtrCacheServerPreference OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The routers' preference for this RPKI cache server. A lower value means more preferred. If two entries have the same preference, then the order is arbitrary. If no order is specified in the configuration then this value is set to 255." I don't understand the sentence: If no order is specified in the configuration then this value is set to 255." Configuration of what? This is misleading as this is a non read-write (monitoring) MIB module. Do you mean a config knob in RFC 6810? Please specify. - - rpkiRtrCacheServerTimeToRefresh OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of seconds remaining before a new refresh is performed via a Serial Query to this cache server over this connection. A negative value means that the refresh time has passed this many seconds and the refresh has not yet been completed. Upon a completed refresh (i.e. a successful and complete response to a Serial Query) the value of this attribute will be re-initialized with the value of the corresponding rpkiRtrCacheServerRefreshTimer attribute." A reference to RFC 6810 section 5.3 would be useful (as flagged by David) - Clarifying question: rpkiRtrPrefixOriginTableEntry OBJECT-TYPE SYNTAX RpkiRtrPrefixOriginTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the rpkiRtrPrefixOriginTable. This represents one announced prefix." INDEX { rpkiRtrPrefixOriginAddressType, rpkiRtrPrefixOriginAddress, rpkiRtrPrefixOriginMinLength } ::= { rpkiRtrPrefixOriginTable 1 } This table gives the link to the unique ID of the connection with rpkiRtrPrefixOriginCacheServerId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The unique ID of the connection to the cache server from which this announcement was received. That connection is identified/found by a matching value in attribute rpkiRtrCacheServerId." ::= { rpkiRtrPrefixOriginTableEntry 6 } Am I assuming correctly that we can only receive a (addressType, address, minLength) from one and only one connection? Regards, Benoit > Hi, > > Been a while since I've done one of these ;-) > > A few comments: > > This review is officially done for the OPS AD, and the AD needs to > decide which points must be addressed. > > Most of the comments should be non-controversial and easy to address. > > There are a couple syntax questions. > > Most technical questions are about ensuring clear and unambiguous > descriptions to ensure interoperability. > > I noticed that a MIB is not listed in the sidr charter, but this is a > sidr document. > > I guess one could raise the point that development of an RPKI MIB has > not been "sanctioned" by the general IETF during WG charter review. > > As a MIB Doctor, I of course think it's a reasonably good idea, > assuming MIB management of this routing security functionality is a > good fit. > > I assume the WG does, and the IETF will. > > I don't know if the OPS AD cares (or the RTG ADs care). Their business. > > Is LAST-UPDATED "201110140000Z" still correct? > > We've crossed a year boundary, so the 2012 copyright might need updating. > > RpkiRtrConnectionType/other: s/non/none > > rpkiRtrCacheServerConnectionType: to prevent any ambiguity, I think it > might be better to describe this only as the connection type, and > remove the "or transport security suite" from the object description. > The fact that the connection type might be a transport security suite > can be spelled out in the connection type T-C. Even there, I would be > careful of ambiguity, to provide clear guidance/constraints to future > developers of added enumerations. > > rpkiRtrCacheServerPreference: would a DEFVAL be a good idea to specify > the 255 default? > > rpkiRtrCacheServerTimeToRefresh could benefit from a reference. Is the > time to refresh always decremented by 1, or can an implementation > choose to only reflect time to refresh in, say, 5 or 10 second > increments? Is there a maximum negative value that makes sense here? > Is it possible to require a wrap if no refresh is completed? Or should > the value latch at the maximum negative value? > > rpkiRtrCacheServerId would benefit from a reference. > > rpkiRtrCacheServerId value is used as a relation between tables. What > are the fate-sharing requirements? Must a corresponding > rpkiRtrPrefixOriginCacheServerId exist? Or if > rpkiRtrPrefixOriginCacheServerId exists, must a corresponding > rpkiRtrCacheServerId exist? If one entry is deleted, must the > corresponding entry be deleted to prevent one table from reusing an > identifier that is still in use in the other table? > > s/debuging/debugging/ > > The Errors table contains counters that represent "the number of XXX > errors received." This description seems to indicate that counters > start at zero (and implicitly reset to zero on a discontinuity). An > NMS developer certainly might interpret this text as indicating > zero-based counters. I think if there is an assumption these are > zero-based, there are TC-s that could be used to show that assumption. > OTOH, counters typically are not zero-based because if errors occur > during system startup, the counter might be initialized partway > through the startup and not reflect all the errors that occurred > during the startup phase. I think this table would benefit from a > discussion of the expected initial values (zero or > unpredictable/implementation-dependent) and the nature of expected > discontinuities, so NMS developers can be sure to understand the > relevant assumptions. (is the only discontinuity a restart of the > management system? What about rollovers? Are all these error counters > not preserved across system restarts? Or can an implementation choose > to preserve them across resets to enhance debugging history?) Some of > this discussion would seem to apply to all the error counters; if that > is true of all current counters and should be true for an potentially > new counters added to this table, this type of discussion could be > captured in the Table or TableEntry description. (including the > discussion of rpkiRtrDiscontinuityTimer, which seems to apply to the > whole table). > > The errors objects might benefit from a reference to the descriptions > of errors in RPKI specs, so NMS implementors are likely to interpret > the counters consistently. > > And to be clear, these counters count the number of messages from the > cache server reporting a remote error, right? These counters never > count an error (found locally) in a message from the remote server? So > it's not actually the number of errors received, but the number of > server-generated error-reports received? Right? That could be made > slightly clearer. > > The comment discussing ROATable probably isn't needed in the final > document, since no official REVISION included ROATable, right? > > s/recieved/received/ > > rpkiRtrPrefixOriginAddressType: "Only IPv4 and IPv6 are supported." -- > This is an enumeration that could be extended in the future if RPKI > ever supports additional address types (like ipv7 or something); the > limitation of ipv4/ipv6 is presumably a limit set by RPKI; it should > not be a limit set by the MIB object, which could not be updated to > match an updated RPKI. Each of these objects should reference the > current limit in RPKI, and allow for future SMIv2 extensibility of the > enumeration so extending it would not involve obsoleting each object > and defining a new object without limits. By indicating that the > enumeration could legally be extended at some point in the future, NMS > developers can plan accordingly; the current approach could > inadvertently encourage hard-coding support for these, and only these, > two enumeration values. > > From RFC4001: > > "The InetAddressType and InetAddress objects SHOULD NOT be sub-typed > > in object definitions. Sub-typing binds the MIB module to specific > > address formats, which may cause serious problems if new address > > formats need to be introduced. Note that it is possible to write > > compliance statements indicating that only a subset of the defined > > address types must be implemented to be compliant." > > Would putting the limit in a compliance clause rather than the object > description clause work? > > Could RPKI ever be implemented in a non-global environment, where > address zoning might be needed? > > rpkiRtrPrefixOriginAddress says "The format of the address is defined > by the > > value of the corresponding instance of > > rpkiRtrCacheServerAddressType." > > Shouldn't this be rpkiRtrPrefixOriginAddressType? > > rpkiRtrCacheServerConnectionStateChange says: > > "The SNMP agent MUST throttle the generation of > > consecutive rpkiRtrCacheServerConnectionStateChange > > notifications such that there is at least a > > 5 second gap between them." > > A MIB is theoretically separate from the protocol used to carry the > information. What happens if the notification is being reported by > something other than SNMP? Is throttling still required? > > I am a bit concerned by the text that describes throttling generation; > should generation be throttled, or should sending be throttled? The > need to recognize a status change event and request a notification be > sent (i.e., generation) might be handled by the underlying > instrumentation, while sending the notification would seem to be the > purview of the protocol being used (i.e., the SNMP engine). If I have > a down event followed by an up event 2 seconds later, should I not > generate a notification reporting the state change? What if I have no > subsequent up event to report? Should the NMS continue to believe the > state is down? Or should I just queue the up notification for 3 > seconds and then send it? > > (and I realize queuing could just push the excessive generation > problem down the road, AND lead to untimely reports). The current text > is unclear about this and I am concerned whether there might be > interoperability problems caused by differing interpretations of how > to throttle these notifications. I know we require a discussion of > throttling; is this the best way to document the throttling for these > notifications? > > In rpkiRtrReadOnlyCompliance, s/Implemntation/Implementation/ > > While read-write and read-create may not be envisioned, it is probably > incorrect to state that the MIB module contains only read-only objects > without specifying that this is true for the current REVISION. I have > a concern about naming this so generically; what happens if new > read-only objects are added in the future? The new objects cannot be > added to this compliance clause, so the goal of clarity and truth in > advertising will not necessarily hold up. I recommend naming the > compliance clause (possibly using the assigned RFC#) so it is clear > that this list of objects applies to the current REVISION of the MIB > module. > > Are none of the objects in this MIB potentially sensitive to > disclosure? None are listed. > > The MIB security boilerplate references 3414 and 3826. There has been > some discussion of whether these should be considered normative. > > David Harrington > > dbharrington@comcast.net > > +1-603-828-1401 > --------------000002060609000107070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

On top of David's feedback, here is mine.


-
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-26 is now RFC 6810

-
                     Copyright (c) 2011 IETF Trust and the persons
                     identified as authors of the code. All rights
                     reserved.
	-> 2013

- 
   rpkiRtrCacheServerPreference OBJECT-TYPE
       SYNTAX       Unsigned32 (0..255)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The routers' preference for this
                    RPKI cache server.

                    A lower value means more preferred. If two
                    entries have the same preference, then the
                    order is arbitrary.

                    If no order is specified in the configuration
                    then this value is set to 255."

I don't understand the sentence:
		    If no order is specified in the configuration
                    then this value is set to 255."
Configuration of what? This is misleading as this is a non read-write (monitoring) MIB module.
Do you mean a config knob in RFC 6810? Please specify.

-
- 
rpkiRtrCacheServerTimeToRefresh OBJECT-TYPE
       SYNTAX       Integer32
       UNITS       "seconds"
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of seconds remaining before a new
                    refresh is performed via a Serial Query to
                    this cache server over this connection.

                    A negative value means that the refresh time
                    has passed this many seconds and the refresh
                    has not yet been completed.

                    Upon a completed refresh (i.e. a successful
                    and complete response to a Serial Query) the
                    value of this attribute will be re-initialized
                    with the value of the corresponding
                    rpkiRtrCacheServerRefreshTimer attribute."


A reference to RFC 6810 section 5.3 would be useful (as flagged by David)

- 
Clarifying question:
   rpkiRtrPrefixOriginTableEntry OBJECT-TYPE
       SYNTAX       RpkiRtrPrefixOriginTableEntry
       MAX-ACCESS   not-accessible
       STATUS       current
       DESCRIPTION "An entry in the rpkiRtrPrefixOriginTable.
                    This represents one announced prefix."
       INDEX       { rpkiRtrPrefixOriginAddressType,
                     rpkiRtrPrefixOriginAddress,
                     rpkiRtrPrefixOriginMinLength
                   }
       ::= { rpkiRtrPrefixOriginTable 1 }


This table gives the link to the unique ID of the connection with 

   rpkiRtrPrefixOriginCacheServerId OBJECT-TYPE
       SYNTAX       Unsigned32 (1..4294967295)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The unique ID of the connection to the cache
                    server from which this announcement was received.
                    That connection is identified/found by a matching
                    value in attribute rpkiRtrCacheServerId."
       ::= { rpkiRtrPrefixOriginTableEntry 6 }

Am I assuming correctly that we can only receive a (addressType, address, minLength) from one and only one connection?
Regards, Benoit

Hi,

 

Been a while since I’ve done one of these ;-)

A few comments:

 

This review is officially done for the OPS  AD, and the AD needs to decide which points must be addressed.

Most of the comments should be non-controversial and easy to address.

There are a couple syntax questions.

Most technical questions are about ensuring clear and unambiguous descriptions to ensure interoperability.

 

I noticed that a MIB is not listed in the sidr charter, but this is a sidr document.

I guess one could raise the point that development of an RPKI MIB has not been “sanctioned” by the general IETF during WG charter review.

As a MIB Doctor, I of course think it’s a reasonably good idea, assuming MIB management of this routing security functionality is a good fit.

I assume the WG does, and the IETF will.

I don’t know if the OPS AD cares (or the RTG ADs care). Their business.

 

Is LAST-UPDATED "201110140000Z" still correct?

 

We’ve crossed a year boundary, so the 2012 copyright might need updating.

 

RpkiRtrConnectionType/other: s/non/none

 

rpkiRtrCacheServerConnectionType: to prevent any ambiguity, I think it might be better to describe this only as the connection type, and remove the “or transport security suite” from the object description. The fact that the connection type might be a transport security suite can be spelled out in the connection type T-C. Even there, I would be careful of ambiguity, to provide clear guidance/constraints to future developers of added enumerations.

 

rpkiRtrCacheServerPreference: would a DEFVAL be a good idea to specify the 255 default?

 

rpkiRtrCacheServerTimeToRefresh could benefit from a reference. Is the time to refresh always decremented by 1, or can an implementation choose to only reflect time to refresh in, say, 5 or 10 second increments? Is there a maximum negative value that makes sense here? Is it possible to require a wrap if no refresh is completed? Or should the value latch at the maximum negative value?

 

rpkiRtrCacheServerId would benefit from a reference.

 

rpkiRtrCacheServerId value is used as a relation between tables. What are the fate-sharing requirements? Must a corresponding rpkiRtrPrefixOriginCacheServerId  exist? Or if rpkiRtrPrefixOriginCacheServerId  exists, must a corresponding rpkiRtrCacheServerId exist? If one entry is deleted, must the corresponding entry be deleted to prevent one table from reusing an identifier that is still in use in the other table?

 

s/debuging/debugging/

 

The Errors table contains counters that represent “the number of XXX errors received.” This description seems to indicate that counters start at zero (and implicitly reset to zero on a discontinuity). An NMS developer certainly might interpret this text as indicating zero-based counters. I think if there is an assumption these are zero-based, there are TC-s that could be used to show that assumption. OTOH, counters typically are not zero-based because if errors occur during system startup, the counter might be initialized partway through the startup and not reflect all the errors that occurred during the startup phase. I think this table would benefit from a discussion of the expected initial values (zero or unpredictable/implementation-dependent) and the nature of expected discontinuities, so NMS developers can be sure to understand the relevant assumptions.  (is the only discontinuity a restart of the management system? What about rollovers? Are all these error counters not preserved across system restarts? Or can an implementation choose to preserve them across resets to enhance debugging history?) Some of this discussion would seem to apply to all the error counters; if that is true of all current counters and should be true for an potentially new counters added to this table, this type of discussion could be captured in the Table or TableEntry description. (including the discussion of rpkiRtrDiscontinuityTimer, which seems to apply to the whole table).

 

The errors objects might benefit from a reference to the descriptions of errors in RPKI specs, so NMS implementors are likely to interpret the counters consistently.

 

And to be clear, these counters count the number of messages from the cache server reporting a remote error, right? These counters never count an error (found locally) in a message from the remote server? So it’s not actually the number of errors received, but the number of server-generated error-reports received? Right? That could be made slightly clearer.

 

The comment discussing ROATable probably isn’t needed in the final document, since no official REVISION included ROATable, right?

 

s/recieved/received/

 

rpkiRtrPrefixOriginAddressType: “Only IPv4 and IPv6 are supported.” – This is an enumeration that could be extended in the future if RPKI ever supports additional address types (like ipv7 or something); the limitation of ipv4/ipv6 is presumably a limit set by RPKI; it should not be a limit set by the MIB object, which could not be updated to match an updated RPKI. Each of these objects should reference the current limit in RPKI, and allow for future SMIv2 extensibility of the enumeration so extending it would not involve obsoleting each object and defining a new object without limits. By indicating that the enumeration could legally be extended at some point in the future, NMS developers can plan accordingly; the current approach could inadvertently encourage hard-coding support for these, and only these, two enumeration values.

From RFC4001:

“The InetAddressType and InetAddress objects SHOULD NOT be sub-typed

   in object definitions.  Sub-typing binds the MIB module to specific

   address formats, which may cause serious problems if new address

   formats need to be introduced.  Note that it is possible to write

   compliance statements indicating that only a subset of the defined

   address types must be implemented to be compliant.”

Would putting the limit in a compliance clause rather than the object description clause work?

 

Could RPKI ever be implemented in a non-global environment, where address zoning might be needed?

 

rpkiRtrPrefixOriginAddress  says “The format of the address is defined by the

                    value of the corresponding instance of

                    rpkiRtrCacheServerAddressType."

Shouldn’t this be rpkiRtrPrefixOriginAddressType?

 

rpkiRtrCacheServerConnectionStateChange says:

“                   The SNMP agent MUST throttle the generation of

                    consecutive rpkiRtrCacheServerConnectionStateChange

                    notifications such that there is at least a

                    5 second gap between them.”

A MIB is theoretically separate from the protocol used to carry the information. What happens if the notification is being reported by something other than SNMP? Is throttling still required?

 

I am a bit concerned by the text that describes throttling generation; should generation be throttled, or should sending be throttled? The need to recognize a status change event and request a notification be sent (i.e., generation) might be handled by the underlying instrumentation, while sending the notification would seem to be the purview of the protocol being used (i.e., the SNMP engine). If I have a down event followed by an up event 2 seconds later, should I not generate a notification reporting the state change? What if I have no subsequent up event to report? Should the NMS continue to believe the state is down? Or should I just queue the up notification for 3 seconds and then send it?

(and I realize queuing could just push the excessive generation problem down the road, AND lead to untimely reports). The current text is unclear about this and I am concerned whether there might be interoperability problems caused by differing interpretations of how to throttle these notifications. I know we require a discussion of throttling; is this the best way to document the throttling for these notifications?

 

In rpkiRtrReadOnlyCompliance, s/Implemntation/Implementation/

While read-write and read-create may not be envisioned, it is probably incorrect to state that the MIB module contains only read-only objects without specifying that this is true for the current REVISION. I have a concern about naming this so generically; what happens if new read-only objects are added in the future? The new objects cannot be added to this compliance clause, so the goal of clarity and truth in advertising will not necessarily hold up. I recommend naming the compliance clause (possibly using the assigned RFC#) so it is clear that this list of objects applies to the current REVISION of the MIB module.

 

Are none of the objects in this MIB potentially sensitive to disclosure? None are listed.

 

The MIB security boilerplate references 3414 and 3826. There has been some discussion of whether these should be considered normative.

 

 

David Harrington

dbharrington@comcast.net

+1-603-828-1401


--------------000002060609000107070602-- From prvs=87339ecd79=rraghu@ciena.com Mon Jan 21 15:42:43 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387A521F8815 for ; Mon, 21 Jan 2013 15:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 Ca6g4l2L8Lfr for ; Mon, 21 Jan 2013 15:42:42 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6373A21F8800 for ; Mon, 21 Jan 2013 15:42:42 -0800 (PST) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id r0LNeXv9005615; Mon, 21 Jan 2013 18:42:37 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1a1fhmr07y-17 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Jan 2013 18:42:37 -0500 Received: from MDWEXGMB01.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Mon, 21 Jan 2013 18:42:13 -0500 From: "Ranganathan, Raghu" To: Cole , "mib-doctors@ietf.org" , "nan@metroethernetforum.org" , "mike.bencheck@verizon.com" Date: Mon, 21 Jan 2013 18:42:12 -0500 Thread-Topic: MEF-UNI-EVC-MIB review Thread-Index: Ac34MLK/purtZDuOTVOz3nC5Jj9QxwAACOGQ Message-ID: <57E88185C94A874D9C01ACFBF7A2819601D89F257A@MDWEXGMB01.ciena.com> References: <50FDD1E5.6060602@comcast.net> In-Reply-To: <50FDD1E5.6060602@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-21_05:2013-01-21, 2013-01-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1301210283 X-Mailman-Approved-At: Mon, 21 Jan 2013 15:54:33 -0800 Cc: Steve Mood Subject: Re: [MIB-DOCTORS] MEF-UNI-EVC-MIB review X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 23:42:43 -0000 Bob: Thanks very much. I will forward this to Steve Mood who is editor of the do= cument. --Raghu -----Original Message----- From: Cole [mailto:rgcole01@comcast.net]=20 Sent: Monday, January 21, 2013 5:40 PM To: mib-doctors@ietf.org; nan@metroethernetforum.org; Ranganathan, Raghu; m= ike.bencheck@verizon.com Subject: MEF-UNI-EVC-MIB review To All: Sorry for the delay in reviewing the MEF-UNI-EVC-MIB. I have attached two = files: a) My review of the MIB including General Comments upfront and Specific Com= ments embedded in the text of the MIB, and b) The smilint output on the MIB. I hope this review is helpful. I'll be glad to discuss with the MIB author= s. Thanks, Bob Cole From macfaden@gmail.com Sun Jan 27 22:53:52 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D380B21F88F0 for ; Sun, 27 Jan 2013 22:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] 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 JqbvPvtrOrrV for ; Sun, 27 Jan 2013 22:53:52 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id E669621F87CB for ; Sun, 27 Jan 2013 22:53:51 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so1102632eek.14 for ; Sun, 27 Jan 2013 22:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VJFQIPNBp+3LL7clrFaS012E2lFhxjHz/iq/mlHNQbM=; b=WkKiGZL+Sn15+dEd2/Cz9OlJW3XkgOT536De2GPphnAmt3AeMMsxu4csxddjjUZotf +NWxTLydsmv1Z1GzowWrIVFWQmH+a62ASurPMTFEDzm+Ca06xUwngSXK2LEJwF4j52NH eMmNromYXkidToaVXmA0/u/3wFRjv+6J5M8JdC22Sg2Y1GuaCJw32KhvrOPQAymlZihF EFpsDs/i5qdpAKbwdXQZvCOw12AUpC6ASf9oMDa5yyNzb5J/uhLOrQBUcmGTV0WdYMIt stTjJKqrqnqKAA8hZO/L70xddIMpsq0HgGQ4vrdhBa5A9RYAa1D4zR0SoQzuaXti84ow 1QGQ== MIME-Version: 1.0 X-Received: by 10.14.175.70 with SMTP id y46mr48521378eel.6.1359356031059; Sun, 27 Jan 2013 22:53:51 -0800 (PST) Sender: macfaden@gmail.com Received: by 10.223.15.72 with HTTP; Sun, 27 Jan 2013 22:53:50 -0800 (PST) In-Reply-To: <50FDCD01.6080508@cisco.com> References: <50F3EB1D.1040801@cisco.com> <50FCF2E8.1070300@cisco.com> <50FDCD01.6080508@cisco.com> Date: Sun, 27 Jan 2013 22:53:50 -0800 X-Google-Sender-Auth: pNUt5bn5mj4CVh2QELxqsz-LD8Q Message-ID: From: Michael MacFaden To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b5dbe205ac6c204d453bd69 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fwd: Re: Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 06:53:52 -0000 --047d7b5dbe205ac6c204d453bd69 Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Benoit, I reviewed the current #3 draft at https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/ the nits checker had a few items to review: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-storm-iscsimib-03.tx There exist editorial comments to clean up, some noted below - -- draft-ietf-storm-iscsi-cons-03 & remove this note. but otherwise looks good to me. Tests performed: prunus% smistrip draft-ietf-storm-iscsimib-03 smistrip draft-ietf-storm-iscsimib-03 ISCSI-MIB: 3761 lines. prunus% smilint -l9 ISCSI-MIB smilint -l9 ISCSI-MIB prunus% smidump -f tree ISCSI-MIB Compared output of smidump -f identifiers from 01 draft to 03, no changes. Verified all nonscalars begin with iscsiInstIndex index as described per section 4 (Relationship to SNMP Contexts) Verified marker objects were deprecated as stated in section 5. Verified all three new objects added iscsiInstXNodeArchitecture iscsiSsnTaskReporting iscsiSsnProtocolLevel items resolved from last review. - - 4. IANA Considerations - check - - 8. Intellectual property section -check Rest of issues I reported in prior review were resolved previously on the list. s/ Mike MacFaden -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFRBiAsxTVOqsYmDtERAn2VAKDN/uPXEyiz5tAjgozx98ovFDyIUQCg0kBB eK3FpOr48h6yIl59BmoZtyo= =UDYf -----END PGP SIGNATURE----- --047d7b5dbe205ac6c204d453bd69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Benoit,

I reviewed the current = #3 draft at https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/
the nits checker had a few items to review:

There exist editorial comments to clean up, some noted = below

- -- <a href=3D"./draft-ietf-storm-i= scsi-cons-03">draft-ietf-storm-iscsi-cons-03</a> &amp; re= move this note.

but otherwise looks good to me.

Tests performed:
prunus% smistrip draft-ietf-storm-iscsimib-03= =A0
smistrip draft-ietf-storm-iscsimib-03
ISCSI-MIB: 37= 61 lines.
prunus% smilint -l9 ISCSI-MIB=A0
smilint -l9 ISCSI-MIB
=
prunus% smidump -f tree ISCSI-MIB

Compared ou= tput of smidump -f identifiers from 01 draft to 03, no changes.
Verified all nonscalars begin with iscsiInstIndex index as described per se= ction 4 (Relationship to SNMP Contexts)=A0
Verified marker object= s were deprecated as stated in section 5.
Verified all three new = objects added=A0
=A0 iscsiInstXNodeArchitecture=A0
=A0iscsiSsnTaskReporting= =A0
=A0 iscsiSsnProtocolLevel=A0

items r= esolved from last review.
- - 4. IANA Considerations - check
- - 8. Intellectual property section -check
Rest of issues I reported in prior review were resolved previously on = the list.

s/=A0
Mike MacFaden
=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.= 6 (GNU/Linux)

iD8DBQFRBiAsxTVOqsYmDtERAn2VAKDN/uPXEyiz5tAjgozx98ovFDy= IUQCg0kBB
eK3FpOr48h6yIl59BmoZtyo=3D
=3DUDYf
= -----END PGP SIGNATURE-----
--047d7b5dbe205ac6c204d453bd69-- From dromasca@avaya.com Mon Jan 28 00:02:34 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9EE21F87C3 for ; Mon, 28 Jan 2013 00:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] 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 6KP0WnyyRy5U for ; Mon, 28 Jan 2013 00:02:33 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3D21F8462 for ; Mon, 28 Jan 2013 00:02:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAP0QA1GHCzI1/2dsb2JhbABFgkgjskwBgTyHXhZzgh4BAQEBAxIbRQcQAgEIDQQEAQELHQcyFAkIAgQBDQUIGodtAQuhWJx0jRSDSmEDlymEcYo7gneBbzU X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208,217";a="341310685" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jan 2013 03:02:28 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Jan 2013 03:02:21 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 03:02:45 -0500 From: "Romascanu, Dan (Dan)" To: Michael MacFaden , Benoit Claise Thread-Topic: [MIB-DOCTORS] Fwd: Re: Request for MIB review of draft-ietf-storm-iscsimib Thread-Index: AQHN/SRIxKhK858gNUGM2xWcliid25heXupg Date: Mon, 28 Jan 2013 08:02:45 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA078AE9@AZ-FFEXMB04.global.avaya.com> References: <50F3EB1D.1040801@cisco.com> <50FCF2E8.1070300@cisco.com> <50FDCD01.6080508@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA078AE9AZFFEXMB04globala_" MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fwd: Re: Request for MIB review of draft-ietf-storm-iscsimib X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 08:02:34 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA078AE9AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, Did you also comment concerning the Security Considerations section? It seems that it is not updated according to the last template version on t= he wiki as per https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security# = (the last but final paragraph and the corresponding references). I noticed this while performing the Gen-ART review of the document. Regards, Dan From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On= Behalf Of Michael MacFaden Sent: Monday, January 28, 2013 8:54 AM To: Benoit Claise Cc: MIB Doctors (E-mail) Subject: Re: [MIB-DOCTORS] Fwd: Re: Request for MIB review of draft-ietf-st= orm-iscsimib -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Benoit, I reviewed the current #3 draft at https://datatracker.ietf.org/doc/draft-i= etf-storm-iscsimib/ the nits checker had a few items to review: http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-stor= m-iscsimib-03.tx There exist editorial comments to clean up, some noted below - -- draft-ietf-storm-iscsi-co= ns-03 & remove this note. but otherwise looks good to me. Tests performed: prunus% smistrip draft-ietf-storm-iscsimib-03 smistrip draft-ietf-storm-iscsimib-03 ISCSI-MIB: 3761 lines. prunus% smilint -l9 ISCSI-MIB smilint -l9 ISCSI-MIB prunus% smidump -f tree ISCSI-MIB Compared output of smidump -f identifiers from 01 draft to 03, no changes. Verified all nonscalars begin with iscsiInstIndex index as described per se= ction 4 (Relationship to SNMP Contexts) Verified marker objects were deprecated as stated in section 5. Verified all three new objects added iscsiInstXNodeArchitecture iscsiSsnTaskReporting iscsiSsnProtocolLevel items resolved from last review. - - 4. IANA Considerations - check - - 8. Intellectual property section -check Rest of issues I reported in prior review were resolved previously on the l= ist. s/ Mike MacFaden -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFRBiAsxTVOqsYmDtERAn2VAKDN/uPXEyiz5tAjgozx98ovFDyIUQCg0kBB eK3FpOr48h6yIl59BmoZtyo=3D =3DUDYf -----END PGP SIGNATURE----- --_000_9904FB1B0159DA42B0B887B7FA8119CA078AE9AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 <= /p>

Did you also comment conc= erning the Security Considerations section?

 <= /p>

It seems that it is not u= pdated according to the last template version on the wiki as per https://sv= n.tools.ietf.org/area/ops/trac/wiki/mib-security# (the last but final paragraph and the corresponding references).

 <= /p>

I noticed this while perf= orming the Gen-ART review of the document.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: mib-doct= ors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Michael MacFaden
Sent: Monday, January 28, 2013 8:54 AM
To: Benoit Claise
Cc: MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] Fwd: Re: Request for MIB review of draft-= ietf-storm-iscsimib

 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

 

Hi Benoit,

 

I reviewed the current #3 draft at https://datatracker.ietf.org/doc/draft-ietf-storm-iscsimib/<= /p>

the nits checker had a few items to review:

 

There exist editorial comments to clean up, some not= ed below

 

- -- <a href=3D"./draft-ietf-storm-iscsi-con= s-03">draft-ietf-storm-iscsi-cons-03</a> &amp; remove thi= s note.

 

but otherwise looks good to me.

 

Tests performed:

prunus% smistrip draft-ietf-storm-iscsimib-03 <= o:p>

smistrip draft-ietf-storm-iscsimib-03

ISCSI-MIB: 3761 lines.

prunus% smilint -l9 ISCSI-MIB 

smilint -l9 ISCSI-MIB

prunus% smidump -f tree ISCSI-MIB

 

Compared output of smidump -f identifiers from 01 dr= aft to 03, no changes.

Verified all nonscalars begin with iscsiInstIndex in= dex as described per section 4 (Relationship to SNMP Contexts) 

Verified marker objects were deprecated as stated in= section 5.

Verified all three new objects added 

  iscsiInstXNodeArchitecture 

 iscsiSsnTaskReporting 

  iscsiSsnProtocolLevel 

 

items resolved from last review.

- - 4. IANA Considerations - check

- - 8. Intellectual property section -check

Rest of issues I reported in prior review were resol= ved previously on the list.

 

s/ 

Mike MacFaden

 

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

 

iD8DBQFRBiAsxTVOqsYmDtERAn2VAKDN/uPXEyiz5tAjgozx98ov= FDyIUQCg0kBB

eK3FpOr48h6yIl59BmoZtyo=3D

=3DUDYf

-----END PGP SIGNATURE-----

--_000_9904FB1B0159DA42B0B887B7FA8119CA078AE9AZFFEXMB04globala_-- From bclaise@cisco.com Mon Jan 28 05:16:45 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE6F21F87C3; Mon, 28 Jan 2013 05:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=4.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FJML9YGZxbHn; Mon, 28 Jan 2013 05:16:44 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id BD6BB21F86FF; Mon, 28 Jan 2013 05:16:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0SDGei9018271; Mon, 28 Jan 2013 08:16:40 -0500 (EST) Received: from [10.61.109.8] (dhcp-10-61-109-8.cisco.com [10.61.109.8]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0SDGdrn004255; Mon, 28 Jan 2013 08:16:39 -0500 (EST) Message-ID: <51067A37.10404@cisco.com> Date: Mon, 28 Jan 2013 13:16:39 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> <20130115140907.GA21588@elstar.local> In-Reply-To: <20130115140907.GA21588@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:16:46 -0000 Dan, > On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > >>>>> f) In 2.12.2, can we find a better phrase than "SNMP ARCH [RFC3411] >>>>> method of context identification"? For example, "an SnmpEngineID >>>>> and ContextName pair [RFC3411] for context identification". >>>>> >>>> [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix a >>> bug I suggest to avoid such changes. >>> >>> It is document clarity. But I won't insist on this, I just find the >>> current text unnecessarily confusing. >>> >>>>> g) Overall, replace MIBs with MIB modules. >>>>> >>>> [[DR]] Same as the previous point. >>> Again, it is document clarity. It is rather obvious that this change >>> does not break anything, no? Let Bert decide - he is the owner of the >>> one MIB many MIB modules song. ;-) >>> >> [[DR]] I also sing the song when I review new documents, but in this case we would interfere in the text of the document that is now at version 4. > So what? Time to fix this. Anyway, I will not fight for this if > editors believe it is best to not update vocabularity to current I agree with Juergen on the two points above. Every single time I speak SNMP/MIB with someone, I try to use the right language, and correct my interlocutor if needed, with a little of education. I don't understand why we don't jump on the opportunity to correct this document. There are two types of audience for this new document: 1. The people who have not read the first 3 versions. So I guess not that familiar with the SNMP/MIB. They would benefit from the right terminology 2. The persons who need a diff with the previous version. So I guess familiar with SNMP/MIB. And the improvements would be obvious to them. Therefore, there is no harm in improving the document. And I don't buy in the argument that we need to keep consistency with RFC 4133 ..; for something that is not clear. Regards, Benoit > rules. > > /js > From dromasca@avaya.com Mon Jan 28 05:24:36 2013 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41B21F8585; Mon, 28 Jan 2013 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GiscjRb6FV8j; Mon, 28 Jan 2013 05:24:35 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9249E21F843A; Mon, 28 Jan 2013 05:24:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAP0QA1HGmAcF/2dsb2JhbABFgmu0CYdeFnOCHgEBAQEDEihLBAIBCA0BAwQBAQEKFAkHMhQJCAIEARIIDgyHbQGhY5x0kF5hA5waijuCd4Ik X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="46190102" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Jan 2013 08:24:00 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2013 08:23:54 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Mon, 28 Jan 2013 08:24:44 -0500 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "mib-doctors@ietf.org" , "draft-ietf-eman-rfc4133bis@tools.ietf.org" , "ops-ads@tools.ietf.org" , "eman@ietf.org" Thread-Topic: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt Thread-Index: AQHN/VnCceBnsMGWTE+6n3qI796HE5heuiTA Date: Mon, 28 Jan 2013 13:24:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA078EC3@AZ-FFEXMB04.global.avaya.com> References: <20130114095505.GA18424@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA0603B0@AZ-FFEXMB04.global.avaya.com> <20130114164533.GB19548@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA06112A@AZ-FFEXMB04.global.avaya.com> <20130115140907.GA21588@elstar.local> <51067A37.10404@cisco.com> In-Reply-To: <51067A37.10404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman-rfc4133bis-05.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:24:36 -0000 Sure, there are 7 instances of 'MIBs' in the latest version of the document= - we can replace them all by 'MIB modules'.=20 Are there any other issues that need to be edited before submitting a revis= ed version? We (the authors) believe that we fixed all issues raised by the= MIB Doctor review, but mistakes are always possible.=20 Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, January 28, 2013 3:17 PM > To: Romascanu, Dan (Dan); mib-doctors@ietf.org; draft-ietf-eman- > rfc4133bis@tools.ietf.org; ops-ads@tools.ietf.org; eman@ietf.org > Subject: Re: [MIB-DOCTORS] mib doctor review of draft-ietf-eman- > rfc4133bis-05.txt >=20 > Dan, > > On Tue, Jan 15, 2013 at 01:07:43PM +0000, Romascanu, Dan (Dan) wrote: > > > >>>>> f) In 2.12.2, can we find a better phrase than "SNMP ARCH > [RFC3411] > >>>>> method of context identification"? For example, "an > SnmpEngineID > >>>>> and ContextName pair [RFC3411] for context identification". > >>>>> > >>>> [[DR]] This is the verbiage used in RFC 4133. Unless we need to fix > >>>> a > >>> bug I suggest to avoid such changes. > >>> > >>> It is document clarity. But I won't insist on this, I just find the > >>> current text unnecessarily confusing. > >>> > >>>>> g) Overall, replace MIBs with MIB modules. > >>>>> > >>>> [[DR]] Same as the previous point. > >>> Again, it is document clarity. It is rather obvious that this change > >>> does not break anything, no? Let Bert decide - he is the owner of > >>> the one MIB many MIB modules song. ;-) > >>> > >> [[DR]] I also sing the song when I review new documents, but in this > case we would interfere in the text of the document that is now at > version 4. > > So what? Time to fix this. Anyway, I will not fight for this if > > editors believe it is best to not update vocabularity to current > I agree with Juergen on the two points above. >=20 > Every single time I speak SNMP/MIB with someone, I try to use the right > language, and correct my interlocutor if needed, with a little of > education. > I don't understand why we don't jump on the opportunity to correct this > document. > There are two types of audience for this new document: > 1. The people who have not read the first 3 versions. So I guess not > that familiar with the SNMP/MIB. They would benefit from the right > terminology 2. The persons who need a diff with the previous version. So > I guess familiar with SNMP/MIB. And the improvements would be obvious to > them. >=20 > Therefore, there is no harm in improving the document. And I don't buy > in the argument that we need to keep consistency with RFC 4133 ..; for > something that is not clear. >=20 > Regards, Benoit > > rules. > > > > /js > >