From bclaise@cisco.com Mon Jul 8 07:59: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 F0E0721F9C86; Mon, 8 Jul 2013 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.596 X-Spam-Level: X-Spam-Status: No, score=-10.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db6FFyJoNzrl; Mon, 8 Jul 2013 07:59:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85F21F9808; Mon, 8 Jul 2013 07:59:08 -0700 (PDT) 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 r68Ex7RC000825; Mon, 8 Jul 2013 16:59:07 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r68EwbJf002798; Mon, 8 Jul 2013 16:58:48 +0200 (CEST) Message-ID: <51DAD39D.2090309@cisco.com> Date: Mon, 08 Jul 2013 16:58:37 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> In-Reply-To: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130704215858.3437.65849.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040808060002010603040505" Subject: [MIB-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG 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: Mon, 08 Jul 2013 14:59:15 -0000 This is a multi-part message in MIME format. --------------040808060002010603040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please find below the agenda of the July 11th IESG telechat. Please send your questions, comments and concerns before June 10th COB. Thanks and Regards, Benoit. -------- Original Message -------- Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference Date: Thu, 04 Jul 2013 14:58:58 -0700 From: IESG Secretary To: iesg-agenda-dist@ietf.org INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-07-11 IESG Teleconference 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ipfix-protocol-rfc5101bis-08 - IETF stream Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Internet Standard) Token: Joel Jaeggli IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-appsawg-rfc5451bis-09 - IETF stream Message Header Field for Indicating Message Authentication Status (Internet Standard) Token: Barry Leiba IANA Review: Version Changed - Review Needed Consensus: Unknown 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-lisp-mib-11 - IETF stream LISP MIB (Experimental) Token: Brian Haberman IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-l2vpn-pbb-vpls-pe-model-07 - IETF stream Extensions to VPLS PE model for Provider Backbone Bridging (Informational) Note: Giles Heron (giheron@cisco.com) is the document shepherd. Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-ospf-manet-single-hop-mdr-03 - IETF stream Use of OSPF-MDR in Single-Hop Broadcast Networks (Experimental) Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items o draft-thornburgh-adobe-rtmfp-09 - IETF stream Adobe's Secure Real-Time Media Flow Protocol (Informational) Token: Martin Stiemerling IANA Review: Version Changed - Review Needed Consensus: Unknown 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o status-change-2050-to-historic-00 - IETF stream RFC 2050 to historic (None) Token: Jari Arkko 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items o conflict-review-kiyomoto-kcipher2-00 IETF conflict review for draft-kiyomoto-kcipher2 draft-kiyomoto-kcipher2-09 A Description of KCipher-2 Encryption Algorithm (ISE: Informational) Token: Stephen Farrell o conflict-review-irtf-samrg-sam-baseline-protocol-00 IETF conflict review for draft-irtf-samrg-sam-baseline-protocol draft-irtf-samrg-sam-baseline-protocol-04 Application Layer Multicast Extensions to RELOAD (IRTF: Experimental) Token: Brian Haberman 3.4.2 Returning Items o conflict-review-donley-nat444-impacts-00 IETF conflict review for draft-donley-nat444-impacts draft-donley-nat444-impacts-06 Assessing the Impact of Carrier-Grade NAT on Network Applications (ISE: Informational) Token: Joel Jaeggli Was deferred by Martin Stiemerling on 2013-06-26 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Security Automation and Continuous Monitoring (sacm) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Managed Incident Lightweight Exchange (mile) --------------040808060002010603040505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Please find below the agenda of the July 11th IESG telechat.
Please send your questions, comments and concerns before June 10th COB.

Thanks and Regards, Benoit.


-------- Original Message --------
Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference
Date: Thu, 04 Jul 2013 14:58:58 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: iesg-agenda-dist@ietf.org 


INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the 2013-07-11 IESG Teleconference

2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-ipfix-protocol-rfc5101bis-08  - IETF stream
    Specification of the IP Flow Information eXport (IPFIX) Protocol for
    the Exchange of Flow Information (Internet Standard)
    Token: Joel Jaeggli
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-appsawg-rfc5451bis-09  - IETF stream
    Message Header Field for Indicating Message Authentication Status
    (Internet Standard)
    Token: Barry Leiba
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-lisp-mib-11  - IETF stream
    LISP MIB (Experimental)
    Token: Brian Haberman
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-l2vpn-pbb-vpls-pe-model-07  - IETF stream
    Extensions to VPLS PE model for Provider Backbone Bridging
    (Informational)
    Note: Giles Heron (giheron@cisco.com) is the document shepherd.
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

  o draft-ietf-ospf-manet-single-hop-mdr-03  - IETF stream
    Use of OSPF-MDR in Single-Hop Broadcast Networks (Experimental)
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  NONE

3.2.2 Returning Items

  o draft-thornburgh-adobe-rtmfp-09  - IETF stream
    Adobe's Secure Real-Time Media Flow Protocol (Informational)
    Token: Martin Stiemerling
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

3.3 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.3.3 For Action

  o status-change-2050-to-historic-00  - IETF stream
    RFC 2050 to historic (None)
    Token: Jari Arkko

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  o conflict-review-kiyomoto-kcipher2-00
    IETF conflict review for draft-kiyomoto-kcipher2
      draft-kiyomoto-kcipher2-09
      A Description of KCipher-2 Encryption Algorithm (ISE:
    Informational)
    Token: Stephen Farrell

  o conflict-review-irtf-samrg-sam-baseline-protocol-00
    IETF conflict review for draft-irtf-samrg-sam-baseline-protocol
      draft-irtf-samrg-sam-baseline-protocol-04
      Application Layer Multicast Extensions to RELOAD (IRTF:
    Experimental)
    Token: Brian Haberman

3.4.2 Returning Items

  o conflict-review-donley-nat444-impacts-00
    IETF conflict review for draft-donley-nat444-impacts
      draft-donley-nat444-impacts-06
      Assessing the Impact of Carrier-Grade NAT on Network Applications
    (ISE: Informational)
    Token: Joel Jaeggli
    Was deferred by Martin Stiemerling on 2013-06-26

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  o Security Automation and Continuous Monitoring (sacm)

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  NONE

4.2.2 Proposed for Approval

  o Managed Incident Lightweight Exchange (mile)
--------------040808060002010603040505-- From bclaise@cisco.com Tue Jul 9 06:25: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 9DCF521F942B; Tue, 9 Jul 2013 06:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq9lcoshRL6e; Tue, 9 Jul 2013 06:25:09 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B887D21F8FAF; Tue, 9 Jul 2013 06:25:08 -0700 (PDT) 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 r69DP4tW022335; Tue, 9 Jul 2013 15:25:04 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r69DOiDV012293; Tue, 9 Jul 2013 15:24:56 +0200 (CEST) Message-ID: <51DC0C39.4060606@cisco.com> Date: Tue, 09 Jul 2013 15:12:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" Content-Type: multipart/alternative; boundary="------------090006010807090609040003" Cc: IESG IESG Subject: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment 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, 09 Jul 2013 13:25:13 -0000 This is a multi-part message in MIME format. --------------090006010807090609040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear MIB-doctors, I would need your advice, regarding the mib2 versus experimental assignment. http://tools.ietf.org/html/draft-ietf-lisp-mib-11 intended status is experimental. Therefore, it looks logical to assign the OIDs under the experimental tree. However, reviewing RFC 4181 section 4.3 RFC 2578 Section 4 describes the object identifier subtrees that are maintained by IANA and specifies the usages for those subtrees. In particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF "standard" objects, while the experimental subtree { iso 3 6 1 3 } is used to identify objects that are under development in the IETF. It is REQUIRED that objects be moved from the experimental subtree to the mgmt subtree when a MIB module enters the IETF standards track. Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs. If I would ask the author "are you targeting deployment in an operational environment?", I'm sure the answer would be yes. On the other side, most of the LISP 6 RFCs have an experimental intended status Where do we draw the line? From what I can see on google, LISP is actually deployed today. Therefore, I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as this stage, just in case this MIB is actually used in production networks. Regards, Benoit --------------090006010807090609040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear MIB-doctors,

I would need your advice, regarding the mib2 versus experimental assignment.

http://tools.ietf.org/html/draft-ietf-lisp-mib-11 intended status is experimental.
Therefore, it looks logical to assign the OIDs under the experimental tree.
However, reviewing RFC 4181 section 4.3
   RFC 2578 Section 4 describes the object identifier subtrees that are
   maintained by IANA and specifies the usages for those subtrees.  In
   particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF
   "standard" objects, while the experimental subtree { iso 3 6 1 3 } is
   used to identify objects that are under development in the IETF.  It
   is REQUIRED that objects be moved from the experimental subtree to
   the mgmt subtree when a MIB module enters the IETF standards track.

   Experience has shown that it is impractical to move objects from one
   subtree to another once those objects have seen large-scale use in an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered under
   the experimental subtree, irrespective of the standardization status
   of that object.  The experimental subtree should be used only for
   objects that are intended for limited experimental deployment.  Such
   objects typically are defined in Experimental RFCs.
If I would ask the author "are you targeting deployment in an operational environment?", I'm sure the answer would be yes. On the other side, most of the LISP 6 RFCs have an experimental intended status

Where do we draw the line?
From what I can see on google, LISP is actually deployed today. Therefore, I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as this stage, just in case this MIB is actually used in production networks.

Regards, Benoit


--------------090006010807090609040003-- From dromasca@avaya.com Tue Jul 9 10:24: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 A3A9121F9EFF; Tue, 9 Jul 2013 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glH3UsjyPtjJ; Tue, 9 Jul 2013 10:24:03 -0700 (PDT) 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 C2EB721F8529; Tue, 9 Jul 2013 10:24:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukKAAH/ZlHGmAcV/2dsb2JhbABGCoJCIyE2uRYBgUWGbIEHFnSCHwEBAQEDEhtHBRACAQgNAQMEAQELHQcyFAkIAgQBDQUIGodyAQugPIxnkCUXjVMHBAaBASYLBgGCYGEDmCOFBopogwuBagkXHg X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208,217";a="18817808" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Jul 2013 13:24:01 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jul 2013 13:22:20 -0400 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; Tue, 9 Jul 2013 13:23:59 -0400 From: "Romascanu, Dan (Dan)" To: Benoit Claise , "MIB Doctors (E-mail)" Thread-Topic: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment Thread-Index: AQHOfKfAg4he9+TlQkC2lGdNBVXZOZlcmGUg Date: Tue, 9 Jul 2013 17:23:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128647C5@AZ-FFEXMB04.global.avaya.com> References: <51DC0C39.4060606@cisco.com> In-Reply-To: <51DC0C39.4060606@cisco.com> 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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128647C5AZFFEXMB04globa_" MIME-Version: 1.0 Cc: IESG IESG Subject: Re: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment 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, 09 Jul 2013 17:24:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA128647C5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would be inclined also to make the assignment under mib-2. The text in 41= 81 indicates that assigning under experimental is recommended only for limi= ted experiments, with no predicted deployment in the Internet. This does no= t seem to be the case with LISP. Regards, Dan From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On= Behalf Of Benoit Claise Sent: Tuesday, July 09, 2013 4:12 PM To: MIB Doctors (E-mail) Cc: IESG IESG Subject: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment Dear MIB-doctors, I would need your advice, regarding the mib2 versus experimental assignment= . http://tools.ietf.org/html/draft-ietf-lisp-mib-11 intended status is experi= mental. Therefore, it looks logical to assign the OIDs under the experimental tree. However, reviewing RFC 4181 section 4.3 RFC 2578 Section 4 describ= es the object identifier subtrees that are maintained by IANA and specifies the usages for those subtrees. In particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF "standard" objects, while the experimental subtree { iso 3 6 1 3 } is used to identify objects that are under development in the IETF. It is REQUIRED that objects be moved from the experimental subtree to the mgmt subtree when a MIB module enters the IETF standards track. Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs. If I would ask the author "are you targeting deployment in an operational e= nvironment?", I'm sure the answer would be yes. On the other side, most of = the LISP 6 RFCs have an experimental intended status Where do we draw the line? >From what I can see on google, LISP is actually deployed today. Therefore, = I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as this stage, just= in case this MIB is actually used in production networks. Regards, Benoit --_000_9904FB1B0159DA42B0B887B7FA8119CA128647C5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I would be inclined also = to make the assignment under mib-2. The text in 4181 indicates that assigni= ng under experimental is recommended only for limited experiments, with no predicted deployment in the Internet. This does not seem to be the= case with LISP.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-= bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, July 09, 2013 4:12 PM
To: MIB Doctors (E-mail)
Cc: IESG IESG
Subject: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignmen= t

 

Dear MIB-doctors,

I would need your advice, regarding the mib2 versus experimental assignment= .

http://tools.= ietf.org/html/draft-ietf-lisp-mib-11 intended status is experimental. Therefore, it looks logical to assign the OIDs under the experimental tree.=
However, reviewing RFC 4181 section 4.3

   =
RFC 2578 Section 4 describes the object identifier subtrees that a=
re
   maintained by IANA and specifies the usages for those sub=
trees.  In
   particular, the mgmt subtree { iso 3 6 1 2 } is used to i=
dentify IETF
   "standard" objects, while the experimental subt=
ree { iso 3 6 1 3 } is
   used to identify objects that are under development in th=
e IETF.  It
   is REQUIRED that objects be moved from the experimental s=
ubtree to
   the mgmt subtree when a MIB module enters the IETF standa=
rds track.
 
   Experience has shown that it is impractical to move objec=
ts from one
   subtree to another once those objects have seen large-sca=
le use in an
   operational environment.  Hence any object that is t=
argeted for
   deployment in an operational environment MUST NOT be regi=
stered under
   the experimental subtree, irrespective of the standardiza=
tion status
   of that object.  The experimental subtree should be =
used only for
   objects that are intended for limited experimental deploy=
ment.  Such
   objects typically are defined in Experimental RFCs.<=
/o:p>

If I would ask the au= thor "are you targeting deployment in an operational environment?"= ;, I'm sure the answer would be yes. On the other side, most of the LISP 6 = RFCs have an experimental intended status

Where do we draw the line?
>From what I can see on google, LISP is actually deployed today. Therefore, = I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as this stage, just= in case this MIB is actually used in production networks.

Regards, Benoit

--_000_9904FB1B0159DA42B0B887B7FA8119CA128647C5AZFFEXMB04globa_-- From bclaise@cisco.com Wed Jul 10 12:57:48 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 E787C21F9DA8; Wed, 10 Jul 2013 12:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nDRfjBUBak9; Wed, 10 Jul 2013 12:57:44 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 88A8921F9DE2; Wed, 10 Jul 2013 12:57:44 -0700 (PDT) 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 r6AJvOdP008018; Wed, 10 Jul 2013 21:57:24 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6AJuiwg011470; Wed, 10 Jul 2013 21:56:59 +0200 (CEST) Message-ID: <51DDBC7C.6030907@cisco.com> Date: Wed, 10 Jul 2013 21:56:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <51DC0C39.4060606@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA128647C5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128647C5@AZ-FFEXMB04.global.avaya.com> Content-Type: multipart/alternative; boundary="------------060205070104060403090804" Cc: "MIB Doctors \(E-mail\)" , IESG IESG Subject: Re: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment 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, 10 Jul 2013 19:57:49 -0000 This is a multi-part message in MIME format. --------------060205070104060403090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Dan for the confirmation. Regards, Benoit > > Hi, > > I would be inclined also to make the assignment under mib-2. The text > in 4181 indicates that assigning under experimental is recommended > only for limited experiments, with no predicted deployment in the > Internet. This does not seem to be the case with LISP. > > Regards, > > Dan > > *From:*mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* Tuesday, July 09, 2013 4:12 PM > *To:* MIB Doctors (E-mail) > *Cc:* IESG IESG > *Subject:* [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment > > Dear MIB-doctors, > > I would need your advice, regarding the mib2 versus experimental > assignment. > > http://tools.ietf.org/html/draft-ietf-lisp-mib-11 intended status is > experimental. > Therefore, it looks logical to assign the OIDs under the experimental > tree. > However, reviewing RFC 4181 section 4.3 > > RFC 2578 Section 4 describes the object identifier subtrees that are > maintained by IANA and specifies the usages for those subtrees. In > particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF > "standard" objects, while the experimental subtree { iso 3 6 1 3 } is > used to identify objects that are under development in the IETF. It > is REQUIRED that objects be moved from the experimental subtree to > the mgmt subtree when a MIB module enters the IETF standards track. > > Experience has shown that it is impractical to move objects from one > subtree to another once those objects have seen large-scale use in an > operational environment. Hence any object that is targeted for > deployment in an operational environment MUST NOT be registered under > the experimental subtree, irrespective of the standardization status > of that object. The experimental subtree should be used only for > objects that are intended for limited experimental deployment. Such > objects typically are defined in Experimental RFCs. > > If I would ask the author "are you targeting deployment in an > operational environment?", I'm sure the answer would be yes. On the > other side, most of the LISP 6 RFCs have an experimental intended status > > Where do we draw the line? > >From what I can see on google, LISP is actually deployed today. > Therefore, I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as > this stage, just in case this MIB is actually used in production networks. > > Regards, Benoit > --------------060205070104060403090804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Dan for the confirmation.

Regards, Benoit

Hi,

 

I would be inclined also to make the assignment under mib-2. The text in 4181 indicates that assigning under experimental is recommended only for limited experiments, with no predicted deployment in the Internet. This does not seem to be the case with LISP.

 

Regards,

 

Dan

 

 

 

From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, July 09, 2013 4:12 PM
To: MIB Doctors (E-mail)
Cc: IESG IESG
Subject: [MIB-DOCTORS] LISP-MIB: mib-2 versus experimental assignment

 

Dear MIB-doctors,

I would need your advice, regarding the mib2 versus experimental assignment.

http://tools.ietf.org/html/draft-ietf-lisp-mib-11 intended status is experimental.
Therefore, it looks logical to assign the OIDs under the experimental tree.
However, reviewing RFC 4181 section 4.3

   RFC 2578 Section 4 describes the object identifier subtrees that are
   maintained by IANA and specifies the usages for those subtrees.  In
   particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF
   "standard" objects, while the experimental subtree { iso 3 6 1 3 } is
   used to identify objects that are under development in the IETF.  It
   is REQUIRED that objects be moved from the experimental subtree to
   the mgmt subtree when a MIB module enters the IETF standards track.
 
   Experience has shown that it is impractical to move objects from one
   subtree to another once those objects have seen large-scale use in an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered under
   the experimental subtree, irrespective of the standardization status
   of that object.  The experimental subtree should be used only for
   objects that are intended for limited experimental deployment.  Such
   objects typically are defined in Experimental RFCs.

If I would ask the author "are you targeting deployment in an operational environment?", I'm sure the answer would be yes. On the other side, most of the LISP 6 RFCs have an experimental intended status

Where do we draw the line?
>From what I can see on google, LISP is actually deployed today. Therefore, I'm inclined to keep draft-ietf-lisp-mib-11 under mib-2 as this stage, just in case this MIB is actually used in production networks.

Regards, Benoit


--------------060205070104060403090804-- From hhazewinkel@gmail.com Mon Jul 15 12:21: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 62E2C11E81F5 for ; Mon, 15 Jul 2013 12:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJRAlonlgrJZ for ; Mon, 15 Jul 2013 12:21:39 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C321E8155 for ; Mon, 15 Jul 2013 12:21:37 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id z7so7851966eaf.20 for ; Mon, 15 Jul 2013 12:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=jLviZTk4kCvqygEBX/76qrKTD1K9cXiil5nm5607i6Q=; b=seccs1fSjaJ/CM7aC2Pm+AGOEwtG6AVfIIcaZbCgn9OAN+fqZqBYDkQOAwBy/n7mJE 9McOPCntPeFGmLCxDXMvKmJ6WnP9/u7aZiTL3spK52pGFSJyNnFrA++usPPymkcJ7TQE eVk2IDaa+G7Xco6m04Ie35bRvB7LJsYKzHokfQc1QEZXHb+QB9JVxn5DWv9u1pYuAc6w FJsfiVTmHpupBBFsigBggoO12MAlz73ytNiAPHNbW5CWKQD6kLsdE8cYjKF3Evcrha4U ahLGDD8yPEtQX9hNvChMX2oJCQPw4RwdUkFqQ7pN9P4KUt1p3+n3+FlS9PpjgkEKXXXo PAKA== X-Received: by 10.15.86.65 with SMTP id h41mr59011684eez.147.1373916096375; Mon, 15 Jul 2013 12:21:36 -0700 (PDT) Received: from [192.168.178.73] (5356DC81.cm-6-7d.dynamic.ziggo.nl. [83.86.220.129]) by mx.google.com with ESMTPSA id i2sm104988201eeu.4.2013.07.15.12.21.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 12:21:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C1DFCF9-5D1D-437F-A073-FD0841C7A914" From: Harrie Hazewinkel In-Reply-To: Date: Mon, 15 Jul 2013 21:21:33 +0200 Message-Id: <70315C0E-6630-4A38-A960-69B156FB64B3@gmail.com> References: <20130617175854.13125.24549.idtracker@ietfa.amsl.com> To: Gregg Schudel (gschudel) X-Mailer: Apple Mail (2.1508) Cc: "mib-doctors@ietf.org" , "amit226@gmail.com Jain" , "Victor Moreno \(vimoreno\)" , Luigi Iannone , "jmh@joelhalpern.com" , "terry.manderson@icann.org" Subject: Re: [MIB-DOCTORS] [lisp] I-D Action: draft-ietf-lisp-mib-11.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, 15 Jul 2013 19:21:41 -0000 --Apple-Mail=_6C1DFCF9-5D1D-437F-A073-FD0841C7A914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Sorry for the late rply, but was on vacation. I beleive all is fine now. Noticed some extra editorial changes which I believe improve the document even more. Harrie On Jun 17, 2013, at 8:05 PM, Gregg Schudel (gschudel) = wrote: > Once more - with "diffs" >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 > > From: > > Subject: [lisp] I-D Action: draft-ietf-lisp-mib-11.txt > > Date: June 17, 2013 10:58:54 AM PDT > > To: > > Cc: > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. > >=20 > > Title : LISP MIB > > Author(s) : Gregg Schudel > > Amit Jain > > Victor Moreno > > Filename : draft-ietf-lisp-mib-11.txt > > Pages : 64 > > Date : 2013-06-17 > >=20 > > Abstract: > > This document defines the MIB module that contains managed objects = to > > support the monitoring devices that support the Locator/ID = Separation > > Protocol (LISP). These objects provide information useful for > > monitoring LISP devices, including determining basic LISP > > configuration information, LISP functional status, and operational > > counters and other statistics. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-mib > >=20 > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-lisp-mib-11 > >=20 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-11 > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > Best regards, > Gregg >=20 > -------------------------------------------------------------------- > .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr > cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com > -------------------------------------------------------------------- > cisco corporate legal statement:=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 > Harrie hhazewinkel@gmail.com --Apple-Mail=_6C1DFCF9-5D1D-437F-A073-FD0841C7A914 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

Sorry for the late rply, but was on vacation. I beleive all is fine now.

Noticed some extra editorial changes which I believe improve
the document even more.


Harrie


On Jun 17, 2013, at 8:05 PM, Gregg Schudel (gschudel) <gschudel@cisco.com> wrote:

Once more - with "diffs"







Begin forwarded message:

> From: <internet-drafts@ietf.org>
> Subject: [lisp] I-D Action: draft-ietf-lisp-mib-11.txt
> Date: June 17, 2013 10:58:54 AM PDT
> To: <i-d-announce@ietf.org>
> Cc: <lisp@ietf.org>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.
>
>        Title           : LISP MIB
>        Author(s)       : Gregg Schudel
>                          Amit Jain
>                          Victor Moreno
>        Filename        : draft-ietf-lisp-mib-11.txt
>        Pages           : 64
>        Date            : 2013-06-17
>
> Abstract:
>   This document defines the MIB module that contains managed objects to
>   support the monitoring devices that support the Locator/ID Separation
>   Protocol (LISP).  These objects provide information useful for
>   monitoring LISP devices, including determining basic LISP
>   configuration information, LISP functional status, and operational
>   counters and other statistics.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-mib
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-lisp-mib-11
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-mib-11
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

Best regards,
Gregg

--------------------------------------------------------------------
.:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr
  cisco   | mobile: +1 571 332 2222   email: gschudel@cisco.com
--------------------------------------------------------------------
cisco corporate legal statement:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------------------------------------------------------------





<wdiff draft-ietf-lisp-mib-10.txt draft-ietf-lisp-mib-11.txt.html>


--Apple-Mail=_6C1DFCF9-5D1D-437F-A073-FD0841C7A914-- From waldbusser@nextbeacon.com Tue Jul 16 18:02:25 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 6B55721F9CE6 for ; Tue, 16 Jul 2013 18:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXklF4XwSwl4 for ; Tue, 16 Jul 2013 18:02:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 398A221F9D12 for ; Tue, 16 Jul 2013 18:02:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [71.198.7.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DEEBC22E1F3; Tue, 16 Jul 2013 21:02:11 -0400 (EDT) Message-ID: <51E5ED0F.10207@nextbeacon.com> Date: Tue, 16 Jul 2013 18:02:07 -0700 From: Steve Waldbusser User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130716-1, 07/16/2013), Outbound message X-Antivirus-Status: Clean Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 01:02:25 -0000 Hello, Here's my review of the the VPLS MIB. 1. There are three tables that have a many-to-one relationship with the vplsConfigTable AND that allow SNMP create operations. A potential ambiguity exists in the creation process for these tables. For example one could create entries in the vplsPwBindTable that reference VPLS entries that don't yet exist: IOW one could create vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A in the vplsConfigTable. It is perfectly alright for the inactive rows in the vplsPWBindTable to have unresolved dangling references to VPLS-A as long as VPLS-A is created before the PWBind Entry is set to active. On the other hand, it has been my experience that agent writers will not allow that mode of operation (i.e. will not allow creation of the dangling references) unless the MIB explicitly mandates it and I think such a mandate may be more trouble than it's worth. Therefore, to protect an NMS writer from ordering their create operations that way and not interoperating, I'd suggest explicitly saying that it is optional for the agent to allow entries to be created that point to non-existent VPLSConfig entries. The most straightforward path is for the NMS to create the VPLSConfig entry and then the vplsPWBind entries. The relevant tables are: VplsPwBindEntry ::= SEQUENCE { vplsPwBindConfigType INTEGER, vplsPwBindType INTEGER, vplsPwBindRowStatus RowStatus, vplsPwBindStorageType StorageType } INDEX { vplsConfigIndex, pwIndex } VplsBgpRteTargetEntry ::= SEQUENCE { vplsBgpRteTargetIndex Unsigned32, vplsBgpRteTargetRTType VplsBgpRouteTargetType, vplsBgpRteTargetRT VplsBgpRouteTarget, vplsBgpRteTargetRowStatus RowStatus } INDEX { vplsConfigIndex, vplsBgpRteTargetIndex } VplsBgpVEEntry ::= SEQUENCE { vplsBgpVEId Unsigned32, vplsBgpVEName SnmpAdminString, vplsBgpVEPreference Unsigned32, vplsBgpVERowStatus RowStatus, vplsBgpVEStorageType StorageType } INDEX { vplsConfigIndex, vplsBgpVEId } 2. In a related matter, it would be good to define what happens to rows in the above three tables when the associated vplsConfigEntry is deleted. One option is nothing happens (i.e. allow the dangling references). Another option is language in the RowStatus objects like: "If this object is set to destroy(6) or deleted by the agent, all associated entries in the VplsPWBindTable, vplsBGPRteTargetTable and vplsBgpVETable shall be deleted." 3. vplsConfigRowStatus vplsPwBindRowStatus vplsBgpADConfigRowStatus vplsBgpRteTargetRowStatus vplsBgpVERowStatus What columns in those tables must be set to valid values before these RowStatus objects can be set to active? (Presumably all of them)? [Ref: RFC4181 4.6.4] 4. vplsPwBindEntry vplsBgpADConfigEntry vplsBgpRteTargetEntry vplsBgpVEEntry As per RFC4181 4.6.4, "If the agent itself may also create and/or delete rows, then the conditions under which this can occur MUST be clearly documented in the row object DESCRIPTION clause." Something like: "Entries in this table may be created or deleted through SNMP, as side-effects of console or other non-SNMP management commands, or upon learning via autodiscovery." 5. VplsBgpADConfigEntry VplsBgpRteTargetEntry These tables need a StorageType object 6. vplsPwBindStorageType Presumably if this row was from auto-discovery, the storagetype for this row should be 'volatile' or 'other'. My argument for 'other' is that the entry is 'algorithmically' stored. Further, you might want to document that if autodiscovered entries are deleted they would likely re-appear in the next autodiscovery interval. I'm guessing you don't intend to store a "negative" entry to keep the entry from reappearing. You'd have trouble deleting the negative entry anyway. Similar issue for vplsBgpRteTargetRowStatus. 7. Page 6: Section 5: Example of the VPLS MIB modules usage Bravo for including an example section! 8. This document is structured as three separate MIB modules. Did you consider putting everything in one MIB module and using the conformance section to modularize the MIB into 3 optional groups? 9. Page 15: vplsStatusTable Do you intend to add a bunch of other stats to this table in the future? Since vplsStatusTable is a one-to-one mapping with vplsConfigTable and fate-shares with it, these could just be read-only variables in the vplsConfigTable and then this table would be unnecessary. . Further, if it is important that this be in a separate table then this should use the AUGMENTS clause, not INDEX. AUGMENTS is used for sub-tables that have a one-to-one mapping and that fate-share, like this one. 10. Page 23 vplsStatusChanged NOTIFICATION-TYPE Need to specify which instances are included in the notification. Something like this: "The object instances included in the notification are the ones associated with the VPLS service whose status has changed." vplsFwdFullAlarmRaised NOTIFICATION-TYPE Similarly: "The object instances included in the notification are the ones associated with the VPLS service which has exceeded the threshold" vplsFwdFullAlarmCleared NOTIFICATION-TYPE Similarly: "The object instances included in the notification are the ones associated with the VPLS service which has fallen below the threshold." 11. Page 30: vplsLdpConfigMacAddrWithdraw: This object should be read-write, not read-create. 12. Generally: How does the agent know that you intend to start BGP or LDP on a VPLS entry that you have created with SNMP? 13. Page 31: vplsLdpPwBindMacAddressLimit Given there's no RowStatus I assume entries in the table are created by the agent as a side effect of the creation of PW bindings on an LDP-managed vpls service (regardless of whether the service or PW bindings were created manually, by signaling or by SNMP. If this assumption is correct then the object should be read-write, not read-create. 14. Page 42: Security Considerations In order to comply with rfc4181 Section 3.4, this should state explicitly that while the read-write and read-create objects must be protected by secure SNMP, none of them are especially disruptive. Similarly, while the read-only objects might present privacy concerns and due consideration should be given to protecting them with secure SNMP, none of these objects contain especially sensitive information. I also have a number of smaller items that I wrote notes about when I was on vacation. I need to collect those notes and send them in another email. Steve From randy_presuhn@mindspring.com Tue Jul 16 21:30: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 D5AB421F9B5D for ; Tue, 16 Jul 2013 21:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9oV9FUxsg63 for ; Tue, 16 Jul 2013 21:30:27 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3181821F9C17 for ; Tue, 16 Jul 2013 21:30:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PRyJnGZaMcknz4V671DQn9hrFxnObU4bKFBNJYM02AxtKOoAKz/Wj0IknPcFq8G4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UzJNd-0003JV-NW; Wed, 17 Jul 2013 00:30:21 -0400 Received: from 99.101.143.81 by webmail.earthlink.net with HTTP; Wed, 17 Jul 2013 00:30:21 -0400 Message-ID: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 16 Jul 2013 21:30:21 -0700 (GMT-07:00) From: Randy Presuhn To: Steve Waldbusser , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f089958485f2698056854fcc8b765acc783350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 04:30:35 -0000 Hi - >From: Steve Waldbusser >Sent: Jul 16, 2013 6:02 PM >To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 ... >1. There are three tables that have a many-to-one relationship with the >vplsConfigTable AND that > allow SNMP create operations. A potential ambiguity exists in the >creation process for these > tables. For example one could create entries in the vplsPwBindTable >that reference VPLS entries > that don't yet exist: IOW one could create >vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A > in the vplsConfigTable. It is perfectly alright for the inactive >rows in the vplsPWBindTable to > have unresolved dangling references to VPLS-A as long as VPLS-A is >created before the PWBind > Entry is set to active. On the other hand, it has been my experience >that agent writers will not > allow that mode of operation (i.e. will not allow creation of the >dangling references) unless the MIB > explicitly mandates it and I think such a mandate may be more >trouble than it's worth. Therefore, > to protect an NMS writer from ordering their create operations that >way and not interoperating, > I'd suggest explicitly saying that it is optional for the agent to >allow entries to be created > that point to non-existent VPLSConfig entries. The most >straightforward path is for the NMS to create the > VPLSConfig entry and then the vplsPWBind entries. My own experience is that it is more robust (both from the perspective of building management applications and from the instrumentation / agent side of things) to permit references to nonexistent rows, as long as what a reference to a nonexistent row *means* is explicit. Here are a few reasons why permitting "dangling" references (as long as the semantic is well-defined) is a better approach, in my opinion: 1) It simplifies provisioning. Management applications don't need special knowledge about the order of creating table entries. Also consider how having such constraints would complicate, for example, a Netconf interface to the same management information. 2) It simplifies tear-down. Management applications don't need to know about magical side-effects of deleting a row. 3) It actually simplifies create-time and activation-time cross-checks within the (sub)agent. 4) It simplifies delete-time cross-checks within the (sub)agent. 5) It avoids access-control head-scratchers about whether a side-effect in conflict with access control policy should be allowed to take place. In my opinion, having optional side-effects would be even more problematic than mandated side effects. It forces management applications to deal with ordering constraints, but still probe to see whether the side effects happened, and if not, to issue additional operations. Permitting "dangling" references removes all the convoluted conditional logic and ordering constraints, both for creation and deletion. It's a win for the manager code, and a win for the (sub)agent code. Randy From bclaise@cisco.com Wed Jul 17 00:34:38 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 CB6A821F8956; Wed, 17 Jul 2013 00:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWMHh--6Puxv; Wed, 17 Jul 2013 00:34:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 54BFA21F9A18; Wed, 17 Jul 2013 00:34:33 -0700 (PDT) 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 r6H7YWrv016366; Wed, 17 Jul 2013 09:34:32 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H7YGkE007829; Wed, 17 Jul 2013 09:34:26 +0200 (CEST) Message-ID: <51E648F8.7020107@cisco.com> Date: Wed, 17 Jul 2013 09:34:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors o , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> In-Reply-To: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010807020206070902040808" Subject: [MIB-DOCTORS] IESG telechat: Agenda and Package for the July 18, 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: Wed, 17 Jul 2013 07:34:39 -0000 This is a multi-part message in MIME format. --------------010807020206070902040808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have back to back formal telechat. Please find below the agenda of the July 18th IESG telechat. Please send your questions, comments and concerns before July 17th COB. Sorry for the short notice. Thanks and Regards, Benoit. -------- Original Message -------- Subject: UPDATED Agenda and Package for the July 18, 2013 Teleconference Date: Mon, 15 Jul 2013 15:19:30 -0700 From: IESG Secretary To: The IESG CC: avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-payload-vp8-09 - IETF stream RTP Payload Format for VP8 Video (Proposed Standard) Note: Ali Begen (abegen@cisco.com) is the document shepherd. Token: Richard Barnes IANA Review: Version Changed - Review Needed Consensus: Unknown o draft-ietf-abfab-eapapplicability-05 - IETF stream Update to the EAP Applicability Statement for ABFAB (Proposed Standard) Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd. Token: Stephen Farrell IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 - IETF stream RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) of Discarded Packets (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the document shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-jcardcal-jcard-05 - IETF stream jCard: The JSON format for vCard (Proposed Standard) Token: Pete Resnick IANA Review: IANA - Review Needed Consensus: Yes Last call expires: 2013-07-18 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-multimob-pmipv6-ropt-07 - IETF stream Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 (Experimental) Note: The document went through IETF Last Call as Informational, but has since been re-classified as Experimental. Token: Brian Haberman IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-dhc-dhcpv6-failover-requirements-06 - IETF stream DHCPv6 Failover Requirements (Informational) Note: Bernie Volz (volz@cisco.com) is the document shepherd. Token: Ted Lemon IANA Review: IANA OK - No Actions Needed Consensus: Yes Last call expires: 2013-07-17 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 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Transparent Interconnection of Lots of Links (trill) 4.2.2 Proposed for Approval NONE --------------010807020206070902040808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

We have back to back formal telechat.
Please find below the agenda of the July 18th IESG telechat.
Please send your questions, comments and concerns before July 17th COB.
Sorry for the short notice.

Thanks and Regards, Benoit.


-------- Original Message --------
Subject: UPDATED Agenda and Package for the July 18, 2013 Teleconference
Date: Mon, 15 Jul 2013 15:19:30 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: The IESG <iesg@ietf.org>
CC: avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org 



2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-payload-vp8-09  - IETF stream
    RTP Payload Format for VP8 Video (Proposed Standard)
    Note: Ali Begen (abegen@cisco.com) is the document shepherd.
    Token: Richard Barnes
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

  o draft-ietf-abfab-eapapplicability-05  - IETF stream
    Update to the EAP Applicability Statement for ABFAB (Proposed
    Standard)
    Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd.
    Token: Stephen Farrell
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

  o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06  - IETF stream
    RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length
    Encoding (RLE) of Discarded Packets (Proposed Standard)
    Note: Shida Schubert (shida@ntt-at.com) is the document shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-jcardcal-jcard-05  - IETF stream
    jCard: The JSON format for vCard (Proposed Standard)
    Token: Pete Resnick
    IANA Review: IANA - Review Needed
    Consensus: Yes
    Last call expires: 2013-07-18

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-multimob-pmipv6-ropt-07  - IETF stream
    Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
    (Experimental)
    Note: The document went through IETF Last Call as Informational, but
    has since been re-classified as Experimental.
    Token: Brian Haberman
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-dhc-dhcpv6-failover-requirements-06  - IETF stream
    DHCPv6 Failover Requirements (Informational)
    Note: Bernie Volz (volz@cisco.com) is the document shepherd.
    Token: Ted Lemon
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes
    Last call expires: 2013-07-17

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 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  NONE

3.4.2 Returning Items

  NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  NONE

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o Transparent Interconnection of Lots of Links (trill)

4.2.2 Proposed for Approval

  NONE
--------------010807020206070902040808-- From andy@yumaworks.com Wed Jul 17 06:36:27 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 9B98121F9F00 for ; Wed, 17 Jul 2013 06:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6qJc2acAy6h for ; Wed, 17 Jul 2013 06:36:23 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB821F9EA7 for ; Wed, 17 Jul 2013 06:36:23 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so1951435pab.7 for ; Wed, 17 Jul 2013 06:36:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vo+9Kz3Ivna7F4eXGADQvqAQJbPonmsK8S1a3RIFEW4=; b=NnYcI6vv3kKfupeoMyFkPFhokuiD4RKV11WGbrp0CCIp4rsiJvyi3rCetUPP+AK8yF eNJ/B76yRbYNnWwBBTa0o7nk461LY/0+42kIvn/ZUise7f7R0rRL9aYzBGgJFCGvrASD JF6hTywtmgCzze4Ib4kFG7DZrSG+eHVoNxYlROBOR7dYz9spVW6jkcqhUxidCAVbAOl0 43niN88hlSJjN2Je/VS6PJ5RDVmpwl4ypQAJ1nxwJxjrtFTOgBYbHial0Mr2rISoRRPm NcHlnVpCPvO5NcNSHETkVlcYnHVo8p4J/K5vav3//CNZk9HAPgi12gO4divJhSRkTjMT bekQ== MIME-Version: 1.0 X-Received: by 10.68.201.98 with SMTP id jz2mr6899771pbc.56.1374068182746; Wed, 17 Jul 2013 06:36:22 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 06:36:22 -0700 (PDT) In-Reply-To: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Wed, 17 Jul 2013 06:36:22 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlbyJ9nc4qFNUwz+LdJFcipzac3w8Fp0YqugNHYo+hgkIsP1T1ejsWpQRzu2rds/8fN6O0L Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 13:36:27 -0000 Hi, >From the POV of an agent developer this is one of the fundamental flaws in SNMP -- natural data structures are not possible. IMO, the "unfolded" tables make agent implementation a nightmare. SNMP allows an arbitrary number of arbitrarily incomplete "rows" to be passed in each request. Since there are absolutely no high level procedures specified, the agent must support any possible creation order sequence. As I pointed out back when XMLCONF was started, this "gumball machine" is not how CLI works -- this is not what operators asked for. During the development of APM and TPM I realized we had reached the upper bound of SMIv2 complexity, and nobody would ever implement those MIB modules. Not because we didn't need Application Performance Monitoring, but because SNMP/SMI was incapable of dealing with this level of complexity in a way that would permit engineering managers to approve agent development projects. It is better for the NMS if every agent supports every possible creation order for every data structure. It is easy to say an agent MUST support any order. Reality doesn't follow RFC 2119 though, and agent developers end up putting lots of undocumented restrictions in their code. NMS developers are forced to play detective and figure out what each agent implementation will actually accept. So even though Steve's suggestion is more restrictive, IMO it might actually help the NMS developer if the bar is set a little lower on the agent. Andy On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn wrote: > Hi - > >>From: Steve Waldbusser >>Sent: Jul 16, 2013 6:02 PM >>To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >>Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 > ... >>1. There are three tables that have a many-to-one relationship with the >>vplsConfigTable AND that >> allow SNMP create operations. A potential ambiguity exists in the >>creation process for these >> tables. For example one could create entries in the vplsPwBindTable >>that reference VPLS entries >> that don't yet exist: IOW one could create >>vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >> in the vplsConfigTable. It is perfectly alright for the inactive >>rows in the vplsPWBindTable to >> have unresolved dangling references to VPLS-A as long as VPLS-A is >>created before the PWBind >> Entry is set to active. On the other hand, it has been my experience >>that agent writers will not >> allow that mode of operation (i.e. will not allow creation of the >>dangling references) unless the MIB >> explicitly mandates it and I think such a mandate may be more >>trouble than it's worth. Therefore, >> to protect an NMS writer from ordering their create operations that >>way and not interoperating, >> I'd suggest explicitly saying that it is optional for the agent to >>allow entries to be created >> that point to non-existent VPLSConfig entries. The most >>straightforward path is for the NMS to create the >> VPLSConfig entry and then the vplsPWBind entries. > > My own experience is that it is more robust (both from the > perspective of building management applications and from > the instrumentation / agent side of things) to permit > references to nonexistent rows, as long as what a reference > to a nonexistent row *means* is explicit. Here are a few > reasons why permitting "dangling" references (as long as > the semantic is well-defined) is a better approach, in my > opinion: > > 1) It simplifies provisioning. Management applications > don't need special knowledge about the order of creating > table entries. Also consider how having such constraints > would complicate, for example, a Netconf interface to > the same management information. > > 2) It simplifies tear-down. Management applications don't > need to know about magical side-effects of deleting a row. > > 3) It actually simplifies create-time and activation-time > cross-checks within the (sub)agent. > > 4) It simplifies delete-time cross-checks within the (sub)agent. > > 5) It avoids access-control head-scratchers about whether a > side-effect in conflict with access control policy should > be allowed to take place. > > In my opinion, having optional side-effects would be even > more problematic than mandated side effects. It forces > management applications to deal with ordering constraints, > but still probe to see whether the side effects happened, > and if not, to issue additional operations. Permitting > "dangling" references removes all the convoluted conditional > logic and ordering constraints, both for creation and deletion. > It's a win for the manager code, and a win for the (sub)agent code. > > Randy > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From tnadeau@lucidvision.com Wed Jul 17 06:52:27 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 70A8D11E80D1 for ; Wed, 17 Jul 2013 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK4Heje3gKkf for ; Wed, 17 Jul 2013 06:52:22 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D973D21F9FCA for ; Wed, 17 Jul 2013 06:52:21 -0700 (PDT) Received: from surfer-172-30-33-30-hotspot.internet-for-guests.com (unknown [174.127.131.39]) by lucidvision.com (Postfix) with ESMTP id DDE8225020DD; Wed, 17 Jul 2013 09:52:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 17 Jul 2013 06:52:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> To: Andy Bierman X-Mailer: Apple Mail (2.1508) Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 13:52:27 -0000 I totally agree with Andy. One option is to simply forget about = provisioning with this MIB altogether - which the industry really has, = but the IETF seems to still have pockets of folks that think otherwise. = Its my experience that with one exception of a popular vendor's = proprietary NMS/EMS, no one is using read-write in production. I often = wonder why do we still go through the "gumball machine" pain when = perfectly good tools like NetConf/Mod exist? Other WGs such as MPLS = have agreed to simply skip mandating read-create/write objects, so there = is plenty of precedent too. --Tom On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman = wrote: > Hi, >=20 > =46rom the POV of an agent developer this is one of the fundamental > flaws in SNMP -- natural data structures are not possible. > IMO, the "unfolded" tables make agent implementation a nightmare. > SNMP allows an arbitrary number of arbitrarily incomplete "rows" > to be passed in each request. Since there are absolutely no > high level procedures specified, the agent must support any > possible creation order sequence. >=20 > As I pointed out back when XMLCONF was started, this "gumball machine" > is not how CLI works -- this is not what operators asked for. >=20 > During the development of APM and TPM I realized we > had reached the upper bound of SMIv2 complexity, and nobody > would ever implement those MIB modules. Not because we > didn't need Application Performance Monitoring, but because > SNMP/SMI was incapable of dealing with this level of complexity > in a way that would permit engineering managers to approve > agent development projects. >=20 > It is better for the NMS if every agent supports every possible = creation order > for every data structure. It is easy to say an agent MUST support any = order. > Reality doesn't follow RFC 2119 though, and agent developers end up > putting lots of undocumented restrictions in their code. NMS = developers > are forced to play detective and figure out what each agent = implementation > will actually accept. >=20 > So even though Steve's suggestion is more restrictive, IMO it might = actually > help the NMS developer if the bar is set a little lower on the agent. >=20 >=20 > Andy >=20 >=20 >=20 >=20 > On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn > wrote: >> Hi - >>=20 >>> From: Steve Waldbusser >>> Sent: Jul 16, 2013 6:02 PM >>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron = (giheron)" , "Kiran Koushik Agrahara Sreenivasa = (kkoushik)" , mib-doctors@ietf.org >>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >> ... >>> 1. There are three tables that have a many-to-one relationship with = the >>> vplsConfigTable AND that >>> allow SNMP create operations. A potential ambiguity exists in the >>> creation process for these >>> tables. For example one could create entries in the = vplsPwBindTable >>> that reference VPLS entries >>> that don't yet exist: IOW one could create >>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>> in the vplsConfigTable. It is perfectly alright for the inactive >>> rows in the vplsPWBindTable to >>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>> created before the PWBind >>> Entry is set to active. On the other hand, it has been my = experience >>> that agent writers will not >>> allow that mode of operation (i.e. will not allow creation of the >>> dangling references) unless the MIB >>> explicitly mandates it and I think such a mandate may be more >>> trouble than it's worth. Therefore, >>> to protect an NMS writer from ordering their create operations = that >>> way and not interoperating, >>> I'd suggest explicitly saying that it is optional for the agent to >>> allow entries to be created >>> that point to non-existent VPLSConfig entries. The most >>> straightforward path is for the NMS to create the >>> VPLSConfig entry and then the vplsPWBind entries. >>=20 >> My own experience is that it is more robust (both from the >> perspective of building management applications and from >> the instrumentation / agent side of things) to permit >> references to nonexistent rows, as long as what a reference >> to a nonexistent row *means* is explicit. Here are a few >> reasons why permitting "dangling" references (as long as >> the semantic is well-defined) is a better approach, in my >> opinion: >>=20 >> 1) It simplifies provisioning. Management applications >> don't need special knowledge about the order of creating >> table entries. Also consider how having such constraints >> would complicate, for example, a Netconf interface to >> the same management information. >>=20 >> 2) It simplifies tear-down. Management applications don't >> need to know about magical side-effects of deleting a row. >>=20 >> 3) It actually simplifies create-time and activation-time >> cross-checks within the (sub)agent. >>=20 >> 4) It simplifies delete-time cross-checks within the (sub)agent. >>=20 >> 5) It avoids access-control head-scratchers about whether a >> side-effect in conflict with access control policy should >> be allowed to take place. >>=20 >> In my opinion, having optional side-effects would be even >> more problematic than mandated side effects. It forces >> management applications to deal with ordering constraints, >> but still probe to see whether the side effects happened, >> and if not, to issue additional operations. Permitting >> "dangling" references removes all the convoluted conditional >> logic and ordering constraints, both for creation and deletion. >> It's a win for the manager code, and a win for the (sub)agent code. >>=20 >> Randy >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors >=20 From giheron@cisco.com Wed Jul 17 06:57:12 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 73CBA11E80F4 for ; Wed, 17 Jul 2013 06:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9O3U1ClvXoe for ; Wed, 17 Jul 2013 06:57:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 46E8F11E80A5 for ; Wed, 17 Jul 2013 06:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6621; q=dns/txt; s=iport; t=1374069427; x=1375279027; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ItMgvnvzRWlr82fIsx+hjOWbZpnS1UElC4tcLSgtXGo=; b=I7+5g14D4bRrSPyMu8ffqJKgzo37yev7guHdpiugobdMCTQSE9UVNBBD 53vxVHjEQLTtM8NFfLKDvPSQJdXU6vmuK74UvesEUpIGUkAgo03d8eHGZ RGdNoqmoYt+x3/xZ9DIeJ3k13FfG+yqcasIevRhiSmByduiWbC4JOsMp0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskHAI2h5lGtJV2Y/2dsb2JhbABagwY0ULtPhwSBERZ0giMBAQEDAQEBATc0BAcQAgEIDgMEAQEBChQQJwsdCAIEDgUIFodsBgy2BASONoERAjEHgw1uA5QFlSSDEoFoQA X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="scan'208";a="235922590" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2013 13:57:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6HDv5js021109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:57:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 08:57:04 -0500 From: "Giles Heron (giheron)" To: Thomas Nadeau Thread-Topic: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 Thread-Index: AQHOgqZbNELfyxNHy0ataLsrw6LQ1ZlpM8UAgAAEa4CAAAFcgA== Date: Wed, 17 Jul 2013 13:57:03 +0000 Message-ID: <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> In-Reply-To: <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.89.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <38DF651E13F7FF43BCB2975A9A5ADC4E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Jul 2013 07:04:19 -0700 Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "" , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 13:57:12 -0000 If it's an easy-ish fix I'd be up for that if it provides a way forward. I= 've never been a fan of read/write SNMP MIBs :) On 17 Jul 2013, at 14:52, Thomas Nadeau wrote: >=20 > I totally agree with Andy. One option is to simply forget about provisio= ning with this MIB altogether - which the industry really has, but the IETF= seems to still have pockets of folks that think otherwise. Its my experien= ce that with one exception of a popular vendor's proprietary NMS/EMS, no on= e is using read-write in production. I often wonder why do we still go thro= ugh the "gumball machine" pain when perfectly good tools like NetConf/Mod e= xist? Other WGs such as MPLS have agreed to simply skip mandating read-cre= ate/write objects, so there is plenty of precedent too. >=20 > --Tom >=20 >=20 > On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman wr= ote: >=20 >> Hi, >>=20 >> From the POV of an agent developer this is one of the fundamental >> flaws in SNMP -- natural data structures are not possible. >> IMO, the "unfolded" tables make agent implementation a nightmare. >> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >> to be passed in each request. Since there are absolutely no >> high level procedures specified, the agent must support any >> possible creation order sequence. >>=20 >> As I pointed out back when XMLCONF was started, this "gumball machine" >> is not how CLI works -- this is not what operators asked for. >>=20 >> During the development of APM and TPM I realized we >> had reached the upper bound of SMIv2 complexity, and nobody >> would ever implement those MIB modules. Not because we >> didn't need Application Performance Monitoring, but because >> SNMP/SMI was incapable of dealing with this level of complexity >> in a way that would permit engineering managers to approve >> agent development projects. >>=20 >> It is better for the NMS if every agent supports every possible creation= order >> for every data structure. It is easy to say an agent MUST support any o= rder. >> Reality doesn't follow RFC 2119 though, and agent developers end up >> putting lots of undocumented restrictions in their code. NMS developers >> are forced to play detective and figure out what each agent implementati= on >> will actually accept. >>=20 >> So even though Steve's suggestion is more restrictive, IMO it might actu= ally >> help the NMS developer if the bar is set a little lower on the agent. >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >> wrote: >>> Hi - >>>=20 >>>> From: Steve Waldbusser >>>> Sent: Jul 16, 2013 6:02 PM >>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (gihero= n)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>> ... >>>> 1. There are three tables that have a many-to-one relationship with th= e >>>> vplsConfigTable AND that >>>> allow SNMP create operations. A potential ambiguity exists in the >>>> creation process for these >>>> tables. For example one could create entries in the vplsPwBindTable >>>> that reference VPLS entries >>>> that don't yet exist: IOW one could create >>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>> rows in the vplsPWBindTable to >>>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>>> created before the PWBind >>>> Entry is set to active. On the other hand, it has been my experience >>>> that agent writers will not >>>> allow that mode of operation (i.e. will not allow creation of the >>>> dangling references) unless the MIB >>>> explicitly mandates it and I think such a mandate may be more >>>> trouble than it's worth. Therefore, >>>> to protect an NMS writer from ordering their create operations that >>>> way and not interoperating, >>>> I'd suggest explicitly saying that it is optional for the agent to >>>> allow entries to be created >>>> that point to non-existent VPLSConfig entries. The most >>>> straightforward path is for the NMS to create the >>>> VPLSConfig entry and then the vplsPWBind entries. >>>=20 >>> My own experience is that it is more robust (both from the >>> perspective of building management applications and from >>> the instrumentation / agent side of things) to permit >>> references to nonexistent rows, as long as what a reference >>> to a nonexistent row *means* is explicit. Here are a few >>> reasons why permitting "dangling" references (as long as >>> the semantic is well-defined) is a better approach, in my >>> opinion: >>>=20 >>> 1) It simplifies provisioning. Management applications >>> don't need special knowledge about the order of creating >>> table entries. Also consider how having such constraints >>> would complicate, for example, a Netconf interface to >>> the same management information. >>>=20 >>> 2) It simplifies tear-down. Management applications don't >>> need to know about magical side-effects of deleting a row. >>>=20 >>> 3) It actually simplifies create-time and activation-time >>> cross-checks within the (sub)agent. >>>=20 >>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>=20 >>> 5) It avoids access-control head-scratchers about whether a >>> side-effect in conflict with access control policy should >>> be allowed to take place. >>>=20 >>> In my opinion, having optional side-effects would be even >>> more problematic than mandated side effects. It forces >>> management applications to deal with ordering constraints, >>> but still probe to see whether the side effects happened, >>> and if not, to issue additional operations. Permitting >>> "dangling" references removes all the convoluted conditional >>> logic and ordering constraints, both for creation and deletion. >>> It's a win for the manager code, and a win for the (sub)agent code. >>>=20 >>> Randy >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >>=20 >=20 From tnadeau@lucidvision.com Wed Jul 17 07:09:27 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 D00AB21E8083 for ; Wed, 17 Jul 2013 07:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePKaFjsABd4T for ; Wed, 17 Jul 2013 07:09:22 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A09421F999B for ; Wed, 17 Jul 2013 07:09:21 -0700 (PDT) Received: from surfer-172-30-33-30-hotspot.internet-for-guests.com (unknown [174.127.131.39]) by lucidvision.com (Postfix) with ESMTP id 9C50D2502203; Wed, 17 Jul 2013 10:09:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> Date: Wed, 17 Jul 2013 07:09:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> To: "Giles Heron (giheron)" X-Mailer: Apple Mail (2.1508) Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "" , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 14:09:27 -0000 Its fairly straight-forward to remove the read-write verbage. = I'd be up for it, but you probably need to ask the WG to avoid some = lengthly additional LC. --Tom On Jul 17, 2013:6:57 AM, at 6:57 AM, "Giles Heron (giheron)" = wrote: > If it's an easy-ish fix I'd be up for that if it provides a way = forward. I've never been a fan of read/write SNMP MIBs :) >=20 > On 17 Jul 2013, at 14:52, Thomas Nadeau = wrote: >=20 >>=20 >> I totally agree with Andy. One option is to simply forget about = provisioning with this MIB altogether - which the industry really has, = but the IETF seems to still have pockets of folks that think otherwise. = Its my experience that with one exception of a popular vendor's = proprietary NMS/EMS, no one is using read-write in production. I often = wonder why do we still go through the "gumball machine" pain when = perfectly good tools like NetConf/Mod exist? Other WGs such as MPLS = have agreed to simply skip mandating read-create/write objects, so there = is plenty of precedent too. >>=20 >> --Tom >>=20 >>=20 >> On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman = wrote: >>=20 >>> Hi, >>>=20 >>> =46rom the POV of an agent developer this is one of the fundamental >>> flaws in SNMP -- natural data structures are not possible. >>> IMO, the "unfolded" tables make agent implementation a nightmare. >>> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >>> to be passed in each request. Since there are absolutely no >>> high level procedures specified, the agent must support any >>> possible creation order sequence. >>>=20 >>> As I pointed out back when XMLCONF was started, this "gumball = machine" >>> is not how CLI works -- this is not what operators asked for. >>>=20 >>> During the development of APM and TPM I realized we >>> had reached the upper bound of SMIv2 complexity, and nobody >>> would ever implement those MIB modules. Not because we >>> didn't need Application Performance Monitoring, but because >>> SNMP/SMI was incapable of dealing with this level of complexity >>> in a way that would permit engineering managers to approve >>> agent development projects. >>>=20 >>> It is better for the NMS if every agent supports every possible = creation order >>> for every data structure. It is easy to say an agent MUST support = any order. >>> Reality doesn't follow RFC 2119 though, and agent developers end up >>> putting lots of undocumented restrictions in their code. NMS = developers >>> are forced to play detective and figure out what each agent = implementation >>> will actually accept. >>>=20 >>> So even though Steve's suggestion is more restrictive, IMO it might = actually >>> help the NMS developer if the bar is set a little lower on the = agent. >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>=20 >>> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >>> wrote: >>>> Hi - >>>>=20 >>>>> From: Steve Waldbusser >>>>> Sent: Jul 16, 2013 6:02 PM >>>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron = (giheron)" , "Kiran Koushik Agrahara Sreenivasa = (kkoushik)" , mib-doctors@ietf.org >>>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>>> ... >>>>> 1. There are three tables that have a many-to-one relationship = with the >>>>> vplsConfigTable AND that >>>>> allow SNMP create operations. A potential ambiguity exists in the >>>>> creation process for these >>>>> tables. For example one could create entries in the = vplsPwBindTable >>>>> that reference VPLS entries >>>>> that don't yet exist: IOW one could create >>>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>>> rows in the vplsPWBindTable to >>>>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>>>> created before the PWBind >>>>> Entry is set to active. On the other hand, it has been my = experience >>>>> that agent writers will not >>>>> allow that mode of operation (i.e. will not allow creation of the >>>>> dangling references) unless the MIB >>>>> explicitly mandates it and I think such a mandate may be more >>>>> trouble than it's worth. Therefore, >>>>> to protect an NMS writer from ordering their create operations = that >>>>> way and not interoperating, >>>>> I'd suggest explicitly saying that it is optional for the agent to >>>>> allow entries to be created >>>>> that point to non-existent VPLSConfig entries. The most >>>>> straightforward path is for the NMS to create the >>>>> VPLSConfig entry and then the vplsPWBind entries. >>>>=20 >>>> My own experience is that it is more robust (both from the >>>> perspective of building management applications and from >>>> the instrumentation / agent side of things) to permit >>>> references to nonexistent rows, as long as what a reference >>>> to a nonexistent row *means* is explicit. Here are a few >>>> reasons why permitting "dangling" references (as long as >>>> the semantic is well-defined) is a better approach, in my >>>> opinion: >>>>=20 >>>> 1) It simplifies provisioning. Management applications >>>> don't need special knowledge about the order of creating >>>> table entries. Also consider how having such constraints >>>> would complicate, for example, a Netconf interface to >>>> the same management information. >>>>=20 >>>> 2) It simplifies tear-down. Management applications don't >>>> need to know about magical side-effects of deleting a row. >>>>=20 >>>> 3) It actually simplifies create-time and activation-time >>>> cross-checks within the (sub)agent. >>>>=20 >>>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>>=20 >>>> 5) It avoids access-control head-scratchers about whether a >>>> side-effect in conflict with access control policy should >>>> be allowed to take place. >>>>=20 >>>> In my opinion, having optional side-effects would be even >>>> more problematic than mandated side effects. It forces >>>> management applications to deal with ordering constraints, >>>> but still probe to see whether the side effects happened, >>>> and if not, to issue additional operations. Permitting >>>> "dangling" references removes all the convoluted conditional >>>> logic and ordering constraints, both for creation and deletion. >>>> It's a win for the manager code, and a win for the (sub)agent code. >>>>=20 >>>> Randy >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>=20 >>=20 >=20 >=20 From andy@yumaworks.com Wed Jul 17 07:18: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 580F911E80A5 for ; Wed, 17 Jul 2013 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoSzoHTrgBUh for ; Wed, 17 Jul 2013 07:18:31 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2E01621F91F4 for ; Wed, 17 Jul 2013 07:18:31 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so1947522pbc.26 for ; Wed, 17 Jul 2013 07:18:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qA7bsJW0Q2FuXmLovDBt952t9t03y0+yFq257I55k1s=; b=IOCHBo6tXEVXYO/4atezoTLUJL3TCZ8qMen0pcs5P5vLzVsw/7P4dagWM3RhOcjvPy 7pzDkZl/yfBYcKncGrlagyybboKRPGa5IRAg/rV95mc0qRMZtYeCEULC6cyCQ23B73tl AAe1/KksQC6iFrJ+6FufuL4opJtCSPVUa+XowU92fwbEv3+QkxkNNyGXQoLtxetmDwHK iswvVILV376bZZPUCO/HxSQJXJVjqIjjUIAaJ6iDuHKcALVVeavttLR2WFox7mN5r98c qKnPCXtTOQLMWLf/dDdSnnCQ7IFT7Ml4fDt8dGma+LHOYpAjulPza9pkS8BqQ0vWVuv7 9wLg== MIME-Version: 1.0 X-Received: by 10.68.131.133 with SMTP id om5mr7048905pbb.148.1374070710663; Wed, 17 Jul 2013 07:18:30 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 07:18:30 -0700 (PDT) In-Reply-To: <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> Date: Wed, 17 Jul 2013 07:18:30 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk4osDXre1aL6D3KculhP+TNjO+kUHrRSALGNy7prC+ECKMMtEeqoL4UEx8FapsdTIWRvWQ Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , "" , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 14:18:35 -0000 Hi, I was not suggesting remove r/w. I am agreeing with Steve's suggestion, which I think is: - agent MUST support creation without dangling references - agent MAY support creation with dangling references Andy On Wed, Jul 17, 2013 at 7:09 AM, Thomas Nadeau wr= ote: > > Its fairly straight-forward to remove the read-write verbage. I'= d be up for it, but you probably need to ask the WG to avoid some lengthly = additional LC. > > --Tom > > On Jul 17, 2013:6:57 AM, at 6:57 AM, "Giles Heron (giheron)" wrote: > >> If it's an easy-ish fix I'd be up for that if it provides a way forward.= I've never been a fan of read/write SNMP MIBs :) >> >> On 17 Jul 2013, at 14:52, Thomas Nadeau wrote: >> >>> >>> I totally agree with Andy. One option is to simply forget about pr= ovisioning with this MIB altogether - which the industry really has, but th= e IETF seems to still have pockets of folks that think otherwise. Its my ex= perience that with one exception of a popular vendor's proprietary NMS/EMS,= no one is using read-write in production. I often wonder why do we still g= o through the "gumball machine" pain when perfectly good tools like NetConf= /Mod exist? Other WGs such as MPLS have agreed to simply skip mandating re= ad-create/write objects, so there is plenty of precedent too. >>> >>> --Tom >>> >>> >>> On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman = wrote: >>> >>>> Hi, >>>> >>>> From the POV of an agent developer this is one of the fundamental >>>> flaws in SNMP -- natural data structures are not possible. >>>> IMO, the "unfolded" tables make agent implementation a nightmare. >>>> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >>>> to be passed in each request. Since there are absolutely no >>>> high level procedures specified, the agent must support any >>>> possible creation order sequence. >>>> >>>> As I pointed out back when XMLCONF was started, this "gumball machine" >>>> is not how CLI works -- this is not what operators asked for. >>>> >>>> During the development of APM and TPM I realized we >>>> had reached the upper bound of SMIv2 complexity, and nobody >>>> would ever implement those MIB modules. Not because we >>>> didn't need Application Performance Monitoring, but because >>>> SNMP/SMI was incapable of dealing with this level of complexity >>>> in a way that would permit engineering managers to approve >>>> agent development projects. >>>> >>>> It is better for the NMS if every agent supports every possible creati= on order >>>> for every data structure. It is easy to say an agent MUST support any= order. >>>> Reality doesn't follow RFC 2119 though, and agent developers end up >>>> putting lots of undocumented restrictions in their code. NMS develope= rs >>>> are forced to play detective and figure out what each agent implementa= tion >>>> will actually accept. >>>> >>>> So even though Steve's suggestion is more restrictive, IMO it might ac= tually >>>> help the NMS developer if the bar is set a little lower on the agent. >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >>>> wrote: >>>>> Hi - >>>>> >>>>>> From: Steve Waldbusser >>>>>> Sent: Jul 16, 2013 6:02 PM >>>>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (gihe= ron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <= kkoushik@cisco.com>, mib-doctors@ietf.org >>>>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>>>> ... >>>>>> 1. There are three tables that have a many-to-one relationship with = the >>>>>> vplsConfigTable AND that >>>>>> allow SNMP create operations. A potential ambiguity exists in the >>>>>> creation process for these >>>>>> tables. For example one could create entries in the vplsPwBindTable >>>>>> that reference VPLS entries >>>>>> that don't yet exist: IOW one could create >>>>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>>>> rows in the vplsPWBindTable to >>>>>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>>>>> created before the PWBind >>>>>> Entry is set to active. On the other hand, it has been my experience >>>>>> that agent writers will not >>>>>> allow that mode of operation (i.e. will not allow creation of the >>>>>> dangling references) unless the MIB >>>>>> explicitly mandates it and I think such a mandate may be more >>>>>> trouble than it's worth. Therefore, >>>>>> to protect an NMS writer from ordering their create operations that >>>>>> way and not interoperating, >>>>>> I'd suggest explicitly saying that it is optional for the agent to >>>>>> allow entries to be created >>>>>> that point to non-existent VPLSConfig entries. The most >>>>>> straightforward path is for the NMS to create the >>>>>> VPLSConfig entry and then the vplsPWBind entries. >>>>> >>>>> My own experience is that it is more robust (both from the >>>>> perspective of building management applications and from >>>>> the instrumentation / agent side of things) to permit >>>>> references to nonexistent rows, as long as what a reference >>>>> to a nonexistent row *means* is explicit. Here are a few >>>>> reasons why permitting "dangling" references (as long as >>>>> the semantic is well-defined) is a better approach, in my >>>>> opinion: >>>>> >>>>> 1) It simplifies provisioning. Management applications >>>>> don't need special knowledge about the order of creating >>>>> table entries. Also consider how having such constraints >>>>> would complicate, for example, a Netconf interface to >>>>> the same management information. >>>>> >>>>> 2) It simplifies tear-down. Management applications don't >>>>> need to know about magical side-effects of deleting a row. >>>>> >>>>> 3) It actually simplifies create-time and activation-time >>>>> cross-checks within the (sub)agent. >>>>> >>>>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>>> >>>>> 5) It avoids access-control head-scratchers about whether a >>>>> side-effect in conflict with access control policy should >>>>> be allowed to take place. >>>>> >>>>> In my opinion, having optional side-effects would be even >>>>> more problematic than mandated side effects. It forces >>>>> management applications to deal with ordering constraints, >>>>> but still probe to see whether the side effects happened, >>>>> and if not, to issue additional operations. Permitting >>>>> "dangling" references removes all the convoluted conditional >>>>> logic and ordering constraints, both for creation and deletion. >>>>> It's a win for the manager code, and a win for the (sub)agent code. >>>>> >>>>> Randy >>>>> _______________________________________________ >>>>> MIB-DOCTORS mailing list >>>>> MIB-DOCTORS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>> >>> >> >> > From tnadeau@juniper.net Wed Jul 17 07:25: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 9551621E805F for ; Wed, 17 Jul 2013 07:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.533 X-Spam-Level: ** X-Spam-Status: No, score=2.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnuMkDKBEWPL for ; Wed, 17 Jul 2013 07:25:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 22E4221F9A2D for ; Wed, 17 Jul 2013 07:25:09 -0700 (PDT) Received: from mail170-db8-R.bigfish.com (10.174.8.246) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 14:25:08 +0000 Received: from mail170-db8 (localhost [127.0.0.1]) by mail170-db8-R.bigfish.com (Postfix) with ESMTP id 2CC377E020F for ; Wed, 17 Jul 2013 14:25:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: VPS-14(zz98dI9371I1432I4e41qzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail170-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=tnadeau@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail170-db8 (localhost.localdomain [127.0.0.1]) by mail170-db8 (MessageSwitch) id 1374071105584050_12710; Wed, 17 Jul 2013 14:25:05 +0000 (UTC) Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.235]) by mail170-db8.bigfish.com (Postfix) with ESMTP id 7FEDE20045 for ; Wed, 17 Jul 2013 14:25:05 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.50) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 14:25:04 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 07:25:02 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 17 Jul 2013 07:25:02 -0700 Received: from CO9EHSOBE029.bigfish.com (207.46.163.25) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 07:29:40 -0700 Received: from mail196-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE029.bigfish.com (10.236.130.92) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 14:25:00 +0000 Received: from mail196-co9 (localhost [127.0.0.1]) by mail196-co9-R.bigfish.com (Postfix) with ESMTP id 8DF497C0330 for ; Wed, 17 Jul 2013 14:25:00 +0000 (UTC) Received: from mail196-co9 (localhost.localdomain [127.0.0.1]) by mail196-co9 (MessageSwitch) id 1374071097523298_22770; Wed, 17 Jul 2013 14:24:57 +0000 (UTC) Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.235]) by mail196-co9.bigfish.com (Postfix) with ESMTP id 7185490004D; Wed, 17 Jul 2013 14:24:57 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Jul 2013 14:24:56 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.87]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0324.000; Wed, 17 Jul 2013 14:24:54 +0000 From: Thomas Nadeau To: Andy Bierman Thread-Topic: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 Thread-Index: AQHOgqZzdnasM+GyaEav2oHT2pLkLJlo3/MAgAAEa4CAAAFcgIAAA2mAgAAClQCAAAHKQw== Date: Wed, 17 Jul 2013 14:24:53 +0000 Message-ID: <2A7E1E92-E104-49F0-89AA-C9D750190268@juniper.net> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.83.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%LUCIDVISION.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MINDSPRING.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Wed, 17 Jul 2013 07:28:50 -0700 Cc: "Giles Heron \(giheron\)" , "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "" , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 14:25:15 -0000 but a simpler solution is to just remove read-write, no? On Jul 17, 2013, at 7:19 AM, "Andy Bierman" wrote: > Hi, >=20 > I was not suggesting remove r/w. > I am agreeing with Steve's suggestion, which I think is: > - agent MUST support creation without dangling references > - agent MAY support creation with dangling references >=20 >=20 > Andy >=20 > On Wed, Jul 17, 2013 at 7:09 AM, Thomas Nadeau = wrote: >>=20 >> Its fairly straight-forward to remove the read-write verbage. I'= d be up for it, but you probably need to ask the WG to avoid some lengthly = additional LC. >>=20 >> --Tom >>=20 >> On Jul 17, 2013:6:57 AM, at 6:57 AM, "Giles Heron (giheron)" wrote: >>=20 >>> If it's an easy-ish fix I'd be up for that if it provides a way forward= . I've never been a fan of read/write SNMP MIBs :) >>>=20 >>> On 17 Jul 2013, at 14:52, Thomas Nadeau wrote= : >>>=20 >>>>=20 >>>> I totally agree with Andy. One option is to simply forget about pr= ovisioning with this MIB altogether - which the industry really has, but th= e IETF seems to still have pockets of folks that think otherwise. Its my ex= perience that with one exception of a popular vendor's proprietary NMS/EMS,= no one is using read-write in production. I often wonder why do we still g= o through the "gumball machine" pain when perfectly good tools like NetConf= /Mod exist? Other WGs such as MPLS have agreed to simply skip mandating re= ad-create/write objects, so there is plenty of precedent too. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>> On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> From the POV of an agent developer this is one of the fundamental >>>>> flaws in SNMP -- natural data structures are not possible. >>>>> IMO, the "unfolded" tables make agent implementation a nightmare. >>>>> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >>>>> to be passed in each request. Since there are absolutely no >>>>> high level procedures specified, the agent must support any >>>>> possible creation order sequence. >>>>>=20 >>>>> As I pointed out back when XMLCONF was started, this "gumball machine= " >>>>> is not how CLI works -- this is not what operators asked for. >>>>>=20 >>>>> During the development of APM and TPM I realized we >>>>> had reached the upper bound of SMIv2 complexity, and nobody >>>>> would ever implement those MIB modules. Not because we >>>>> didn't need Application Performance Monitoring, but because >>>>> SNMP/SMI was incapable of dealing with this level of complexity >>>>> in a way that would permit engineering managers to approve >>>>> agent development projects. >>>>>=20 >>>>> It is better for the NMS if every agent supports every possible creat= ion order >>>>> for every data structure. It is easy to say an agent MUST support an= y order. >>>>> Reality doesn't follow RFC 2119 though, and agent developers end up >>>>> putting lots of undocumented restrictions in their code. NMS develop= ers >>>>> are forced to play detective and figure out what each agent implement= ation >>>>> will actually accept. >>>>>=20 >>>>> So even though Steve's suggestion is more restrictive, IMO it might a= ctually >>>>> help the NMS developer if the bar is set a little lower on the agent. >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >>>>> wrote: >>>>>> Hi - >>>>>>=20 >>>>>>> From: Steve Waldbusser >>>>>>> Sent: Jul 16, 2013 6:02 PM >>>>>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (gih= eron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" = , mib-doctors@ietf.org >>>>>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>>>>> ... >>>>>>> 1. There are three tables that have a many-to-one relationship with= the >>>>>>> vplsConfigTable AND that >>>>>>> allow SNMP create operations. A potential ambiguity exists in the >>>>>>> creation process for these >>>>>>> tables. For example one could create entries in the vplsPwBindTable >>>>>>> that reference VPLS entries >>>>>>> that don't yet exist: IOW one could create >>>>>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>>>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>>>>> rows in the vplsPWBindTable to >>>>>>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>>>>>> created before the PWBind >>>>>>> Entry is set to active. On the other hand, it has been my experienc= e >>>>>>> that agent writers will not >>>>>>> allow that mode of operation (i.e. will not allow creation of the >>>>>>> dangling references) unless the MIB >>>>>>> explicitly mandates it and I think such a mandate may be more >>>>>>> trouble than it's worth. Therefore, >>>>>>> to protect an NMS writer from ordering their create operations that >>>>>>> way and not interoperating, >>>>>>> I'd suggest explicitly saying that it is optional for the agent to >>>>>>> allow entries to be created >>>>>>> that point to non-existent VPLSConfig entries. The most >>>>>>> straightforward path is for the NMS to create the >>>>>>> VPLSConfig entry and then the vplsPWBind entries. >>>>>>=20 >>>>>> My own experience is that it is more robust (both from the >>>>>> perspective of building management applications and from >>>>>> the instrumentation / agent side of things) to permit >>>>>> references to nonexistent rows, as long as what a reference >>>>>> to a nonexistent row *means* is explicit. Here are a few >>>>>> reasons why permitting "dangling" references (as long as >>>>>> the semantic is well-defined) is a better approach, in my >>>>>> opinion: >>>>>>=20 >>>>>> 1) It simplifies provisioning. Management applications >>>>>> don't need special knowledge about the order of creating >>>>>> table entries. Also consider how having such constraints >>>>>> would complicate, for example, a Netconf interface to >>>>>> the same management information. >>>>>>=20 >>>>>> 2) It simplifies tear-down. Management applications don't >>>>>> need to know about magical side-effects of deleting a row. >>>>>>=20 >>>>>> 3) It actually simplifies create-time and activation-time >>>>>> cross-checks within the (sub)agent. >>>>>>=20 >>>>>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>>>>=20 >>>>>> 5) It avoids access-control head-scratchers about whether a >>>>>> side-effect in conflict with access control policy should >>>>>> be allowed to take place. >>>>>>=20 >>>>>> In my opinion, having optional side-effects would be even >>>>>> more problematic than mandated side effects. It forces >>>>>> management applications to deal with ordering constraints, >>>>>> but still probe to see whether the side effects happened, >>>>>> and if not, to issue additional operations. Permitting >>>>>> "dangling" references removes all the convoluted conditional >>>>>> logic and ordering constraints, both for creation and deletion. >>>>>> It's a win for the manager code, and a win for the (sub)agent code. >>>>>>=20 >>>>>> Randy >>>>>> _______________________________________________ >>>>>> MIB-DOCTORS mailing list >>>>>> MIB-DOCTORS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>> _______________________________________________ >>>>> MIB-DOCTORS mailing list >>>>> MIB-DOCTORS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >=20 >=20 From andy@yumaworks.com Wed Jul 17 07:34:27 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 76ADD21F8FF3 for ; Wed, 17 Jul 2013 07:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67b3kOQ1LyPY for ; Wed, 17 Jul 2013 07:34:23 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 666F521F85F4 for ; Wed, 17 Jul 2013 07:34:23 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q10so1904944pdj.24 for ; Wed, 17 Jul 2013 07:34:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=HezAvDMrQrG9ABPGdSjA6dmcWhqTm2zyRiutL/t6fGc=; b=oKmVg01j4rLhw5nKXvRVvr6afQEJLHpFcacCHdNnKL+OWqdeACS9fJhJ3k1lCbbZ2G pYYRuMe5ZcCyzJ4fYCci++FnnYhIFxq8QeVL25jSOAXx4tegcvBoY0ezpXGtAIeWL9hd 0GPd98tUZNr1DHRmW+YkUo1jDodApMlPiVGgyuN0zC2c2fEotpPi4RCVXsLs/Q3kBkzF J7jg8j6R7D83uMbCU+Qirncs4v/7JRMXXD6sVfjf8AGjbUu6hyEEXTKhrAmLCe8iWR/W We/TvHnoLGHIaYgmJCQW9QS1Gdta7Ph11zBHhlUjvrtERAPD5wkmAcyBWPfYUwNvzZev 3eHw== MIME-Version: 1.0 X-Received: by 10.68.201.98 with SMTP id jz2mr7159917pbc.56.1374071663080; Wed, 17 Jul 2013 07:34:23 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 07:34:23 -0700 (PDT) In-Reply-To: <2A7E1E92-E104-49F0-89AA-C9D750190268@juniper.net> References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> <2A7E1E92-E104-49F0-89AA-C9D750190268@juniper.net> Date: Wed, 17 Jul 2013 07:34:23 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkOLHCSgk5hvO3xmgWIdFG9VjloiTOogi1PfAc+7sEO/RuvKgu1BgxLIe/YDXK4s5gug5n/ Cc: "Giles Heron \(giheron\)" , "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "" , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 14:34:27 -0000 Hi, I am assuming the WG knows the objects are r/c and that's what they want. IMO, a MIB Doctor's job is to help the WG achieve what they want, not tell them what I want. Andy On Wed, Jul 17, 2013 at 7:24 AM, Thomas Nadeau wrote: > but a simpler solution is to just remove read-write, no? > > On Jul 17, 2013, at 7:19 AM, "Andy Bierman" wrote: > >> Hi, >> >> I was not suggesting remove r/w. >> I am agreeing with Steve's suggestion, which I think is: >> - agent MUST support creation without dangling references >> - agent MAY support creation with dangling references >> >> >> Andy >> >> On Wed, Jul 17, 2013 at 7:09 AM, Thomas Nadeau = wrote: >>> >>> Its fairly straight-forward to remove the read-write verbage. I= 'd be up for it, but you probably need to ask the WG to avoid some lengthly= additional LC. >>> >>> --Tom >>> >>> On Jul 17, 2013:6:57 AM, at 6:57 AM, "Giles Heron (giheron)" wrote: >>> >>>> If it's an easy-ish fix I'd be up for that if it provides a way forwar= d. I've never been a fan of read/write SNMP MIBs :) >>>> >>>> On 17 Jul 2013, at 14:52, Thomas Nadeau wrot= e: >>>> >>>>> >>>>> I totally agree with Andy. One option is to simply forget about p= rovisioning with this MIB altogether - which the industry really has, but t= he IETF seems to still have pockets of folks that think otherwise. Its my e= xperience that with one exception of a popular vendor's proprietary NMS/EMS= , no one is using read-write in production. I often wonder why do we still = go through the "gumball machine" pain when perfectly good tools like NetCon= f/Mod exist? Other WGs such as MPLS have agreed to simply skip mandating r= ead-create/write objects, so there is plenty of precedent too. >>>>> >>>>> --Tom >>>>> >>>>> >>>>> On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> From the POV of an agent developer this is one of the fundamental >>>>>> flaws in SNMP -- natural data structures are not possible. >>>>>> IMO, the "unfolded" tables make agent implementation a nightmare. >>>>>> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >>>>>> to be passed in each request. Since there are absolutely no >>>>>> high level procedures specified, the agent must support any >>>>>> possible creation order sequence. >>>>>> >>>>>> As I pointed out back when XMLCONF was started, this "gumball machin= e" >>>>>> is not how CLI works -- this is not what operators asked for. >>>>>> >>>>>> During the development of APM and TPM I realized we >>>>>> had reached the upper bound of SMIv2 complexity, and nobody >>>>>> would ever implement those MIB modules. Not because we >>>>>> didn't need Application Performance Monitoring, but because >>>>>> SNMP/SMI was incapable of dealing with this level of complexity >>>>>> in a way that would permit engineering managers to approve >>>>>> agent development projects. >>>>>> >>>>>> It is better for the NMS if every agent supports every possible crea= tion order >>>>>> for every data structure. It is easy to say an agent MUST support a= ny order. >>>>>> Reality doesn't follow RFC 2119 though, and agent developers end up >>>>>> putting lots of undocumented restrictions in their code. NMS develo= pers >>>>>> are forced to play detective and figure out what each agent implemen= tation >>>>>> will actually accept. >>>>>> >>>>>> So even though Steve's suggestion is more restrictive, IMO it might = actually >>>>>> help the NMS developer if the bar is set a little lower on the agent= . >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >>>>>> wrote: >>>>>>> Hi - >>>>>>> >>>>>>>> From: Steve Waldbusser >>>>>>>> Sent: Jul 16, 2013 6:02 PM >>>>>>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (gi= heron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)"= , mib-doctors@ietf.org >>>>>>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>>>>>> ... >>>>>>>> 1. There are three tables that have a many-to-one relationship wit= h the >>>>>>>> vplsConfigTable AND that >>>>>>>> allow SNMP create operations. A potential ambiguity exists in the >>>>>>>> creation process for these >>>>>>>> tables. For example one could create entries in the vplsPwBindTabl= e >>>>>>>> that reference VPLS entries >>>>>>>> that don't yet exist: IOW one could create >>>>>>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>>>>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>>>>>> rows in the vplsPWBindTable to >>>>>>>> have unresolved dangling references to VPLS-A as long as VPLS-A is >>>>>>>> created before the PWBind >>>>>>>> Entry is set to active. On the other hand, it has been my experien= ce >>>>>>>> that agent writers will not >>>>>>>> allow that mode of operation (i.e. will not allow creation of the >>>>>>>> dangling references) unless the MIB >>>>>>>> explicitly mandates it and I think such a mandate may be more >>>>>>>> trouble than it's worth. Therefore, >>>>>>>> to protect an NMS writer from ordering their create operations tha= t >>>>>>>> way and not interoperating, >>>>>>>> I'd suggest explicitly saying that it is optional for the agent to >>>>>>>> allow entries to be created >>>>>>>> that point to non-existent VPLSConfig entries. The most >>>>>>>> straightforward path is for the NMS to create the >>>>>>>> VPLSConfig entry and then the vplsPWBind entries. >>>>>>> >>>>>>> My own experience is that it is more robust (both from the >>>>>>> perspective of building management applications and from >>>>>>> the instrumentation / agent side of things) to permit >>>>>>> references to nonexistent rows, as long as what a reference >>>>>>> to a nonexistent row *means* is explicit. Here are a few >>>>>>> reasons why permitting "dangling" references (as long as >>>>>>> the semantic is well-defined) is a better approach, in my >>>>>>> opinion: >>>>>>> >>>>>>> 1) It simplifies provisioning. Management applications >>>>>>> don't need special knowledge about the order of creating >>>>>>> table entries. Also consider how having such constraints >>>>>>> would complicate, for example, a Netconf interface to >>>>>>> the same management information. >>>>>>> >>>>>>> 2) It simplifies tear-down. Management applications don't >>>>>>> need to know about magical side-effects of deleting a row. >>>>>>> >>>>>>> 3) It actually simplifies create-time and activation-time >>>>>>> cross-checks within the (sub)agent. >>>>>>> >>>>>>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>>>>> >>>>>>> 5) It avoids access-control head-scratchers about whether a >>>>>>> side-effect in conflict with access control policy should >>>>>>> be allowed to take place. >>>>>>> >>>>>>> In my opinion, having optional side-effects would be even >>>>>>> more problematic than mandated side effects. It forces >>>>>>> management applications to deal with ordering constraints, >>>>>>> but still probe to see whether the side effects happened, >>>>>>> and if not, to issue additional operations. Permitting >>>>>>> "dangling" references removes all the convoluted conditional >>>>>>> logic and ordering constraints, both for creation and deletion. >>>>>>> It's a win for the manager code, and a win for the (sub)agent code. >>>>>>> >>>>>>> Randy >>>>>>> _______________________________________________ >>>>>>> MIB-DOCTORS mailing list >>>>>>> MIB-DOCTORS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>>> _______________________________________________ >>>>>> MIB-DOCTORS mailing list >>>>>> MIB-DOCTORS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >> >> > > From tnadeau@lucidvision.com Wed Jul 17 07:53: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 6B81C21F9F00 for ; Wed, 17 Jul 2013 07:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUhloxDd7Gl9 for ; Wed, 17 Jul 2013 07:53:03 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4610121F99C7 for ; Wed, 17 Jul 2013 07:52:56 -0700 (PDT) Received: from [10.133.214.192] (mobile-166-147-083-217.mycingular.net [166.147.83.217]) by lucidvision.com (Postfix) with ESMTP id D135B2502358; Wed, 17 Jul 2013 10:52:51 -0400 (EDT) References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> <2A7E1E92-E104-49F0-89AA-C9D750190268@juniper.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: "Thomas D. Nadeau" Date: Wed, 17 Jul 2013 07:52:48 -0700 To: Andy Bierman Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , "" , Thomas Nadeau , "" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 14:53:13 -0000 I know. not sure r-w was discussed. On Jul 17, 2013, at 7:34 AM, Andy Bierman wrote: > Hi, >=20 > I am assuming the WG knows the objects are r/c and that's what they want. > IMO, a MIB Doctor's job is to help the WG achieve what they want, > not tell them what I want. >=20 >=20 > Andy >=20 >=20 > On Wed, Jul 17, 2013 at 7:24 AM, Thomas Nadeau wrote= : >> but a simpler solution is to just remove read-write, no? >>=20 >> On Jul 17, 2013, at 7:19 AM, "Andy Bierman" wrote: >>=20 >>> Hi, >>>=20 >>> I was not suggesting remove r/w. >>> I am agreeing with Steve's suggestion, which I think is: >>> - agent MUST support creation without dangling references >>> - agent MAY support creation with dangling references >>>=20 >>>=20 >>> Andy >>>=20 >>> On Wed, Jul 17, 2013 at 7:09 AM, Thomas Nadeau = wrote: >>>>=20 >>>> Its fairly straight-forward to remove the read-write verbage. I'= d be up for it, but you probably need to ask the WG to avoid some lengthly a= dditional LC. >>>>=20 >>>> --Tom >>>>=20 >>>> On Jul 17, 2013:6:57 AM, at 6:57 AM, "Giles Heron (giheron)" wrote: >>>>=20 >>>>> If it's an easy-ish fix I'd be up for that if it provides a way forwar= d. I've never been a fan of read/write SNMP MIBs :) >>>>>=20 >>>>> On 17 Jul 2013, at 14:52, Thomas Nadeau wrot= e: >>>>>=20 >>>>>>=20 >>>>>> I totally agree with Andy. One option is to simply forget about pr= ovisioning with this MIB altogether - which the industry really has, but the= IETF seems to still have pockets of folks that think otherwise. Its my expe= rience that with one exception of a popular vendor's proprietary NMS/EMS, no= one is using read-write in production. I often wonder why do we still go th= rough the "gumball machine" pain when perfectly good tools like NetConf/Mod e= xist? Other WGs such as MPLS have agreed to simply skip mandating read-crea= te/write objects, so there is plenty of precedent too. >>>>>>=20 >>>>>> --Tom >>>>>>=20 >>>>>>=20 >>>>>> On Jul 17, 2013:6:36 AM, at 6:36 AM, Andy Bierman wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> =46rom the POV of an agent developer this is one of the fundamental >>>>>>> flaws in SNMP -- natural data structures are not possible. >>>>>>> IMO, the "unfolded" tables make agent implementation a nightmare. >>>>>>> SNMP allows an arbitrary number of arbitrarily incomplete "rows" >>>>>>> to be passed in each request. Since there are absolutely no >>>>>>> high level procedures specified, the agent must support any >>>>>>> possible creation order sequence. >>>>>>>=20 >>>>>>> As I pointed out back when XMLCONF was started, this "gumball machin= e" >>>>>>> is not how CLI works -- this is not what operators asked for. >>>>>>>=20 >>>>>>> During the development of APM and TPM I realized we >>>>>>> had reached the upper bound of SMIv2 complexity, and nobody >>>>>>> would ever implement those MIB modules. Not because we >>>>>>> didn't need Application Performance Monitoring, but because >>>>>>> SNMP/SMI was incapable of dealing with this level of complexity >>>>>>> in a way that would permit engineering managers to approve >>>>>>> agent development projects. >>>>>>>=20 >>>>>>> It is better for the NMS if every agent supports every possible crea= tion order >>>>>>> for every data structure. It is easy to say an agent MUST support a= ny order. >>>>>>> Reality doesn't follow RFC 2119 though, and agent developers end up >>>>>>> putting lots of undocumented restrictions in their code. NMS develo= pers >>>>>>> are forced to play detective and figure out what each agent implemen= tation >>>>>>> will actually accept. >>>>>>>=20 >>>>>>> So even though Steve's suggestion is more restrictive, IMO it might a= ctually >>>>>>> help the NMS developer if the bar is set a little lower on the agent= . >>>>>>>=20 >>>>>>>=20 >>>>>>> Andy >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Jul 16, 2013 at 9:30 PM, Randy Presuhn >>>>>>> wrote: >>>>>>>> Hi - >>>>>>>>=20 >>>>>>>>> From: Steve Waldbusser >>>>>>>>> Sent: Jul 16, 2013 6:02 PM >>>>>>>>> To: draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (gi= heron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <= kkoushik@cisco.com>, mib-doctors@ietf.org >>>>>>>>> Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >>>>>>>> ... >>>>>>>>> 1. There are three tables that have a many-to-one relationship wit= h the >>>>>>>>> vplsConfigTable AND that >>>>>>>>> allow SNMP create operations. A potential ambiguity exists in the >>>>>>>>> creation process for these >>>>>>>>> tables. For example one could create entries in the vplsPwBindTabl= e >>>>>>>>> that reference VPLS entries >>>>>>>>> that don't yet exist: IOW one could create >>>>>>>>> vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A >>>>>>>>> in the vplsConfigTable. It is perfectly alright for the inactive >>>>>>>>> rows in the vplsPWBindTable to >>>>>>>>> have unresolved dangling references to VPLS-A as long as VPLS-A is= >>>>>>>>> created before the PWBind >>>>>>>>> Entry is set to active. On the other hand, it has been my experien= ce >>>>>>>>> that agent writers will not >>>>>>>>> allow that mode of operation (i.e. will not allow creation of the >>>>>>>>> dangling references) unless the MIB >>>>>>>>> explicitly mandates it and I think such a mandate may be more >>>>>>>>> trouble than it's worth. Therefore, >>>>>>>>> to protect an NMS writer from ordering their create operations tha= t >>>>>>>>> way and not interoperating, >>>>>>>>> I'd suggest explicitly saying that it is optional for the agent to= >>>>>>>>> allow entries to be created >>>>>>>>> that point to non-existent VPLSConfig entries. The most >>>>>>>>> straightforward path is for the NMS to create the >>>>>>>>> VPLSConfig entry and then the vplsPWBind entries. >>>>>>>>=20 >>>>>>>> My own experience is that it is more robust (both from the >>>>>>>> perspective of building management applications and from >>>>>>>> the instrumentation / agent side of things) to permit >>>>>>>> references to nonexistent rows, as long as what a reference >>>>>>>> to a nonexistent row *means* is explicit. Here are a few >>>>>>>> reasons why permitting "dangling" references (as long as >>>>>>>> the semantic is well-defined) is a better approach, in my >>>>>>>> opinion: >>>>>>>>=20 >>>>>>>> 1) It simplifies provisioning. Management applications >>>>>>>> don't need special knowledge about the order of creating >>>>>>>> table entries. Also consider how having such constraints >>>>>>>> would complicate, for example, a Netconf interface to >>>>>>>> the same management information. >>>>>>>>=20 >>>>>>>> 2) It simplifies tear-down. Management applications don't >>>>>>>> need to know about magical side-effects of deleting a row. >>>>>>>>=20 >>>>>>>> 3) It actually simplifies create-time and activation-time >>>>>>>> cross-checks within the (sub)agent. >>>>>>>>=20 >>>>>>>> 4) It simplifies delete-time cross-checks within the (sub)agent. >>>>>>>>=20 >>>>>>>> 5) It avoids access-control head-scratchers about whether a >>>>>>>> side-effect in conflict with access control policy should >>>>>>>> be allowed to take place. >>>>>>>>=20 >>>>>>>> In my opinion, having optional side-effects would be even >>>>>>>> more problematic than mandated side effects. It forces >>>>>>>> management applications to deal with ordering constraints, >>>>>>>> but still probe to see whether the side effects happened, >>>>>>>> and if not, to issue additional operations. Permitting >>>>>>>> "dangling" references removes all the convoluted conditional >>>>>>>> logic and ordering constraints, both for creation and deletion. >>>>>>>> It's a win for the manager code, and a win for the (sub)agent code.= >>>>>>>>=20 >>>>>>>> Randy >>>>>>>> _______________________________________________ >>>>>>>> MIB-DOCTORS mailing list >>>>>>>> MIB-DOCTORS@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>>>> _______________________________________________ >>>>>>> MIB-DOCTORS mailing list >>>>>>> MIB-DOCTORS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >=20 From andy@yumaworks.com Wed Jul 17 07:57:16 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 64AEB21E8083 for ; Wed, 17 Jul 2013 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRHP47A3UjnW for ; Wed, 17 Jul 2013 07:57:11 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53721E805D for ; Wed, 17 Jul 2013 07:57:07 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q10so1933107pdj.10 for ; Wed, 17 Jul 2013 07:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Kcr23n4J0iwE2R6ak/6Ko3GTI+srUvJuNc5BSMg9dew=; b=VKQ7LHNrcd2UTzEOIm2RmRvOjkjmyIJag3m+7cyt2/cXbIRBInfxgZ5Aqi70w9SjJX BYx7d7xx+U96aek8Opgs/oAxlitWJoOjvP5JpDtA9J6zefVA25Z/340uz9LlCSWvrgu6 ptwobJE0wnO6pOzk4lOt22Hb1dxsI8AyoF3XebpXwtjll113Zb1GhcUn/UMpkAhLAldw uwXdCWdjT1kryEV6WOjPo4PgcjGMERB/4TC22riQ3T80Cmpb+TOOqSLqMnKPo5MHwRvn lWGuTpfU9NGX/BZTAiWWQEHuKMNzKHLU1Jd0Sr+H1HDi+STT+RzItT8vnnYnyqxxsrgT ezxw== MIME-Version: 1.0 X-Received: by 10.66.234.71 with SMTP id uc7mr8278660pac.10.1374073027203; Wed, 17 Jul 2013 07:57:07 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 07:57:07 -0700 (PDT) Date: Wed, 17 Jul 2013 07:57:07 -0700 Message-ID: From: Andy Bierman To: "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlLuWG7uvJgFc+B+MVeZGm2FoqfTsmdxgrrC4qTBu5BRRsaRfrWRMVL+dPP6yY8wHMA1rFS Subject: [MIB-DOCTORS] SNMP w/JSON encoding? 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, 17 Jul 2013 14:57:16 -0000 Hi, Sorry for starting a tangent thread, but the common wisdom is that SNMP is good for monitoring, and IMO that isn't even true. ASN.1/BER encoding is CPU-expensive and varbinds contain lots of redundant information. The encoding is very inefficient. Karl Auerbach created something called KNMP that used JSON encoding, but I don't think it went anywhere. JSON is designed to reduce redundant information. That's why we are supported it w/ REST and NETCONF APIs. It is simple and widely deployed. I am surprised that no standards effort has ever been attempted to improve the encoding efficiency of SNMP, especially for tables that have complex INDEX clauses. Andy From j.schoenwaelder@jacobs-university.de Wed Jul 17 08:19:47 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 380BC11E8111 for ; Wed, 17 Jul 2013 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2FWcpmsy+YQ for ; Wed, 17 Jul 2013 08:19:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF621F8B12 for ; Wed, 17 Jul 2013 08:19:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA03B20BF5; Wed, 17 Jul 2013 17:19:30 +0200 (CEST) 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 iazNs1a9nzPm; Wed, 17 Jul 2013 17:19:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84E4020BF4; Wed, 17 Jul 2013 17:19:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6426327405B5; Wed, 17 Jul 2013 17:19:27 +0200 (CEST) Date: Wed, 17 Jul 2013 17:19:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130717151926.GA87668@elstar.local> Mail-Followup-To: Andy Bierman , "MIB Doctors (E-mail)" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] SNMP w/JSON encoding? 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: Wed, 17 Jul 2013 15:19:47 -0000 On Wed, Jul 17, 2013 at 07:57:07AM -0700, Andy Bierman wrote: > Hi, > > Sorry for starting a tangent thread, but the common wisdom is > that SNMP is good for monitoring, and IMO that isn't even true. > ASN.1/BER encoding is CPU-expensive and varbinds contain > lots of redundant information. The encoding is very inefficient. > > Karl Auerbach created something called KNMP that used JSON > encoding, but I don't think it went anywhere. JSON is designed > to reduce redundant information. That's why we are supported > it w/ REST and NETCONF APIs. It is simple and widely deployed. > > I am surprised that no standards effort has ever been attempted > to improve the encoding efficiency of SNMP, especially for tables that > have complex INDEX clauses. There was EOS and it failed. BER encoding may not be the most compact encoding, but I very much doubt it is CPU expensive (and this is also what measurements have confirmed - the time spent on the encoding/decoding part of the message processing is negligible). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Wed Jul 17 09:10:05 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 E488821F9F34 for ; Wed, 17 Jul 2013 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efuzsfCElTaW for ; Wed, 17 Jul 2013 09:09:58 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6385221F9F85 for ; Wed, 17 Jul 2013 09:09:58 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so2123602pad.32 for ; Wed, 17 Jul 2013 09:09:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cJwdCbQhoeklAutlW3y2RKM+BpIkrv3zBqdfdPkAFaE=; b=Qp1FOc8SqC8DshCeeRnwMQHVQRsQCsgPluxVhOwDuFyekG6m8kGR8CFohCQ6kAJlBP +yez9Him97KmJmt9ZUG6lf+TE6ywCOY5Weclq/0EDrch+zIj0aF2W3BAiZBp4Ha5Y19u u0Wxl2FmQWgjA5xHdmRwMU5qmmZ822DUYkpdSjpmGQKkOsmieFOb2LlV7svVGxHFCsaR ht/HmN73wBJjfVzDQNtOibN2OoeWS7sqnOk1BPV489hCaiFrhJa30VRLB+OBMZ0UNZJD hM6xYFYfXMXBKgWyqZHMHHWLrhkB+nOhKKwobQttrhHkmK5PT4ELZZn/54mxM6RyFS26 NO2g== MIME-Version: 1.0 X-Received: by 10.66.149.40 with SMTP id tx8mr8798589pab.38.1374077398144; Wed, 17 Jul 2013 09:09:58 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 09:09:58 -0700 (PDT) In-Reply-To: <20130717151926.GA87668@elstar.local> References: <20130717151926.GA87668@elstar.local> Date: Wed, 17 Jul 2013 09:09:58 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkDD1GCJ6aem7Fmcc9PTxbai64CDE/ypCSNRZebPl796QgY5rVzvl+mMVrabB044KA9if68 Subject: Re: [MIB-DOCTORS] SNMP w/JSON encoding? 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, 17 Jul 2013 16:10:06 -0000 On Wed, Jul 17, 2013 at 8:19 AM, Juergen Schoenwaelder wrote: > On Wed, Jul 17, 2013 at 07:57:07AM -0700, Andy Bierman wrote: >> Hi, >> >> Sorry for starting a tangent thread, but the common wisdom is >> that SNMP is good for monitoring, and IMO that isn't even true. >> ASN.1/BER encoding is CPU-expensive and varbinds contain >> lots of redundant information. The encoding is very inefficient. >> >> Karl Auerbach created something called KNMP that used JSON >> encoding, but I don't think it went anywhere. JSON is designed >> to reduce redundant information. That's why we are supported >> it w/ REST and NETCONF APIs. It is simple and widely deployed. >> >> I am surprised that no standards effort has ever been attempted >> to improve the encoding efficiency of SNMP, especially for tables that >> have complex INDEX clauses. > > There was EOS and it failed. > > BER encoding may not be the most compact encoding, but I very much > doubt it is CPU expensive (and this is also what measurements have > confirmed - the time spent on the encoding/decoding part of the > message processing is negligible). > The main issue is PDU size on the wire, not CPU efficiency. varbinds would be fine if the manager were asking for lots of unrelated OIDs, but they don't. The problem is the worst for retrieval of lots of counters for the same table with a really long INDEX (e.g., IPv6 addresses in them). But I don't think EOS-2 should be started. I just think it's odd (given the UDP transport) that this issue never came up again. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From andy@yumaworks.com Wed Jul 17 11:01: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 0E2BA21E8084 for ; Wed, 17 Jul 2013 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmGlA+mhC5kH for ; Wed, 17 Jul 2013 11:01:38 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 020B721E804C for ; Wed, 17 Jul 2013 11:01:34 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so2185360pbc.12 for ; Wed, 17 Jul 2013 11:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ONQr4va2RtzybfRusZ3wGkNMFaGbbhznMOSaXh6gXWY=; b=IBxx5HSYDHLfDnB2POm9yUe7C/KEFRrCgUW5il9tiy+PuntOPzfQk8DgFRJO9XcV5J s3TZzOB/bDCEsDdVoDbL4myMm8E2yfEogU+78mE25QT8p5PDjmuU/1smYQon3odlGpup 9/MQYDvP4c4K/2JGoBmJ0BZoXi0ldMF/3d2SzYFD0rb2qfr4t0d/oSZiEOiCn3cw9FxQ UPU8KgFum1JTNBBWMGq16TNBYlALb8UZXrnWn67v533XDw9Zm5nV3pVBCgu3jmRlgN3O iAaeyn0o6Ef40oGkupSU8z9jCay/+xnmak7sskp8jLfYJn/Top6b97PAQHTil96Xt5d4 eUjQ== MIME-Version: 1.0 X-Received: by 10.66.219.38 with SMTP id pl6mr9278256pac.59.1374084094747; Wed, 17 Jul 2013 11:01:34 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 11:01:34 -0700 (PDT) In-Reply-To: <20130717151926.GA87668@elstar.local> References: <20130717151926.GA87668@elstar.local> Date: Wed, 17 Jul 2013 11:01:34 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "MIB Doctors (E-mail)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnviO29wVdabxH4Ftr5LdKLIK5GhycN6JOazc6sGKiu7F132rXDXSvBPxkb0TIUKLI4Mvl2 Subject: Re: [MIB-DOCTORS] SNMP w/JSON encoding? 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, 17 Jul 2013 18:01:43 -0000 > There was EOS and it failed. > Too bad -- I don't think OID compression was controversial. I remember everybody liked it. That was 12 years ago so I could be imagining that was what happened ;-) > /js > Andy From randy_presuhn@mindspring.com Wed Jul 17 11:29:02 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 EF5CF21F9AB3 for ; Wed, 17 Jul 2013 11:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4-CathoTLGw for ; Wed, 17 Jul 2013 11:28:55 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B62F311E80CC for ; Wed, 17 Jul 2013 11:28:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Ov9897d2pH1tpbjGZDYSOXyQqig3e3DtnOrBP3fOJjg9iCUfd+/Mu43yp2tfR2dH; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UzWSy-000299-RU; Wed, 17 Jul 2013 14:28:44 -0400 Received: from 99.23.163.223 by webmail.earthlink.net with HTTP; Wed, 17 Jul 2013 14:28:44 -0400 Message-ID: <19900559.1374085724854.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Wed, 17 Jul 2013 11:28:44 -0700 (GMT-07:00) From: Randy Presuhn To: Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08096db610187317d2e59a583eb0a3e724350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:29:02 -0000 Hi - >From: Andy Bierman >Sent: Jul 17, 2013 6:36 AM >To: Randy Presuhn >Cc: Steve Waldbusser , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 > >Hi, > >From the POV of an agent developer this is one of the fundamental >flaws in SNMP -- natural data structures are not possible. >IMO, the "unfolded" tables make agent implementation a nightmare. In that regard it's no worse than a normalized database. If you'd like a much more human-friendly (object-oriented) way of representing information, GDMO/CMIP would have been your ticket. But we know where that went. :-| ... >It is better for the NMS if every agent supports every possible creation order >for every data structure. It is easy to say an agent MUST support any order. True. >Reality doesn't follow RFC 2119 though, and agent developers end up >putting lots of undocumented restrictions in their code. NMS developers >are forced to play detective and figure out what each agent implementation >will actually accept. And this is what makes no sense to me. These "undocumented restrictions" actually *increase* agent code complexity. They are effectively additional hidden state. Providing a consistent semantic for dangling references (as was done in the SNMPv3 MIBs) both simplifies agent code *and* makes it more robust. Everyone wins. The pain of developers who add "undocumented restrictions" is entirely self-inflicted. >So even though Steve's suggestion is more restrictive, IMO it might actually >help the NMS developer if the bar is set a little lower on the agent. I think the phrase "the bar is set a little lower" frames the discussion in a misleading way. Eliminating side effects and defining a consistent semantic for dangling references *reduces* agent implementation complexity. Permitting side effects and implementation-specific ordering constraints increases agent implementation complexity, increases NMS complexity, and muddies the question of what it means to be interoperable. Randy From andy@yumaworks.com Wed Jul 17 11:56: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 207FC11E80DF for ; Wed, 17 Jul 2013 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onbYhMexfx57 for ; Wed, 17 Jul 2013 11:56:06 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0B11E80C5 for ; Wed, 17 Jul 2013 11:56:04 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so2146417pdj.3 for ; Wed, 17 Jul 2013 11:56:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/nts1an0XjgrgP86EFAlwzmSEeliXAFLWyEwuAc/aC8=; b=SrJQRDn2x0htuoWpmg85sopTK/yhOIbvTPtTwF+sOLvZOYtIks9b1vr66cIT50DSd+ J93ezxbIXPBolG5PMyY2tSENKD+46NbEFR1SaDzh3/p5loQoGFZ8FRCDLdtMKNVM+KuC F2hDQJqDLJWGywoYgTlpMUL9WhYRJpejeteNzoINpSfW/ALweA917MEwWEV6HZRx0hzJ KdZKJeBSPTjUbsD85iicC+0ZoRTZx6rW90/kgGk9Awc05dwoOzfP26mMRTKSnZsKhcUi 8KI7LGP9OsylpGaRQ9n84Z4iaPHp/7GP5Zh1IJ+1L7YshCR+WvGtr59i6EvMMAAUkZbf CGXg== MIME-Version: 1.0 X-Received: by 10.68.131.133 with SMTP id om5mr8233847pbb.148.1374087363942; Wed, 17 Jul 2013 11:56:03 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 11:56:03 -0700 (PDT) In-Reply-To: <19900559.1374085724854.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <19900559.1374085724854.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Wed, 17 Jul 2013 11:56:03 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlIm949GG5uFxk64Xb5ZEZZoT9iHpD4O/8JVGqtsAQWQQoewGCJcxWzji6qIdGXKp2msSem Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 18:56:11 -0000 On Wed, Jul 17, 2013 at 11:28 AM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: Jul 17, 2013 6:36 AM >>To: Randy Presuhn >>Cc: Steve Waldbusser , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >>Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >> >>Hi, >> > >From the POV of an agent developer this is one of the fundamental >>flaws in SNMP -- natural data structures are not possible. >>IMO, the "unfolded" tables make agent implementation a nightmare. > > In that regard it's no worse than a normalized database. > If you'd like a much more human-friendly (object-oriented) > way of representing information, GDMO/CMIP would have > been your ticket. But we know where that went. :-| > (Disclaimer: I work on YANG-based tools all day, every day.) The balance between power and ease-of-use is hard to get right. I think YANG scores higher on that metric than anything else I've seen. > ... >>It is better for the NMS if every agent supports every possible creation order >>for every data structure. It is easy to say an agent MUST support any order. > > True. > >>Reality doesn't follow RFC 2119 though, and agent developers end up >>putting lots of undocumented restrictions in their code. NMS developers >>are forced to play detective and figure out what each agent implementation >>will actually accept. > > And this is what makes no sense to me. These "undocumented > restrictions" actually *increase* agent code complexity. They > are effectively additional hidden state. Providing a consistent > semantic for dangling references (as was done in the SNMPv3 MIBs) > both simplifies agent code *and* makes it more robust. Everyone > wins. The pain of developers who add "undocumented restrictions" > is entirely self-inflicted. > But to the agent developer in a hurry, it's SNMP (Simply Not My Problem) :-) CLI is much worse than SNMP wrt/ undocumented restrictions. (The whole thing is ad-hoc so one might say CLI is a completely undocumented API.) In fact, the trouble facing NETCONF adoption has everything to do with transitioning from no-rules ad-hoc CLI to anything structured (NETCONF/YANG included), and nothing to do with SNMP. >>So even though Steve's suggestion is more restrictive, IMO it might actually >>help the NMS developer if the bar is set a little lower on the agent. > > I think the phrase "the bar is set a little lower" frames > the discussion in a misleading way. Eliminating side effects > and defining a consistent semantic for dangling references > *reduces* agent implementation complexity. Permitting > side effects and implementation-specific ordering constraints > increases agent implementation complexity, increases NMS > complexity, and muddies the question of what it means to > be interoperable. IMO this is no different than any other optional functionality. The NMS developer may avoid an optional mechanism because not all agents support it. The agent developer may have valid reasons why it cannot be implemented. The WG can require creation in any order and hope for the best from vendors. I suggest using a protocol with some sort of a transaction model with datastore validation. SNMP has neither of those, rendering it DOA for configuration. > > Randy Andy From randy_presuhn@mindspring.com Wed Jul 17 13:45: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 9CB9F21F9ED4 for ; Wed, 17 Jul 2013 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLKSjI7j5Le5 for ; Wed, 17 Jul 2013 13:45:09 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 424DE21F9EA7 for ; Wed, 17 Jul 2013 13:44:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gofwjELKFc6kGg2qzf1IZk+BjT/65aGTH0mu7hASCCGlabQx/SbqVY4LeXHPfJ07; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UzYal-00074P-Q6; Wed, 17 Jul 2013 16:44:55 -0400 Received: from 99.23.163.223 by webmail.earthlink.net with HTTP; Wed, 17 Jul 2013 16:44:55 -0400 Message-ID: <15398067.1374093895822.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Wed, 17 Jul 2013 13:44:55 -0700 (GMT-07:00) From: Randy Presuhn To: Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f084de058d91f500297aa603d2038d76199350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:45:15 -0000 Hi - >From: Andy Bierman >Sent: Jul 17, 2013 11:56 AM >To: Randy Presuhn >Cc: Steve Waldbusser , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 ... >The WG can require creation in any order and hope for >the best from vendors. ... That's true about *any* requirement. My point is that from an implementation perspective (both manager and agent) "creation in any order" (if dangling reference semantics are properly specified) is probably the *simplest* for developers to get right. It's the easiest to reason about, the easiest to test, easiest for managers, and easiest for agents. It's also the easiest to extend, should the need arise. Randy From andy@yumaworks.com Wed Jul 17 14:01: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 7DAF321F9D7E for ; Wed, 17 Jul 2013 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk6ftZQrDtmP for ; Wed, 17 Jul 2013 14:01:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF421F99E9 for ; Wed, 17 Jul 2013 14:01:08 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so2331068pbc.3 for ; Wed, 17 Jul 2013 14:01:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oxc37INp68S46iG1OKJxjVj6Smgv0bLmYfCAV+vc7uk=; b=NLdppzyJ2Ss1KUZs+rEYQ2KkXyS4LP+tPybtrN2MZMVU62YWtl4xee9Irj0ftnTTl3 DxVO/U1cvzvELCEzYZM14dAXVvyt6fo+IB5ITBJIg0A5B8e4oiL0aaMoeuu1K8vgI4ZH 6PqC3VtHt18DZOYBKdTLn00BY3TFVkFNo9Q5N4Pweg3YHSno02Vr0X43NnnJyoK2U2Fo 07Utf2YY0zpiLZqXnuScRV0gimIR9DQi+ZHa2HKCJZolZt8KbqrblpjHeeCYRuX/IKFJ 7v2bAUpQMSDEowJd1x+mkWKOshqk41UtAxzAdGQSB+RND8TqYEb5TQiprBgAwwg4WaX/ vLag== MIME-Version: 1.0 X-Received: by 10.66.234.71 with SMTP id uc7mr9724972pac.10.1374094867846; Wed, 17 Jul 2013 14:01:07 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 17 Jul 2013 14:01:07 -0700 (PDT) In-Reply-To: <15398067.1374093895822.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <15398067.1374093895822.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Wed, 17 Jul 2013 14:01:07 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnLGdWnBeG9D0vfLpkdYU6G3+6OTw8g31GjcsMlOb26fmj1WG6MbABioxwixTVDjZ0tuE/X Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 21:01:13 -0000 On Wed, Jul 17, 2013 at 1:44 PM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: Jul 17, 2013 11:56 AM >>To: Randy Presuhn >>Cc: Steve Waldbusser , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , mib-doctors@ietf.org >>Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 > ... >>The WG can require creation in any order and hope for >>the best from vendors. > ... > > That's true about *any* requirement. > > My point is that from an implementation perspective > (both manager and agent) "creation in any order" > (if dangling reference semantics are properly > specified) is probably the *simplest* for developers > to get right. It's the easiest to reason about, > the easiest to test, easiest for managers, and easiest > for agents. It's also the easiest to extend, should > the need arise. > Does SNMP suck for configuration because agent developers do not do the "right thing" during implementation, or do agent developers do the "wrong thing" during implementation because SNMP sucks for configuration? A: in the end it doesn't matter. NMS developers are not using SNMP for configuration. > Randy Andy From tnadeau@lucidvision.com Wed Jul 17 14:02: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 14C4621F9D7E for ; Wed, 17 Jul 2013 14:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk7uCtm8jAwp for ; Wed, 17 Jul 2013 14:02:30 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F27C721F99C5 for ; Wed, 17 Jul 2013 14:02:29 -0700 (PDT) Received: from [172.19.131.116] (unknown [12.130.126.121]) by lucidvision.com (Postfix) with ESMTP id E90492502CE6; Wed, 17 Jul 2013 17:02:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 17 Jul 2013 17:02:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15398067.1374093895822.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> To: Andy Bierman X-Mailer: Apple Mail (2.1508) Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 17 Jul 2013 21:02:35 -0000 On Jul 17, 2013:5:01 PM, at 5:01 PM, Andy Bierman = wrote: > On Wed, Jul 17, 2013 at 1:44 PM, Randy Presuhn > wrote: >> Hi - >>=20 >>> From: Andy Bierman >>> Sent: Jul 17, 2013 11:56 AM >>> To: Randy Presuhn >>> Cc: Steve Waldbusser , = draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, "Giles Heron (giheron)" = , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" = , mib-doctors@ietf.org >>> Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 >> ... >>> The WG can require creation in any order and hope for >>> the best from vendors. >> ... >>=20 >> That's true about *any* requirement. >>=20 >> My point is that from an implementation perspective >> (both manager and agent) "creation in any order" >> (if dangling reference semantics are properly >> specified) is probably the *simplest* for developers >> to get right. It's the easiest to reason about, >> the easiest to test, easiest for managers, and easiest >> for agents. It's also the easiest to extend, should >> the need arise. >>=20 >=20 > Does SNMP suck for configuration because agent developers > do not do the "right thing" during implementation, or do > agent developers do the "wrong thing" during implementation > because SNMP sucks for configuration? >=20 > A: in the end it doesn't matter. NMS developers are not > using SNMP for configuration. I agree. Having this debate is a waste of time; the industry has = voted a long time ago... --Tom >=20 >=20 >> Randy >=20 > Andy > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors >=20 From waldbusser@nextbeacon.com Thu Jul 18 13:18: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 BADA011E8158 for ; Thu, 18 Jul 2013 13:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mwO4ODwoRrS for ; Thu, 18 Jul 2013 13:18:15 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D59D721F9A2B for ; Thu, 18 Jul 2013 13:18:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [71.198.7.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E12B622E1F4; Thu, 18 Jul 2013 16:18:04 -0400 (EDT) Message-ID: <51E84D7B.8040504@nextbeacon.com> Date: Thu, 18 Jul 2013 13:18:03 -0700 From: Steve Waldbusser User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andy Bierman References: <2339726.1374035421626.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <7CCB2694-24DE-42DA-B8DD-0D1C350A68B5@lucidvision.com> <136D0A04DAA0A64881D68D8374E6E077090D5B71@xmb-rcd-x04.cisco.com> <7D4E9591-BE89-4C15-8ADE-E15E571DFF00@lucidvision.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130718-3, 07/18/2013), Outbound message X-Antivirus-Status: Clean Cc: "Giles Heron \(giheron\)" , "" , "" , "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 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, 18 Jul 2013 20:18:21 -0000 On 7/17/2013 7:34 AM, Andy Bierman wrote: > I am agreeing with Steve's suggestion, which I think is: > - agent MUST support creation without dangling references > - agent MAY support creation with dangling references Yes, that was my suggestion. On Wed, Jul 17, 2013 at 7:24 AM, Thomas Nadeau wrote: > but a simpler solution is to just remove read-write, no? It would probably take as much time to remove the read-write semantics from the MIB as it would to fix them (give or take an hour or two). And either requires WG review. Based on the principle of least astonishment, proceeding with the fixes has the lowest risk of generating a protracted WG discussion. You've done a great job and you're 95% done, I'd suggest sticking with it. On 7/17/2013 1:44 PM, Randy Presuhn wrote: > My point is that from an implementation perspective (both manager and > agent) "creation in any order" (if dangling reference semantics are > properly specified) is probably the *simplest* for developers to get > right. It's the easiest to reason about, the easiest to test, easiest > for managers, and easiest for agents. It's also the easiest to extend, > should the need arise. Randy My experience is that the pre-existing data structures don't allow the dangling references and there are two options: 1. Retrofit the capability for dangling references into the pre-existing data structures and everything that reads and writes them, at some risk to the stability of that code 2. Create a separate data structure in the agent that holds these in-progress entries, merges the views of the 2 data structures, and moves entries between the two data structures as they are activated and inactivated. I've coded #2 before (and probably #1 too) and it's not an incredible amount of work when you know what you're doing but I can understand why agent writers avoid it when left to their own devices. And they avoid it because they know they'll probably get away with it because NMS writers are probably reluctant to send the dangling references anyway (why take the risk that you won't get allocated the correct VPLS index and be forced to start over?) I mostly agree with your 5 benefits of allowing dangling references - it's just that I see the cost as higher. You lose me when you talk about optional side-effects because I don't think we're talking about introduces optional side-effects. Same with "undocumented restrictions". I'm suggesting we document a restriction that would probably happen in real life *before* it happens in real life and could affect interoperability. Steve From adrian@olddog.co.uk Thu Jul 18 16:00: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 3D1F911E821F for ; Thu, 18 Jul 2013 16:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbBTEUej-f-Q for ; Thu, 18 Jul 2013 16:00:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1C11E8235 for ; Thu, 18 Jul 2013 16:00:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6IN0YwJ028466 for ; Fri, 19 Jul 2013 00:00:34 +0100 Received: from 950129200 ([149.254.182.200]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6IN0Vft028415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 19 Jul 2013 00:00:33 +0100 From: "Adrian Farrel" To: "'MIB Doctors \(E-mail\)'" Date: Fri, 19 Jul 2013 00:00:32 +0100 Message-ID: <007701ce840a$9cb6d410$d6247c30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6ECpnA2OhkvITdT0io2GvYsHD/EQ== Content-Language: en-gb Subject: [MIB-DOCTORS] Advice on DEFVAL X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:00:42 -0000 Hi, Section 7.9 of RFC 2578 says: > During conceptual row creation, if an instance of a columnar object > is not present as one of the operands in the correspondent management > protocol set operation, then the value of the DEFVAL clause, if > present, indicates an acceptable default value that an agent might > use (especially for a read-only object). This has me puzzled... I completely understand using DEFVAL for a read-create object that is not provided during row creation. I sort of understand using DEFVAL for a read-write object that has not been written. I am not sure I understand the use of DEFVAL for a read-only object. Surely the default value for a read-only object is implementation-specific or defined in the protocol that the MIB module models. I'm pretty sure that back in the glory days when I was writing MIB modules I had my knuckles firmly rapped for using DEFVAL on read-only objects. Thoughts? Adrian From bclaise@cisco.com Fri Jul 19 01:38: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 669F821F9C72; Fri, 19 Jul 2013 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0FqK0aQ6o5I; Fri, 19 Jul 2013 01:38:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9758821F9D17; Fri, 19 Jul 2013 01:38:30 -0700 (PDT) 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 r6J8cQMf014198; Fri, 19 Jul 2013 10:38:26 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6J8bKIR020585; Fri, 19 Jul 2013 10:37:41 +0200 (CEST) Message-ID: <51E8FAC1.6050306@cisco.com> Date: Fri, 19 Jul 2013 10:37:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Haberman References: <20130707215546.424.92752.idtracker@ietfa.amsl.com> <51DAD6C1.7050507@innovationslab.net> <51DDBCF9.4000805@cisco.com> <069d01ce7e1a$81f660a0$85e321e0$@olddog.co.uk> <51DED196.1020900@joelhalpern.com> <0bfc01ce8188$2d6c4a10$8844de30$@olddog.co.uk> <51E82B93.6080600@innovationslab.net> In-Reply-To: <51E82B93.6080600@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Luigi Iannone' , "MIB Doctors \(E-mail\)" , 'The IESG' , lisp-chairs@tools.ietf.org, draft-ietf-lisp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT) 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: Fri, 19 Jul 2013 08:38:39 -0000 > Adrian and I chatted about this. I agree with Adrian's point that > this MIB should be anchored under "experimental" rather than "mib-2". > If/When we get to the point of moving LISP to the Standards Track, we > can do the necessary work to move the MIB to "mib-2". For the record, I disagree but I will not fight that battle any longer (as I expressed to Adrian) Regards, Benoit > > Regards, > Brian > > On 7/15/13 2:21 PM, Adrian Farrel wrote: >> While I see where you are coming from, if we applied this philosophy >> more widely >> we would never use experimental codepoints because moving the work to >> Standards >> Track would require a change of codepoint value. >> >> I do not believe that changing the OID for a MIB module is a big deal. >> I think it improbable that the MIB would not be revised at the time >> that the >> protocol is moved to Standards Track because the protocol would >> probably receive >> a revision. Revising a MIB module usually involves a change of OID. >> >> Bottom line, I don't think anyone has made a substantial case for >> this being in >> mib2, and I stand by my previous email. >> >> I think I should discuss this with Brian to try to reach agreement. >> >> Adrian >> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: 11 July 2013 16:39 >>> To: adrian@olddog.co.uk >>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG'; >>> lisp- >>> chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org >>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: >>> (with DISCUSS >> and >>> COMMENT) >>> >>> Adrian, >>> I have to disagree with your reading. The point I believe the >>> MIB >>> advice is making is that history has show that when we move something >>> from experimetnal status to operational / staqndards track status that >>> we can't change the OIDs used for theetwork management. In ligt of >>> that, if there is a hope of making such a transition some day then it >>> recommends that the experiment use te mib2 branch. >>> >>> f my reading is accurate then ti would seem that the LISP MIB >>> belongs in the mib2 branch. We may or may not be able to move to >>> standards track, but there is certainly a hope of doing so in the >>> future. >>> >>> Yours, >>> Joel >>> >>> On 7/11/2013 5:39 AM, Adrian Farrel wrote: >>>> Hi, >>>> >>>> I read the MIB Doctor's response. I understand it to say that "4181 >> indicates >>>> that assigning under experimental is recommended only for limited >>> experiments, >>>> with no predicted deployment in the Internet." >>>> >>>> I do not know what "no predicted deployment" means. Many people >>>> will make >>>> predictions about many things. >>>> >>>> In 4181 I see >>>> >>>> the experimental subtree { iso 3 6 1 3 } is >>>> used to identify objects that are under development in the >>>> IETF. It >>>> is REQUIRED that objects be moved from the experimental >>>> subtree to >>>> the mgmt subtree when a MIB module enters the IETF standards >>>> track. >>>> >>>> and >>>> >>>> Hence any object that is targeted for >>>> deployment in an operational environment MUST NOT be >>>> registered under >>>> the experimental subtree, irrespective of the standardization >>>> status >>>> of that object. The experimental subtree should be used only for >>>> objects that are intended for limited experimental >>>> deployment. Such >>>> objects typically are defined in Experimental RFCs. >>>> >>>> Maybe "targeted for deployment" is causing a misunderstanding. But >>>> IMHO >>>> Standards Track equates to "targeted for deployment" while >>>> Experimental is >> for >>>> experimentation. Experimentation may well lead to deployment in the >>>> longer >>> term, >>>> but that is not where we are now. >>>> >>>> As far as I understand the definition of Experimental in the IETF >>>> stream of >> the >>>> RFC series, it is consistent with allocation under experimental . >> Furthermore, >>>> the LISP charter is very clear about the Experimental nature of the >>>> output >> of >>>> the working group. >>>> >>>> I think this discussion has clarified my view that this module >>>> should be >>>> positioned under experimental. >>>> >>>> Thanks, >>>> Adrian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Benoit Claise [mailto:bclaise@cisco.com] >>>>> Sent: 10 July 2013 20:59 >>>>> To: Brian Haberman >>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG; >>>>> lisp-chairs@tools.ietf.org; >>>> draft-ietf- >>>>> lisp-mib@tools.ietf.org >>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with >> DISCUSS >>>> and >>>>> COMMENT) >>>>> >>>>> On 8/07/2013 17:12, Brian Haberman wrote: >>>>>> Hi Adrian, >>>>>> >>>>>> On 7/7/13 5:55 PM, Adrian Farrel wrote: >>>>>>> Adrian Farrel has entered the following ballot position for >>>>>>> draft-ietf-lisp-mib-11: Discuss >>>>>>> >>>>>>> When responding, please keep the subject line intact and reply >>>>>>> to all >>>>>>> email addresses included in the To and CC lines. (Feel free to >>>>>>> cut this >>>>>>> introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to >>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> DISCUSS: >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> Two relatively small and easy-to-fix Discuss points >>>>>>> >>>>>>> While it is not against the allocation policy to assign this module >>>>>>> under mib-2, I should have thought that given the Experimental >>>>>>> nature >>>>>>> of this work, it would be better placed under 1.3.6.1.3 >>>>>>> experimental. >>>>>>> >>>>>>> Please let me know that this was considered and sicussed with >>>>>>> the MIB >>>>>>> Doctor. >>>>>> >>>>>> I don't recall this being discussed. I tend to agree that this MIB >>>>>> belongs under the experimental branch. >>>>> Talking with the MIB-doctors, this MIB module would be more suitable >>>>> under mib-2. >>>>> Note: The IESG was copied on the MIB-doctors message, but not the >>>>> authors. So here it is. >>>>> >>>>> Regards, Benoit >>>>>> >>>>>> The other issues I will leave to the authors and shepherd. >>>>>> >>>>>> Regards, >>>>>> Brian >>>>>> >>>>>> >>>> >>>> > > From tnadeau@lucidvision.com Fri Jul 19 06:01: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 5E51011E812C for ; Fri, 19 Jul 2013 06:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXniCg9B+CHd for ; Fri, 19 Jul 2013 06:01:48 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 36EB311E8123 for ; Fri, 19 Jul 2013 06:01:48 -0700 (PDT) Received: from bartimaeus.thenadeaufarm.com (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C155F250594C; Fri, 19 Jul 2013 09:01:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: <007701ce840a$9cb6d410$d6247c30$@olddog.co.uk> Date: Fri, 19 Jul 2013 09:01:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <384332DE-E847-4126-BA16-8B66C26FA744@lucidvision.com> References: <007701ce840a$9cb6d410$d6247c30$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1508) Cc: "'MIB Doctors \(E-mail\)'" Subject: Re: [MIB-DOCTORS] Advice on DEFVAL 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: Fri, 19 Jul 2013 13:01:53 -0000 Its useful as a hint to implementations for a value to start = with, as a means of fostering interop. At least that is the theory. *) Quoting from http://www.ietf.org/rfc/rfc2578.txt?number=3D2578 7.9. Mapping of the DEFVAL clause The DEFVAL clause, which need not be present, defines an acceptable default value which may be used at the discretion of an agent when an object instance is created. That is, the value is a "hint" to implementors. ... Note that if an operand to the management protocol set operation is an instance of a read-only object, then the error `notWritable' [6] will be returned. As such, the DEFVAL clause can be used to provide an acceptable default value that an agent might use. > Hi, >=20 > Section 7.9 of RFC 2578 says: >=20 >> During conceptual row creation, if an instance of a columnar object >> is not present as one of the operands in the correspondent = management >> protocol set operation, then the value of the DEFVAL clause, if >> present, indicates an acceptable default value that an agent might >> use (especially for a read-only object). >=20 > This has me puzzled... >=20 > I completely understand using DEFVAL for a read-create object that is = not > provided during row creation. > I sort of understand using DEFVAL for a read-write object that has not = been > written. > I am not sure I understand the use of DEFVAL for a read-only object. >=20 > Surely the default value for a read-only object is = implementation-specific or > defined in the protocol that the MIB module models. > I'm pretty sure that back in the glory days when I was writing MIB = modules I had > my knuckles firmly rapped for using DEFVAL on read-only objects. >=20 > Thoughts? >=20 > Adrian >=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors >=20 From ietfdbh@comcast.net Fri Jul 19 07:35: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 AD0ED11E82BE for ; Fri, 19 Jul 2013 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.22 X-Spam-Level: X-Spam-Status: No, score=-100.22 tagged_above=-999 required=5 tests=[AWL=0.217, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9haxxwRjezVe for ; Fri, 19 Jul 2013 07:35:40 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D111E82BD for ; Fri, 19 Jul 2013 07:35:40 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2CPg1m0031ZXKqc5AEbfMH; Fri, 19 Jul 2013 14:35:39 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id 2Ebe1m01H2yZEBF3hEbfPR; Fri, 19 Jul 2013 14:35:39 +0000 From: "ietfdbh" To: "'Benoit Claise'" , "'Brian Haberman'" References: <20130707215546.424.92752.idtracker@ietfa.amsl.com> <51DAD6C1.7050507@innovationslab.net> <51DDBCF9.4000805@cisco.com> <069d01ce7e1a$81f660a0$85e321e0$@olddog.co.uk> <51DED196.1020900@joelhalpern.com> <0bfc01ce8188$2d6c4a10$8844de30$@olddog.co.uk> <51E82B93.6080600@innovationslab.net> <51E8FAC1.6050306@cisco.com> In-Reply-To: <51E8FAC1.6050306@cisco.com> Date: Fri, 19 Jul 2013 10:34:47 -0400 Message-ID: <013a01ce848d$1ee91510$5cbb3f30$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbrjz5brDploKJz1IEa8/W1mXbhgJRYRFCAqBN7RYBjcKfKQKmfbIUAaQDlKEBmVM0tAIRmY8Fl14Mm3A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374244539; bh=J+r3YV0tn6H5g9jVAmZcof6mwytzdWBqn9m1Qx2kK2M=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Jvyh6p11yYr3QnPyDMn2Znn1++K1Tr5ppSAgsKqRLpvwYQflYqKyPoQXg2ipCGsH3 s46Lzuekl9hMGweIPEH2Po5iOKTP7Eq5i/8PB67YL73hiPpx/2DEp9XO0y46yxOYjQ n/Ug/M60KdEXhvUENqTpO6igw812pGqN+lkJy6X17g3jLqVoBFQqBgpS7uOywafSTV 4jTBxrmdkWikqQUxlu7fCR8VX1Bp/Hg8EPjll+i8JxgEqnGu1J2rD3B/QIqzQ83e0z 53kjpLWDNBBAfn1BAYhCoGzwMnB6HMKu5Lp+ph6tGOjUlX84BhaYMYRPc+PLzQ9VFP YQYM2DBFOWIMA== Cc: 'Luigi Iannone' , "'MIB Doctors \(E-mail\)'" , 'The IESG' , lisp-chairs@tools.ietf.org, draft-ietf-lisp-mib@tools.ietf.org Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT) 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: Fri, 19 Jul 2013 14:35:54 -0000 Hi, To be clear about the costs of subsequently moving the module to a different subtree, By my interpretation, If lispMib is assigned to { experimental xxx }, you cannot subsequently assign lispMib to { mib-2 xxx }. Per rfc2578, section 3.6, " the semantics associated with the OBJECT IDENTIFIER value is not allowed to change, and a descriptor assigned to a particular OBJECT IDENTIFIER value cannot subsequently be assigned to another." If you change the OID for an object definition, you would also need to change the associated descriptor. Every descriptor under lispMib that is assigned an OID under experimental would also need to be changed to move it under mib-2. MIB Doctors, did I get that right? The work of moving this may be justified in the long run, or not. I'm not sure why rooting this under experimental is important. I do understand that assigning it under mib-2, and then having the experiment fail, would leave a MIB module "taking up space" in the mib-2 subtree. We have lots of MIB modules that never get implemented, so I don't see that as a compelling argument for the work. If you did move it later, the original assignment under experimental would still exist, so you'd be taking up unnecessary space there, PLUS space under mib-2; and if people don't implement the lispMib for whatever reasons, you end up taking up double the space. >From a standpoint of interoperability, which subtree this is assigned is probably not that important from an NMS programming perspective. An NMS typically doesn't care much whether a module falls under mib-2 or experimental; it's just a slightly different OID to use. I do understand the general principle of giving experimental technologies experimental codepoints. The cost for other technologies to be reassigned a codepoint might be less costly than it is for a MIB module. This COULD affect industry adoption; it could be harder to sell the need for an NMS to support an experimental module than a mib-2 module. Maybe that's a good thing, if this module is really an experiment designed for implementation only by those participating in the lisp experiment. Putting this under experimental would hopefully be a red flag that says "think about this before implementing this module." David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors- > bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Friday, July 19, 2013 4:37 AM > To: Brian Haberman > Cc: 'Luigi Iannone'; MIB Doctors (E-mail); 'The IESG'; lisp-chairs@tools.ietf.org; > draft-ietf-lisp-mib@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: > (with DISCUSS and COMMENT) > > > > Adrian and I chatted about this. I agree with Adrian's point that > > this MIB should be anchored under "experimental" rather than "mib-2". > > If/When we get to the point of moving LISP to the Standards Track, we > > can do the necessary work to move the MIB to "mib-2". > For the record, I disagree but I will not fight that battle any longer (as I > expressed to Adrian) > > Regards, Benoit > > > > Regards, > > Brian > > > > On 7/15/13 2:21 PM, Adrian Farrel wrote: > >> While I see where you are coming from, if we applied this philosophy > >> more widely we would never use experimental codepoints because > moving > >> the work to Standards Track would require a change of codepoint > >> value. > >> > >> I do not believe that changing the OID for a MIB module is a big deal. > >> I think it improbable that the MIB would not be revised at the time > >> that the protocol is moved to Standards Track because the protocol > >> would probably receive a revision. Revising a MIB module usually > >> involves a change of OID. > >> > >> Bottom line, I don't think anyone has made a substantial case for > >> this being in mib2, and I stand by my previous email. > >> > >> I think I should discuss this with Brian to try to reach agreement. > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>> Sent: 11 July 2013 16:39 > >>> To: adrian@olddog.co.uk > >>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG'; > >>> lisp- > >>> chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org > >>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: > >>> (with DISCUSS > >> and > >>> COMMENT) > >>> > >>> Adrian, > >>> I have to disagree with your reading. The point I believe the > >>> MIB advice is making is that history has show that when we move > >>> something from experimetnal status to operational / staqndards track > >>> status that we can't change the OIDs used for theetwork management. > >>> In ligt of that, if there is a hope of making such a transition some > >>> day then it recommends that the experiment use te mib2 branch. > >>> > >>> f my reading is accurate then ti would seem that the LISP MIB > >>> belongs in the mib2 branch. We may or may not be able to move to > >>> standards track, but there is certainly a hope of doing so in the > >>> future. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/11/2013 5:39 AM, Adrian Farrel wrote: > >>>> Hi, > >>>> > >>>> I read the MIB Doctor's response. I understand it to say that "4181 > >> indicates > >>>> that assigning under experimental is recommended only for limited > >>> experiments, > >>>> with no predicted deployment in the Internet." > >>>> > >>>> I do not know what "no predicted deployment" means. Many people > >>>> will make predictions about many things. > >>>> > >>>> In 4181 I see > >>>> > >>>> the experimental subtree { iso 3 6 1 3 } is > >>>> used to identify objects that are under development in the > >>>> IETF. It > >>>> is REQUIRED that objects be moved from the experimental > >>>> subtree to > >>>> the mgmt subtree when a MIB module enters the IETF standards > >>>> track. > >>>> > >>>> and > >>>> > >>>> Hence any object that is targeted for > >>>> deployment in an operational environment MUST NOT be > >>>> registered under > >>>> the experimental subtree, irrespective of the standardization > >>>> status > >>>> of that object. The experimental subtree should be used only for > >>>> objects that are intended for limited experimental deployment. > >>>> Such > >>>> objects typically are defined in Experimental RFCs. > >>>> > >>>> Maybe "targeted for deployment" is causing a misunderstanding. But > >>>> IMHO Standards Track equates to "targeted for deployment" while > >>>> Experimental is > >> for > >>>> experimentation. Experimentation may well lead to deployment in the > >>>> longer > >>> term, > >>>> but that is not where we are now. > >>>> > >>>> As far as I understand the definition of Experimental in the IETF > >>>> stream of > >> the > >>>> RFC series, it is consistent with allocation under experimental . > >> Furthermore, > >>>> the LISP charter is very clear about the Experimental nature of the > >>>> output > >> of > >>>> the working group. > >>>> > >>>> I think this discussion has clarified my view that this module > >>>> should be positioned under experimental. > >>>> > >>>> Thanks, > >>>> Adrian > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Benoit Claise [mailto:bclaise@cisco.com] > >>>>> Sent: 10 July 2013 20:59 > >>>>> To: Brian Haberman > >>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG; > >>>>> lisp-chairs@tools.ietf.org; > >>>> draft-ietf- > >>>>> lisp-mib@tools.ietf.org > >>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: > >>>>> (with > >> DISCUSS > >>>> and > >>>>> COMMENT) > >>>>> > >>>>> On 8/07/2013 17:12, Brian Haberman wrote: > >>>>>> Hi Adrian, > >>>>>> > >>>>>> On 7/7/13 5:55 PM, Adrian Farrel wrote: > >>>>>>> Adrian Farrel has entered the following ballot position for > >>>>>>> draft-ietf-lisp-mib-11: Discuss > >>>>>>> > >>>>>>> When responding, please keep the subject line intact and reply > >>>>>>> to all email addresses included in the To and CC lines. (Feel > >>>>>>> free to cut this introductory paragraph, however.) > >>>>>>> > >>>>>>> > >>>>>>> Please refer to > >>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html > >>>>>>> for more information about IESG DISCUSS and COMMENT > positions. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ---------------------------------------------------------------- > >>>>>>> ------ > >>>>>>> > >>>>>>> DISCUSS: > >>>>>>> ---------------------------------------------------------------- > >>>>>>> ------ > >>>>>>> > >>>>>>> > >>>>>>> Two relatively small and easy-to-fix Discuss points > >>>>>>> > >>>>>>> While it is not against the allocation policy to assign this > >>>>>>> module under mib-2, I should have thought that given the > >>>>>>> Experimental nature of this work, it would be better placed > >>>>>>> under 1.3.6.1.3 experimental. > >>>>>>> > >>>>>>> Please let me know that this was considered and sicussed with > >>>>>>> the MIB Doctor. > >>>>>> > >>>>>> I don't recall this being discussed. I tend to agree that this > >>>>>> MIB belongs under the experimental branch. > >>>>> Talking with the MIB-doctors, this MIB module would be more > >>>>> suitable under mib-2. > >>>>> Note: The IESG was copied on the MIB-doctors message, but not the > >>>>> authors. So here it is. > >>>>> > >>>>> Regards, Benoit > >>>>>> > >>>>>> The other issues I will leave to the authors and shepherd. > >>>>>> > >>>>>> Regards, > >>>>>> Brian > >>>>>> > >>>>>> > >>>> > >>>> > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From randy_presuhn@mindspring.com Fri Jul 19 14:29: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 EB75121F9C37 for ; Fri, 19 Jul 2013 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrOaxUymZjix for ; Fri, 19 Jul 2013 14:29:44 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id A40C621F9C70 for ; Fri, 19 Jul 2013 14:29:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YclWo8XYjRhVYfDPl/CVHsJ8TSj7u6kN0egjdGlicTfh1Wru0V2FEhJRnO16wXuf; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1V0IEz-0007p3-KZ; Fri, 19 Jul 2013 17:29:29 -0400 Received: from 99.101.143.63 by webmail.earthlink.net with HTTP; Fri, 19 Jul 2013 17:29:29 -0400 Message-ID: <21573720.1374269369628.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Fri, 19 Jul 2013 14:29:29 -0700 (GMT-07:00) From: Randy Presuhn To: Thomas Nadeau , Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08e7f3fa14b2f6f027d3e64fb462c51da2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "Giles Heron \(giheron\)" , draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org, mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 21:29:51 -0000 Hi - >From: Thomas Nadeau >Sent: Jul 17, 2013 2:02 PM >To: Andy Bierman >Cc: Randy Presuhn , "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , "Giles Heron (giheron)" , mib-doctors@ietf.org, draft-ietf-l2vpn-vpls-mib.all@tools.ietf.org >Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10 ... >> A: in the end it doesn't matter. NMS developers are not >> using SNMP for configuration. > > I agree. Having this debate is a waste of time; > the industry has voted a long time ago... This list doesn't make sense as place for that debate. We were asked to comment on a question regarding a specific aspect of MIB module design. *That* is what we should be talking about. Steve has suggested one approach to accomplish what the WG wanted to do, I've suggested another approach, and Andy seems to be advocating "no, you shouldn't even try to use SNMP to do this." If that last case is indeed the consensus of the MIB doctors, then it's time to re-do the review guidelines to say that even though SNMP can be used for these things, it's NOT RECOMMENDED because "the industry" is doing something else. Randy From dbharrington@comcast.net Sat Jul 20 08:49:28 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 3BFA821F943C for ; Sat, 20 Jul 2013 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.064 X-Spam-Level: X-Spam-Status: No, score=0.064 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ4niHDyTiRF for ; Sat, 20 Jul 2013 08:49:23 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 721BD21F9C2E for ; Sat, 20 Jul 2013 08:49:23 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 2foV1m0050SCNGk5BfpNZj; Sat, 20 Jul 2013 15:49:22 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id 2fpK1m00N2yZEBF3VfpM0u; Sat, 20 Jul 2013 15:49:22 +0000 User-Agent: Microsoft-MacOutlook/14.3.5.130515 Date: Sat, 20 Jul 2013 11:49:18 -0400 From: David Harrington To: MIB Doctors Message-ID: Thread-Topic: nfs mibs? In-Reply-To: <00c701ce8184$e2b12750$a81375f0$@comcast.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374335362; bh=T3y37yOwm5mvlj8bm4euxvKSecgt3k6HPwpsqj2zI6g=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=DwKgjqTrrbauCxwN6lv3HfOn4ejHRyHdcwgwEGbMiQkV9+/d7St0i58u86JCy6oMb 9dw+l5D+ap18NCYDMjYm30TxnZ/s+X74Xk3IcM1iPMVWcpuK+iC/ZLjS+S7rv2+MVA Hmyhf/PNWpQoFAYBlE0O3DMHXXnW1sXSPmr/7g3sOzlt/IshVHsBBcuU6fj+2NfcO/ +lk7EpOFZfwWDUHyk6KQKG1qQ22fW84BDh5KiRgvMsyMjPCmqqY4TjVLUAV5At0Z9B bMLADd+l3DJB8EmkIseeuWH5yc7zh0lmul9Dgttf8qtUBIchMZLqFPEy8n+CQjFjbl tW0nbiasBbflw== Subject: [MIB-DOCTORS] FW: nfs mibs? 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: Sat, 20 Jul 2013 15:49:28 -0000 Hi, Mike and I have been having a small discussion about mibs for nfsv4. He asked when and why the nfsv4 wg charter dropped MIB deliverables. I did some research to answer the question. It is in the email message below. Mike has discussed with me VMWare's need for NFS MIBs a number of times.of my=20 So my email also has a few opinions and suggestions. I (and I assume Mike) would be interested in opinions and insights from other MIB doctors as well. --=20 David Harrington dbharrington@comcast.net +1-603-828-1401 On 7/15/13 1:58 PM, "ietfdbh" wrote: >Hi Mike, >=20 >I notice the slides are from 2003. >The current charter includes deliverables for 2012, so I assume it was >approved sometime between 2003 and 2012. >I was AD for Mar2010-Mar2012, and I don=B9t remember approving a revised >charter on my watch. >=20 >[hell, I was working hard just to get them to submit documents they=B9d >been working on for years, and were fine-tuning to death ;-) >I did push them to get a new charter submitted, but don=B9t know that I >succeeded while on my watch.] >=20 >Looking at the history tab of the WG page, the charter info changed on >3-29-12. >Charter changes weren=B9t really tracked for a long time, so the history >might be incomplete. >I think my last day as AD was 3-28-12. >I notice the IETF83 proceedings for NFSv4 lists Martin as the AD. >The agenda includes a charter discussion, but no slides for a charter >review. >I checked the IESG official and narrative minutes and found no discussion >of an NFS recharter from 1-1-12 to 4-1-12 and found none. >I don=B9t know if I can determine when those deliverables were dropped from >the charter. >=20 >=20 >After getting this far, I decided to check proceedings further back. >The MIB modules are not in the deliverables for ietf81. >Going to binary search: ietf58-yes; ietf70-yes; ietf75-no; ietf72-yes; >ietf73-yes; ietf74-no; >So, it was dropped apparently with the 2009-03-18 revision of the charter. >Ietf74 meeting minutes mention an updated charter, with no detailed >discussion of the changes. >Ietf73 meeting minutes don=B9t mention mibs or management. >Ietf72 minutes mention charter update, but no mention of mibs or >management. >Ietf71 minutes do not mention mibs or management. >So I have not been able to establish WG consensus to drop them in the >official minutes. >=20 >So I checked IESG minutes at http://www.ietf.org/iesg/minutes/2009/ >IESG approved the new charter in the 3-12-09 telechat. >In the narrative minutes for 3-12-09, external review completed, nobody >objected to the new charter. >In the narrative minutes for 2-26-09, nobody objected to the new charter, >but called for external review. >In the narrative minutes for earlier 2009 telechats, NFS wasn=B9t mentioned >(i.e. was not on the telechat agenda) >=20 >So the MIB deliverables appear to have been quietly dropped, without >discussion, in March 2009. >=20 >These were dropped years ago, so it might be a hard sell to resurrect >them as charter deliverables, but not impossible. >You could submit an NFS MIB to the NFSv4 WG if you want. I=B9m not sure it >would be taken seriously since they=B9re working on other stuff. >You might be able to push it as a YANG module deliverable in netmod or >opsawg.=20 >YANG proponents are realizing they are facing an uphill battle with few >standardized modules, and might appreciate another module proposal. But >you=B9ll really need NFSv4 WG support, and a MIB might be an easier sell, >especially if there are proprietary mibs to work from. >=20 >Virtualization, clouds, and storage migration are trending high now (and >management thereof is sorely lacking). >As a developer for VMWare, and a MIB Doctor, your opinion might carry >some weight with the NFSv4 WG. >And you might be able to play up the fact that iSCSI and Fibre Channel >have current MIBs done by the storm WG (under David Black). >So you might want to start the discussion with the NFSv4 WG as =B3how do >you intend your stuff to be managed?=B2 >I really expect the WG response to be =B3sure, go ahead=B2. >If you want to raise this to a higher abstraction, and make it about >managing virtualization and migration, the TSV area might be an >appropriate place to sell the Ads on better management of virtualization. >You might also consider bringing a proposal to TSVWG (TSV=B9s OPSAWG >equivalent), where David Black is co-chair. >MIBs that refer to lower-level MIBs, like iSCSI and ifcp MIBs, might >force NFSv4 to think about MIBs. >Now would be the time to prepare that presentation about the need for >managing virtual environments using IETF protocols. >=20 >Hope this helps. >=20 >David Harrington >ietfdbh@comcast.net > >+1-603-828-1401 >From: Michael MacFaden [mailto:mrm@vmware.com] >Sent: Monday, July 15, 2013 6:56 AM >To: ietfdbh >Subject: nfs mibs? > > >=20 >Hi David, > >=20 > >Hope your summer is going nicely. I was trying to find > >the NFS mib modules, saw here they were going to proposed > >=20 > >http://www.ietf.org/proceedings/58/slides/nfsv4-0.pdf > >listing them as wg milestones. > >=20 > >Don't recall seeing mib-doctor reviews or got published? > >=20 > >Might you recall? > >=20 > >Thanks, > >Mike > >=20 From dromasca@avaya.com Sun Jul 21 02:51:14 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 5E1C221E8088; Sun, 21 Jul 2013 02:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFPgtdh5G5Xt; Sun, 21 Jul 2013 02:51:08 -0700 (PDT) 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 2E9AE21E804E; Sun, 21 Jul 2013 02:51:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUKACSu61HGmAcV/2dsb2JhbABQCoJlITVQrCqNBYcAgRYWdIIkAQEBAQIBAQEBDyg0CwwEAgEIDQEDBAEBAQoUCQcnCxQJCAIEAQ0FCAEZh2gGAQuaQZsTF45UBgQGgQExAgUGgwpuA54jiweBWYE5gWgJFyI X-IronPort-AV: E=Sophos;i="4.89,712,1367985600"; d="scan'208";a="20388160" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Jul 2013 05:51:06 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2013 05:48:45 -0400 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; Sun, 21 Jul 2013 05:51:04 -0400 From: "Romascanu, Dan (Dan)" To: Benoit Claise , Brian Haberman Thread-Topic: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT) Thread-Index: AQHOhFth5WkEuiUswkG+Kao7fYA8bplu4x4Q Date: Sun, 21 Jul 2013 09:51:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12878AE7@AZ-FFEXMB04.global.avaya.com> References: <20130707215546.424.92752.idtracker@ietfa.amsl.com> <51DAD6C1.7050507@innovationslab.net> <51DDBCF9.4000805@cisco.com> <069d01ce7e1a$81f660a0$85e321e0$@olddog.co.uk> <51DED196.1020900@joelhalpern.com> <0bfc01ce8188$2d6c4a10$8844de30$@olddog.co.uk> <51E82B93.6080600@innovationslab.net> <51E8FAC1.6050306@cisco.com> In-Reply-To: <51E8FAC1.6050306@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 Cc: 'Luigi Iannone' , "MIB Doctors \(E-mail\)" , 'The IESG' , "lisp-chairs@tools.ietf.org" , "draft-ietf-lisp-mib@tools.ietf.org" Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT) 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: Sun, 21 Jul 2013 09:51:14 -0000 Hi, I am surprised by the argumentation.=20 > >> Bottom line, I don't think anyone has made a substantial case for > >> this being in mib2, and I stand by my previous email. I believe that substantial and argumented cases against locating the MIB un= der experimental were made in the initial MIB Doctor advice, and than subst= antial and later in the discussion by Joel and DBH. > > If/When we get to the point of moving LISP to the Standards Track, we > > can do the necessary work to move the MIB to "mib-2". Is this clear to all IESG members participating in the discussion that ther= e is no such thing like 'moving the MIB to "mib-2"? You cannot just change = the OIDs, you also need to change all the associated descriptors (names of = all objects) in the MIB module. In other words deprecate the MIB module und= er experimental and create a new MIB module under mib-2 which may look very= similar but has different OIDs and descriptors (names). Plus the tools and= applications already using the older MIB modules will need to be migrated = to the new OIDs and object names and probably support both for a period of = transition.=20 Maybe this is the argumentation that was missing (although it was already s= aid in other words)? Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] > On Behalf Of Benoit Claise > Sent: Friday, July 19, 2013 11:37 AM > To: Brian Haberman > Cc: 'Luigi Iannone'; MIB Doctors (E-mail); 'The IESG'; lisp- > chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org > Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp- > mib-11: (with DISCUSS and COMMENT) >=20 >=20 > > Adrian and I chatted about this. I agree with Adrian's point that > > this MIB should be anchored under "experimental" rather than "mib-2". > > If/When we get to the point of moving LISP to the Standards Track, we > > can do the necessary work to move the MIB to "mib-2". > For the record, I disagree but I will not fight that battle any longer > (as I expressed to Adrian) >=20 > Regards, Benoit > > > > Regards, > > Brian > > > > On 7/15/13 2:21 PM, Adrian Farrel wrote: > >> While I see where you are coming from, if we applied this philosophy > >> more widely we would never use experimental codepoints because moving > >> the work to Standards Track would require a change of codepoint > >> value. > >> > >> I do not believe that changing the OID for a MIB module is a big > deal. > >> I think it improbable that the MIB would not be revised at the time > >> that the protocol is moved to Standards Track because the protocol > >> would probably receive a revision. Revising a MIB module usually > >> involves a change of OID. > >> > >> Bottom line, I don't think anyone has made a substantial case for > >> this being in mib2, and I stand by my previous email. > >> > >> I think I should discuss this with Brian to try to reach agreement. > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>> Sent: 11 July 2013 16:39 > >>> To: adrian@olddog.co.uk > >>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG'; > >>> lisp- > >>> chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org > >>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: > >>> (with DISCUSS > >> and > >>> COMMENT) > >>> > >>> Adrian, > >>> I have to disagree with your reading. The point I believe the > >>> MIB advice is making is that history has show that when we move > >>> something from experimetnal status to operational / staqndards track > >>> status that we can't change the OIDs used for theetwork management. > >>> In ligt of that, if there is a hope of making such a transition some > >>> day then it recommends that the experiment use te mib2 branch. > >>> > >>> f my reading is accurate then ti would seem that the LISP MIB > >>> belongs in the mib2 branch. We may or may not be able to move to > >>> standards track, but there is certainly a hope of doing so in the > >>> future. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/11/2013 5:39 AM, Adrian Farrel wrote: > >>>> Hi, > >>>> > >>>> I read the MIB Doctor's response. I understand it to say that "4181 > >> indicates > >>>> that assigning under experimental is recommended only for limited > >>> experiments, > >>>> with no predicted deployment in the Internet." > >>>> > >>>> I do not know what "no predicted deployment" means. Many people > >>>> will make predictions about many things. > >>>> > >>>> In 4181 I see > >>>> > >>>> the experimental subtree { iso 3 6 1 3 } is > >>>> used to identify objects that are under development in the > >>>> IETF. It > >>>> is REQUIRED that objects be moved from the experimental > >>>> subtree to > >>>> the mgmt subtree when a MIB module enters the IETF standards > >>>> track. > >>>> > >>>> and > >>>> > >>>> Hence any object that is targeted for > >>>> deployment in an operational environment MUST NOT be > >>>> registered under > >>>> the experimental subtree, irrespective of the standardization > >>>> status > >>>> of that object. The experimental subtree should be used only > for > >>>> objects that are intended for limited experimental deployment. > >>>> Such > >>>> objects typically are defined in Experimental RFCs. > >>>> > >>>> Maybe "targeted for deployment" is causing a misunderstanding. But > >>>> IMHO Standards Track equates to "targeted for deployment" while > >>>> Experimental is > >> for > >>>> experimentation. Experimentation may well lead to deployment in the > >>>> longer > >>> term, > >>>> but that is not where we are now. > >>>> > >>>> As far as I understand the definition of Experimental in the IETF > >>>> stream of > >> the > >>>> RFC series, it is consistent with allocation under experimental . > >> Furthermore, > >>>> the LISP charter is very clear about the Experimental nature of the > >>>> output > >> of > >>>> the working group. > >>>> > >>>> I think this discussion has clarified my view that this module > >>>> should be positioned under experimental. > >>>> > >>>> Thanks, > >>>> Adrian > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Benoit Claise [mailto:bclaise@cisco.com] > >>>>> Sent: 10 July 2013 20:59 > >>>>> To: Brian Haberman > >>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG; > >>>>> lisp-chairs@tools.ietf.org; > >>>> draft-ietf- > >>>>> lisp-mib@tools.ietf.org > >>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: > >>>>> (with > >> DISCUSS > >>>> and > >>>>> COMMENT) > >>>>> > >>>>> On 8/07/2013 17:12, Brian Haberman wrote: > >>>>>> Hi Adrian, > >>>>>> > >>>>>> On 7/7/13 5:55 PM, Adrian Farrel wrote: > >>>>>>> Adrian Farrel has entered the following ballot position for > >>>>>>> draft-ietf-lisp-mib-11: Discuss > >>>>>>> > >>>>>>> When responding, please keep the subject line intact and reply > >>>>>>> to all email addresses included in the To and CC lines. (Feel > >>>>>>> free to cut this introductory paragraph, however.) > >>>>>>> > >>>>>>> > >>>>>>> Please refer to > >>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html > >>>>>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ---------------------------------------------------------------- > >>>>>>> ------ > >>>>>>> > >>>>>>> DISCUSS: > >>>>>>> ---------------------------------------------------------------- > >>>>>>> ------ > >>>>>>> > >>>>>>> > >>>>>>> Two relatively small and easy-to-fix Discuss points > >>>>>>> > >>>>>>> While it is not against the allocation policy to assign this > >>>>>>> module under mib-2, I should have thought that given the > >>>>>>> Experimental nature of this work, it would be better placed > >>>>>>> under 1.3.6.1.3 experimental. > >>>>>>> > >>>>>>> Please let me know that this was considered and sicussed with > >>>>>>> the MIB Doctor. > >>>>>> > >>>>>> I don't recall this being discussed. I tend to agree that this > >>>>>> MIB belongs under the experimental branch. > >>>>> Talking with the MIB-doctors, this MIB module would be more > >>>>> suitable under mib-2. > >>>>> Note: The IESG was copied on the MIB-doctors message, but not the > >>>>> authors. So here it is. > >>>>> > >>>>> Regards, Benoit > >>>>>> > >>>>>> The other issues I will leave to the authors and shepherd. > >>>>>> > >>>>>> Regards, > >>>>>> Brian > >>>>>> > >>>>>> > >>>> > >>>> > > > > >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Sun Jul 21 14:18:05 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 6C1DA11E8102; Sun, 21 Jul 2013 14:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyGO0ITQjxez; Sun, 21 Jul 2013 14:18:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9F11E80A5; Sun, 21 Jul 2013 14:18:00 -0700 (PDT) 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 r6LLHt58027282; Sun, 21 Jul 2013 23:17:55 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6LLGcIf010683; Sun, 21 Jul 2013 23:16:53 +0200 (CEST) Message-ID: <51EC4FB6.4020501@cisco.com> Date: Sun, 21 Jul 2013 23:16:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20130707215546.424.92752.idtracker@ietfa.amsl.com> <51DAD6C1.7050507@innovationslab.net> <51DDBCF9.4000805@cisco.com> <069d01ce7e1a$81f660a0$85e321e0$@olddog.co.uk> <51DED196.1020900@joelhalpern.com> <0bfc01ce8188$2d6c4a10$8844de30$@olddog.co.uk> <51E82B93.6080600@innovationslab.net> <51E8FAC1.6050306@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA12878AE7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12878AE7@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Haberman , "draft-ietf-lisp-mib@tools.ietf.org" , "MIB Doctors \(E-mail\)" , "lisp-chairs@tools.ietf.org" , 'The IESG' , 'Luigi Iannone' Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: (with DISCUSS and COMMENT) 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: Sun, 21 Jul 2013 21:18:05 -0000 On 21/07/2013 11:51, Romascanu, Dan (Dan) wrote: > Hi, > > I am surprised by the argumentation. > >>>> Bottom line, I don't think anyone has made a substantial case for >>>> this being in mib2, and I stand by my previous email. > I believe that substantial and argumented cases against locating the MIB under experimental were made in the initial MIB Doctor advice, and than substantial and later in the discussion by Joel and DBH. > >>> If/When we get to the point of moving LISP to the Standards Track, we >>> can do the necessary work to move the MIB to "mib-2". > > Is this clear to all IESG members participating in the discussion that there is no such thing like 'moving the MIB to "mib-2"? You cannot just change the OIDs, you also need to change all the associated descriptors (names of all objects) in the MIB module. In other words deprecate the MIB module under experimental and create a new MIB module under mib-2 which may look very similar but has different OIDs and descriptors (names). Plus the tools and applications already using the older MIB modules will need to be migrated to the new OIDs and object names and probably support both for a period of transition. "and support both for a period of transition" is a real drawback in my opinion. Regards, Benoit > > Maybe this is the argumentation that was missing (although it was already said in other words)? > > Regards, > > Dan > >> -----Original Message----- >> From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] >> On Behalf Of Benoit Claise >> Sent: Friday, July 19, 2013 11:37 AM >> To: Brian Haberman >> Cc: 'Luigi Iannone'; MIB Doctors (E-mail); 'The IESG'; lisp- >> chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org >> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-lisp- >> mib-11: (with DISCUSS and COMMENT) >> >> >>> Adrian and I chatted about this. I agree with Adrian's point that >>> this MIB should be anchored under "experimental" rather than "mib-2". >>> If/When we get to the point of moving LISP to the Standards Track, we >>> can do the necessary work to move the MIB to "mib-2". >> For the record, I disagree but I will not fight that battle any longer >> (as I expressed to Adrian) >> >> Regards, Benoit >>> Regards, >>> Brian >>> >>> On 7/15/13 2:21 PM, Adrian Farrel wrote: >>>> While I see where you are coming from, if we applied this philosophy >>>> more widely we would never use experimental codepoints because moving >>>> the work to Standards Track would require a change of codepoint >>>> value. >>>> >>>> I do not believe that changing the OID for a MIB module is a big >> deal. >>>> I think it improbable that the MIB would not be revised at the time >>>> that the protocol is moved to Standards Track because the protocol >>>> would probably receive a revision. Revising a MIB module usually >>>> involves a change of OID. >>>> >>>> Bottom line, I don't think anyone has made a substantial case for >>>> this being in mib2, and I stand by my previous email. >>>> >>>> I think I should discuss this with Brian to try to reach agreement. >>>> >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: 11 July 2013 16:39 >>>>> To: adrian@olddog.co.uk >>>>> Cc: 'Benoit Claise'; 'Brian Haberman'; 'Luigi Iannone'; 'The IESG'; >>>>> lisp- >>>>> chairs@tools.ietf.org; draft-ietf-lisp-mib@tools.ietf.org >>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: >>>>> (with DISCUSS >>>> and >>>>> COMMENT) >>>>> >>>>> Adrian, >>>>> I have to disagree with your reading. The point I believe the >>>>> MIB advice is making is that history has show that when we move >>>>> something from experimetnal status to operational / staqndards track >>>>> status that we can't change the OIDs used for theetwork management. >>>>> In ligt of that, if there is a hope of making such a transition some >>>>> day then it recommends that the experiment use te mib2 branch. >>>>> >>>>> f my reading is accurate then ti would seem that the LISP MIB >>>>> belongs in the mib2 branch. We may or may not be able to move to >>>>> standards track, but there is certainly a hope of doing so in the >>>>> future. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/11/2013 5:39 AM, Adrian Farrel wrote: >>>>>> Hi, >>>>>> >>>>>> I read the MIB Doctor's response. I understand it to say that "4181 >>>> indicates >>>>>> that assigning under experimental is recommended only for limited >>>>> experiments, >>>>>> with no predicted deployment in the Internet." >>>>>> >>>>>> I do not know what "no predicted deployment" means. Many people >>>>>> will make predictions about many things. >>>>>> >>>>>> In 4181 I see >>>>>> >>>>>> the experimental subtree { iso 3 6 1 3 } is >>>>>> used to identify objects that are under development in the >>>>>> IETF. It >>>>>> is REQUIRED that objects be moved from the experimental >>>>>> subtree to >>>>>> the mgmt subtree when a MIB module enters the IETF standards >>>>>> track. >>>>>> >>>>>> and >>>>>> >>>>>> Hence any object that is targeted for >>>>>> deployment in an operational environment MUST NOT be >>>>>> registered under >>>>>> the experimental subtree, irrespective of the standardization >>>>>> status >>>>>> of that object. The experimental subtree should be used only >> for >>>>>> objects that are intended for limited experimental deployment. >>>>>> Such >>>>>> objects typically are defined in Experimental RFCs. >>>>>> >>>>>> Maybe "targeted for deployment" is causing a misunderstanding. But >>>>>> IMHO Standards Track equates to "targeted for deployment" while >>>>>> Experimental is >>>> for >>>>>> experimentation. Experimentation may well lead to deployment in the >>>>>> longer >>>>> term, >>>>>> but that is not where we are now. >>>>>> >>>>>> As far as I understand the definition of Experimental in the IETF >>>>>> stream of >>>> the >>>>>> RFC series, it is consistent with allocation under experimental . >>>> Furthermore, >>>>>> the LISP charter is very clear about the Experimental nature of the >>>>>> output >>>> of >>>>>> the working group. >>>>>> >>>>>> I think this discussion has clarified my view that this module >>>>>> should be positioned under experimental. >>>>>> >>>>>> Thanks, >>>>>> Adrian >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Benoit Claise [mailto:bclaise@cisco.com] >>>>>>> Sent: 10 July 2013 20:59 >>>>>>> To: Brian Haberman >>>>>>> Cc: Adrian Farrel; Luigi Iannone; The IESG; >>>>>>> lisp-chairs@tools.ietf.org; >>>>>> draft-ietf- >>>>>>> lisp-mib@tools.ietf.org >>>>>>> Subject: Re: Adrian Farrel's Discuss on draft-ietf-lisp-mib-11: >>>>>>> (with >>>> DISCUSS >>>>>> and >>>>>>> COMMENT) >>>>>>> >>>>>>> On 8/07/2013 17:12, Brian Haberman wrote: >>>>>>>> Hi Adrian, >>>>>>>> >>>>>>>> On 7/7/13 5:55 PM, Adrian Farrel wrote: >>>>>>>>> Adrian Farrel has entered the following ballot position for >>>>>>>>> draft-ietf-lisp-mib-11: Discuss >>>>>>>>> >>>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>>> to all email addresses included in the To and CC lines. (Feel >>>>>>>>> free to cut this introductory paragraph, however.) >>>>>>>>> >>>>>>>>> >>>>>>>>> Please refer to >>>>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> DISCUSS: >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> >>>>>>>>> Two relatively small and easy-to-fix Discuss points >>>>>>>>> >>>>>>>>> While it is not against the allocation policy to assign this >>>>>>>>> module under mib-2, I should have thought that given the >>>>>>>>> Experimental nature of this work, it would be better placed >>>>>>>>> under 1.3.6.1.3 experimental. >>>>>>>>> >>>>>>>>> Please let me know that this was considered and sicussed with >>>>>>>>> the MIB Doctor. >>>>>>>> I don't recall this being discussed. I tend to agree that this >>>>>>>> MIB belongs under the experimental branch. >>>>>>> Talking with the MIB-doctors, this MIB module would be more >>>>>>> suitable under mib-2. >>>>>>> Note: The IESG was copied on the MIB-doctors message, but not the >>>>>>> authors. So here it is. >>>>>>> >>>>>>> Regards, Benoit >>>>>>>> The other issues I will leave to the authors and shepherd. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>> >>> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > From dbharrington@comcast.net Sat Jul 27 05:50: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 CD7A221F92B8 for ; Sat, 27 Jul 2013 05:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.382 X-Spam-Level: **** X-Spam-Status: No, score=4.382 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7ZQRk8IIn6g for ; Sat, 27 Jul 2013 05:50:37 -0700 (PDT) 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 4C77921F93BF for ; Sat, 27 Jul 2013 05:50:36 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id 5Qft1m0071uE5Es5EQqZ83; Sat, 27 Jul 2013 12:50:33 +0000 Received: from sz0047.wc.mail.comcast.net ([68.87.26.138]) by omta16.westchester.pa.mail.comcast.net with comcast id 5QqZ1m00e2ymm843cQqZab; Sat, 27 Jul 2013 12:50:33 +0000 Date: Sat, 27 Jul 2013 12:50:33 +0000 (UTC) From: dbharrington@comcast.net To: nomcom05@ietf.org, admiraltyoffice@aol.com, sommerfeld@sun.com, liyan_77@huawei.com, mib-doctors@ietf.org, albert@ons-huis.net, hartmans-ietf@mit.edu, klarochelle@mklcpa.com, ah@tr-sys.de, iquander@aol.com, mundy@tislabs.com Message-ID: <123402673.1866343.1374929433221.JavaMail.root@sz0047a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [::ffff:113.169.164.242] X-Mailer: Zimbra 6.0.13_GA_2944 (zclient/6.0.13_GA_2944) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374929433; bh=5G3oLyiMtug4jDNpO6rfMUzLVZ7Z5G1IeTji/sTvnuc=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=AQ87r4DqxhKlCazfGli3SzNUsaLoN74mxfNo+B4YuM6tfZrDcJ9Gdf9cZ0QwK6H4x hh53EMZcoVtg6rvYA0lJIylpFxXgL8L+KVU2NzJ+NxBHQP5/GDEF4pEz94OfVaiXEn FS99V+Z2rcKd7Kd7t26iuzbH6PIUAymeuzVEYHKuM4WR70hEor87jYhYEAItQZ0S9h tH8UpoJKxu3ARtT9Htb72N2Kmfj97XLT7jxNjSv/9drPegGXaXd1U8+0MtTr10LHvn GSZh6NDGbgVSGjJvuHhZGQQbDVUNXlX5vpRRaIWY6vVrpeT1SdTVgeNggnhuPQPY9K csBVnD6WcO/oQ== Subject: Re: [MIB-DOCTORS] hello! 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: Sat, 27 Jul 2013 12:50:43 -0000 http://whaouh.com/www.cnnnews.com.replynews.index68.php?topicid=9ao From bclaise@cisco.com Sat Jul 27 08:24: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 4FACB21F94DC for ; Sat, 27 Jul 2013 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.322 X-Spam-Level: X-Spam-Status: No, score=-9.322 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id necS9sUBjK78 for ; Sat, 27 Jul 2013 08:24:16 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 408C821F9AA2 for ; Sat, 27 Jul 2013 08:24:10 -0700 (PDT) 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 r6RFNcj9010427; Sat, 27 Jul 2013 17:23:38 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6RFLHP7007657; Sat, 27 Jul 2013 17:21:33 +0200 (CEST) Message-ID: <51F3E551.6080203@cisco.com> Date: Sat, 27 Jul 2013 17:20:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dbharrington@comcast.net References: <123402673.1866343.1374929433221.JavaMail.root@sz0047a.westchester.pa.mail.comcast.net> In-Reply-To: <123402673.1866343.1374929433221.JavaMail.root@sz0047a.westchester.pa.mail.comcast.net> Content-Type: multipart/alternative; boundary="------------050708040602020203020202" Cc: liyan_77@huawei.com, ah@tr-sys.de, nomcom05@ietf.org, mundy@tislabs.com, mib-doctors@ietf.org, sommerfeld@sun.com, albert@ons-huis.net, admiraltyoffice@aol.com, iquander@aol.com, hartmans-ietf@mit.edu, klarochelle@mklcpa.com Subject: Re: [MIB-DOCTORS] hello! -> don't click 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: Sat, 27 Jul 2013 15:24:20 -0000 This is a multi-part message in MIME format. --------------050708040602020203020202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > http://whaouh.com/www.cnnnews.com.replynews.index68.php?topicid=9ao > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > > --------------050708040602020203020202 Content-Type: multipart/related; boundary="------------070507010902080703090500" --------------070507010902080703090500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
http://whaouh.com/www.cnnnews.com.replynews.index68.php?topicid=9ao
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

--------------070507010902080703090500 Content-Type: image/png; name="bjjejjbb.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bjjejjbb.png" iVBORw0KGgoAAAANSUhEUgAAA5kAAAKFCAIAAADJV7olAAAgAElEQVR4nO3dsa4syXHu+3Ho HByAFulLpmSQrqBXkB5BMpdB0NMD8J5HIB2BIAQIEA2SgFyBpCPvQPMAh6RBgxfQuQbHkCER A5HD6WssTrN2ZUTkl5FR3ZXV/x8GG72rMyMjs7KqYvdas9ZHNwAAAGBNHz07AQAAACCJWhYA AACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYA AACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYA AACropat8fP/9/9bOj4AAMCKqGUL/O//88u/+/sf/e//88tF4wMAACyKWrbA3/39j7729r/+ 7u9/tGh8AACARVHLFvja2/96/2/R+AAAAIuili1ALQsAAPAU1LIFqGUBAACeglq2ALUsAADA U1DLjjF/NlZQa47+LK2j4wMAAFwJtewA72djebXm6M/SOjo+AADAxVDLDvB+NpZXa47+LK2j 4wMAAFwMtewAr6YcPf6s+AAAABdDLWsb+r7VRK35lPgAAAAXQy1rGP2+1dHjz4oPAABwMdSy hqqa8mzHAQAALoZa1nC2GpRaFgAAwEQtazhbDUotCwAAYKKWNZytBqWWBQAAMFHLGryf21r1 81+fFR8AAOBiqGUN3s8BqPq9XM+KDwAAcDHUsjbv57MO/VzY0TgPiA8AAHAl1LIFjv6aPt8z AAAAYKKWLXD01/T5ngEAAAATtWyNo7+mz/cMAAAAtKhlAQAAsCpqWQAAAKyKWhYAAACropYd 9n//9V/v/x3RUWmWzgEAAOBKqGVVv/v001/++Cf/8jd/+09/9uff/eij73700T/92Z9//K1v 3W63zz/77L3Nx9/61vtbH3/rW/eDt9vtk5//4qff+Oa240+/8c3f/PoTL/73vvLV733lq+/x //s//2vb7N//7eOPv/WtH/zFX373o4++95Wv/uAv/vLjb33rk5//4vD5AwAAnA+1rOR3n376 8be/816Jbv/757/669vt9vv3svXzz7e17O+/qGU/+fkv3kvP3X//8atf7eJ/7ytfbeNvS95f /vgn94J4+9/3v/Z1PqAFAAAviFpWsitkv/+1r7+Xpx/Ush9+Lvt+8PPPPtv2/Ze/+duffuOb P/3GN3/wF3+5LVI//vZ3/v5//M8/NPvSl/4Q/0tf2tay//5vH+9K2G3t+09/9ud8OgsAAF4N tWzfb379yfe/9vV71fjxt7/zyc9/8cnPf/HLH//kZz/80c35HoP3Wva///O/fvqNb7Yfsv7m 15989tvftvG/95Wv7uK/f4/B7z799B7nux999NNvfPP9m2V/+o1vfvdLX7oP+vjFAQAAeCJq 2b6f/fBH20I2aNnWsr//7LP7wfca9Gc//NH2uwve4//Dl7/8/omsEf/zz2+323/86lfbIL/7 9NP3N3/z60/+5W/+9v34D/7iLwtnDQAAcH7Usn3bbxLY/Q9b+5bW98u23xvw/a99/f0D3T/G /9KXvvvRR//w5S978bdB/v3fPt6+9csf/+S9+z/+yZ9OzxUAAGAl1LJ921p291MF9i2tWvbz zz7793/7+J//6q93Fe0vf/yTP8b/opb14lPLAgAAtKhl+7bfY7D9PLVl1rLvfv/ZZ+8/Tmv7 rQLv32i7/R4DL/4nP//FH7/PYfMDv7bfj/v9r329aMYAAABroJbt++Tnv7j/v1nf/9rXf/nj n/zm15/85teffPLzX7x/RBr8v1+3zz//3aef/u7TTz//4q/3D2j/5W/+9v1//4rjv39r7H// 53/dvy/2vaT+za8/+Y9f/erjb3/nD3XwRx/99BvffNIKAQAAPAe1rGT7eer7TyT457/66+9/ 7evdn8n12W9/+7Mf/uin3/jmx9/+zsff/o75uewfOn7x4wi+95WvbuPfv4P2//7rv25z+MFf /OX7z+16/+s//smf7r73AAAA4PKoZSXbHxewK2pv4e9K+Oy3v93VwfcfB7stPd/j//FHzFq/ K+H3H/6o2u1///gnfxp/8wMAAMAlUcuqfvPrTz7+9nd2v8Hr/cv6n1u17OfW70q4f3fB/X/8 auPfK9q//x//86ff+Ob2/wb7/LPPfvbDH23/N7J/+PKXzWgAAACvgFp22PsvKXj/L9Gl20tp mcgBAADgeqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACr opYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACr opYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACr opYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACr opYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsKqr17IfffTBf/G7ekvv 3figMtbuYJDhvZkZKshWDHvQvLpL7Y2rp6300iPnVmxmRxWOpa9SsG7iWyWjz2yPOJo4ojjW g88FAMB36Ztp9+EhVh56g/jg0AOv28VsFqekZBKHnZ/XTLEipi32EiPnVmxmRxWONbRQ4lnY hQ3aJ0ZX2qfjiDuqO9bQKZtZDQCA4Lp30uDB77VRQulxhh72Skp6bTH0pBwdsXxewVyC9ukJ 6iVLYuiqHVU1ljL3uKPZXrwKEqNXnSxx6MSlfXRKAIBB172TVhVYXq+4TTqBdO1iPpUVoyOW z8sbNG6fCFiSXty4akcdPVZ3pvFZMN8tWWel4MvtDT290XyUlMQEAADjrnsb3T1uC6sBsU15 zac/wocekKMjls/LCx530adZmF63cdWOOm6s0V7xHohbJkY3a8fupJQGBy1FLpTeCwDQc+nb aPvE7T6SlUdgMFB8cHI4/RE+9IBURozTHppXnKRYOnTfjVvmpqAMXbWjjhtrdD+LZ1Mca3QP T14I8cGhpRD3bfm5AAD0XP02Gj9gqiqP0UeX8lAUR0m0SYyYWEYxlNem/Wt6pkM1VreQioeu 2lHHjdUdXTkLXgN9nZXR0wtYtRRiPum0h3YCAMDxMrdR8VkbdNwe6bbxOm6PjD6nc9l2jY5Y Pi898mhAPezQupWfo9GybHKs0UIwPhIUcA8YXQyiR07ko6SUmwgAQHDd22hVBZOOU17z5bLt Gh2xfF5tm6A8GgooJjwULW5cXtM8cqxdg+AseGd8fp0PCpKOnA6VmxoAYNx1b6PtwzX9LNk2 i5/Z5tM9GK6qrBmdkdjl6JrADNstpMSAXktxUnrARJzujqoaS5m72T4+C8olkBg9jnzExLsn In0JpFMCAAy69J20WxKJldNQaaXEGTqivDXURu9SOItEeZQ7Hsxifid0hy7cUSVj6ZOKh+ue rJLRxS5VbbxmMwtSeC4AAJqr30kTTzKlpTJW9/lnHlRqF2W+utERg4d00CxeanFhczNN1zSJ E1G7o+bHGiqe9LMwujGU0eNJjbZpW4ojBrMOIpefCwCAjJspAAAAVkUtCwAAgFVRywIAAGBV 1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBV1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBV 1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBV1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBV 1LIAAABYFbUsAAAAVnXZWvatcdAo5QHbbA9K/lDzOT9g1t0hjts5o5m8lDOv+SN76TET8Y++ N44SM3lKtvqgVSciODvt0+HB5/E+0HyG70dGV8AcZcZJLgHMuHIt2z1yxChV0S5zdQ1N5KAV OE/98cj4T3eGUy+OeHR3s/F8MZrufq8hRgc9SJzJ02+MenqTkc3z0lZ4cfejtUmmM2xL1e4K xAdzznMhII1atniUwlDXuMDOUNBQyz7FGU69OOLR3ctr2ZI6+Dw78GVrWTOUV8l1z9oDFmeX jHlQrGWD6VDLYtSL1rLmFy9GD5qjeL3u7YMuylwmM8/18qaze71dk+1849ufN4q5YrtlV7IN 1iEYqxvEm+y2vZ7VLrI3VnA2g7EefDCYhdjYm28cIX6dW9W4lzg7c6xte2X67VJ4r7vr9vYh vaM5KSUH74zskomzFRenben10me9i2nmr69Dd0nbfIK/Km8NTbNd/O4QQZvuW6MBg2y9eXkH q0J1Tyse4Mq17M72rfZ14qC3d71eZlizl/fWZOZKkpMHzVWKBw2yitc8l605XJy5MtnEIkwu rOegMyse7GYiNtY3kjLW/CU5v7GHIuhbtxswOPj0e0juSpm/QtP5H30ht9u1+9d72JKt0k01 vvS67b1rs53C24Y3r5kTVBiqe1rxAFeuZbtHbs4eNbsccYvvpjeaZJxDrtfkHM172dBttztE N8nucFUPsHRWk/diT9XOGd2xQaihcb0cggjtn5MBvYPzs5vfQpNDz++69nIu3NX6QuWWN3Gm JkePpxzfM4OO8VuFGzLIuRvcC/X29ta2V6Y8f/+PQz3g/oxCL1rLvm20B81muUfg5IMzyDyR Q9tmdL5xfOX2Z96quml7Q8TnsXsvEzMfOqHBa2Uj5TZPO6/Rk2j2jTeed9CMn96x2ymYie1a tn96fZVVNdfB7K7kFkfovi5sLK7P7qC3Gsq5G5q+eKbS8duxxPiTowcnS3yr/Wv3rcINKWai zCWOqQyk75/tQT1h8aKI54uHecVatrvzvMtstHtu0NE0cknmQsXx9dvf6E0wt4zxvPTMc/f9 XITcrM1JeRHiUEPx9YO5E3cTTuKuZfvn6IhBcC/m/EmpXStx6MT2MNs8a//PX6GjoY6eSOKv 3bfmH1LxzVwM7oVSHhDzU5gMleiOB3vpWvbt7e2IwiJdjhz9SMglWXgwyCdOO3G39U6uOVzV Ayyd1eTZ9Cb1sDM7dIvPNS65gubzH9oAuQTirRuMNXruSnbdZA7ewe7uTec/mVVJHO+geURZ YS/UfHr31907j57hUANv6Pn9I4bKHcSDXbmW3WnfvVmPELOld9DbuO27+oPBHG4mydGx0ovg XefBdMyU4mhiYnEOQVjvoHhCg9dBVvNj7ea1G8sMe9DBNo3RxvEaxvvHfG32fdsIAnrnYnR2 cYR2+sG43hy9NLxZdPPvrk8iB/Es38KFmow/OmuzS3DuxDi7aMo0b82Cmy27MxLT26UaZ6Jn KE7BW4Futm3C3VDiEpkHg5XHw1y2lsVpcbVXYSUvaa3Tula2AC6JWhaPxsOvCit5SWud1rWy BXBJ1LJ4nOCrPADerXKNcDkDOAlqWQAAAKyKWhYAAACropYFAADAqi5by5rfyJX47q7cN4RV jT4fQflBKuKPVvHadH94yqTJsDPdvR8iczRzMYMj3bPQ/liZumTxgbXW9szZvllu01e0+VOW ZnMNxzrbvbHqjvqs26Pp6KVuh3vAKNBRy2biPGz0Xa/5/M2HQbqW1cviEunpp7N6yg0rOEfK waG+3ujn9IDcJi+3dK9nWSLbqtJz/uTmxnrAiEPB48b6bf88m+dh/zg5IixKUMtm4jxs9Fv1 w7Uta4KY1LJPrGVv8omjlj1oCGrZkyipVJ5+szrPvfFitWzh0zYxEE7i4rXs7isOu9ft1yPa g4nut/DqEuObo5gRvGSCIbySyMxNjGy+m17hbZ7bNMzbaJBGUMYpk/WGExdKXIE2N+91N7cg prm72iPt1LrZeqthRkjvvW4m4kkJem3/Ki6FN277ejLbYAglgXgPzJ/BoH13yuZ82yTjnL1x vSDeW2LyM8PpAbuncrsU3RMUhArOXZCVN2J7ZoOzf9BSB3PspmQ2iBd5ZnYoceVaNrjk4itT 7+K19K4uPaw31nwE8Yg3nDmp9t3ECneH7p4CJYcguLJhJrNNnKzt63hGQwFzCbSNxZUMppBb 0m7O3d07dIIS+/lZ2Xbj78LOn8Huu0MpmUkqOXvtg4NinuLBNqw5x8JTObRvq0KJL6pmkTuz uYGqdkJui2LGlWvZ9rW+KXfvtjfTuHv3koufAXovZVxziN2RdORtg6FU9ZZe93jdgvwTI3Zv l91s4zS8g90T13ZX9moiw8lz1zaYfGx40rtX75W4Y5jdc+NO7uSZZMwzGJxNfZRY+e3Xe0vv uPS9MXfbD+6Kk9dy7T2zdvT5UIkNjwRq2f6FZNYHW0HMbkr310MPm13abTJmkGDQ3IyCbLsB u5OKD5qT2r3bSo+4e3c0oJeV2SCeYzzrNgdvEYIMu6/jBt5a7RroWyVe0jaImPxor7hx2yxI NZ5akG3QMrd0Q8mYZ9DMqt1p4up1kwxSaocIggQB2+S7XfpzONm9UY8fpBq8GJpvdxESZ3Yy pV0bMef44DZmmzAmUcv2L6SgS3dEpYF43xlK2wwSDDo/IyUrfRRlpvq6jQZP3Ky72QYHgwbd E2fGDHKY3KVKY7FXYu8NXSO1yU/eMeazvTXrNhSqJJldg/ZPL3juWvBa5m6D6ZvVhe+NkxdO 4vZoRq69Z9amNBQqd/NBCWrZ4WpmqHs3paB91bjeW7UzUvoWHgyy6h5/e3szz69yj47b5+YV Z9494jUYepKZ0ZRsE1eK8lp/At1GTkq6V+K8K5tz8iouXDolmceczTjJ0Zy7HYfyvMC9MRff bPCY2+PomW27iPeoyeu9ZCJIu3Ite7c92DYwe3ldxO7e3c17N77vKHcZb9BgCGXu3chvH4oD dg927wVtR3Gy2+P3P9tRvLPfLkvwrjhZMXPxSLyGZnezgbcHglDeogURum3EDdCm3T0p3V7e cG1jPXNz3NFe5lvxHlM2Q5xMMMRo+9yUzfje62CH6HNRkleGe/tQLmB8KrcHg0m1iemhghPn xXmbuExyS32zFmobXIlpNrg5K1M4O5S4bC27FjZ3Tm7dzF7nOQWPyaRklPMs2otgwSF6+lZ5 egLvTpIGjkYtewpcbznUss8d5TyL9iJYcIieslWCjzmf5SRp4GjUsk/GVxxyZtbt5LXs7fhk quKfatGujRsFRM/dKmf7Mvp5MsGhqGUBAACwKmpZAAAArIpaFgAAAKu6eC2r/DiMtw+ZfXfN vDbBceVIfNxL+FnfDzQ/7uNnMTnQEd9oW/i/r8Utn/59YyUb5ughyhWmNBrqkd8Xvsp3eJ/Z K8xR9IB7BS7myrWsV3TGxaj57G/r2iCC1z4IohxXcp70yFrhuFnoI472OjTDExYZtU+URP2d brCKoYmkZ/2APXzOi3ctrzDHUekL5AH/huR8ncpL1LJiweq9FVerykZva9ngMqCWPQi17CP7 thGoZVvUsk8Pfh4vMs0h1LIQXbaWnS8cxVpWb2B2ab/Cfm+sX0K77kpAr0EQqv3r6KDxLHbv tn2DUYJeylzaUMGU45UMphyPGy9+GydIaXtEPF/mZJWUhtY8SDUYdzfrboNunNHpzBwMUhpa 4V0oM/jutblc3llo++7yVKYZ56N09FZAGVpZjfLcPGKe2yNm5LhX7cH5BuJBb/3bP7cdvQjm KMGuiE9oG8dcB3NS8YrhUK9ey97CzRp078YPLqHgyO3Dy68bOUg1DhjcTUYb5GZxE1Y+PUq8 bt1QQTLBSia2hNK9O5c4pZlTn9sPZp7pZMxoQw0S5+KIg5MrrF8p99feKN3bS3r/iPl488rt NzHJg3IzJfI0z68+u/mD3fyVCU4eFGcqZhUvci7bYLg4NxyNWvaDLvpWVuJ7d8n5G81OnFXh RVt4u2xnFLcfGiWOUHvD6kaYySrXqyrPoa0Vhwpe62HnGyR65Xaj2D138bah2j+HRvESTpyy IJ+4o/d6MmHvSEluivm7fSKU3l3Pf+jgZFZe9+CseRG6Q3STTA+HR6KWdTsmrkazTXB7ffuQ GDlooAcUbxwlocT1n7/9tQl348/fsMwczFBmg6PnIu7n3aB6SvGUu6vXHdeMJg4nnotur+Cs dbPSZ2qusDfo7mD7p5eYGLD72sszyGd+BW7yufBGr80tIJ7K3Ononpdu2t2JdCcrjjU5qfbs ezG9CMEQ8crEU1CGwyO9aC0bbNP2Lf1qNNu0LScjm5f3aMDRW2RVqOBg1e3PM3TTjMcdylZM 5qC5zOznXErdsEP5m9GUk5VLTDyY2Anzl0nQoP1TGeWIU6bko+QWH9Rn5x0pyc1z0H0y0av2 so0jTF59yjXVnlMl7cLVHhoOj/QStextZNsp+z7+a/xW7fUmBhQfb3r3XKhgFunczICTVYWX p/IUVxIY6j45l9FT3z3dSs7diejjmtGGGnQXsGrjicteu8IzQQ46Zbk7kvl6l+FQNHOChbkF JnfXLtToJZw72M3fbHB0VvEZVLLqDmE2GLodBa/xMK9Sy96+2J3B8d277W0xiDCURpxVMJAS 05tIG7AdyMzkJlzh8eoFE/EmKx5UenkpxaF2LYNJxWHNaF4cPVSc0s05uXHw+HTHvdKrp4xr zjpu0E3MHHdojuLBoZnGMYNFjl8rZ0GP5k2k26vb8dasQJuht8Lm+sRHJnPzhlCimSc9OB3p 7Td0MM7fbDCfQLw++oLvGnvRxMTiHMzj3SXFoS5by97CTb/cKDPOnyEA5MTFzRNHXyL+clgQ mKhl1xhlxvkzBIAcatmXwoLAdOVa9saN5na7LZIkACQoX/9d1zVmUeIy5xRHuHgtCwAAgAuj lgUAAMCqqGUBAACwKmpZGPi2pCOwqgAAlKOWXcDjfyDDolXXQWlXhV10VQEAODNq2QVQy4qo ZQEAeDWXrWW9yqz95RzBLwgJftpL9zeI3CN4vz6kbWAmY0b2QinZmo13zczcvLl3G8Q56GPt Mm9z7i7ULr4y7vav8ZkSZ9p2BwAAaa9Vyw4d9ErDRIS2TAwOivFnslUai7kpw8U5DK3D5ELt sh1d/zi+njOFLAAAVS5by956H4bpVVEbMzg4VIDOHBzNNtdYSUM/WLg45hCjtWxi3O2m2m2w ob4AAKAEtex6teyWnm1JLdsO7UXQc0iflHgdhrKN51hYy3rJAACAHGrZ9WpZMSslWrex0lHP 7YjFURp0s43nWFjLirkBAADRlWvZm/VJXvt6vuBLF15t4/kabijbbmMljUSv9tPKRK+g+3HZ iqNQywIA8BivVcvenK/zvm14HcUI5tBBQSMm0xZ/3VpttLFYFLYJx8N1c+iug5f5/V19oXbd xTmKZ1ac6e51sJgAAKDr5WrZ8zhzbo/EOgAAgDRq2ac5c26PxDoAAIC0y9ay8ZfCz+Dk6T0M 6wAAANIuW8sCAADg8qhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyK WhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyKWhYAAACropYFAADAqqhlAQAAsCpqWQAAAKyK WhYAAACrumwt+/b2tlDYx3t7ezv/XM6T4bMyKRn3AcnH22kogfOc9K2ZrN6+UBXwPB6ztY4e 4okmZ3f04pjxtwcTzxGv/dGPpGtvJFDLPiLsqZKZ6fiylq5ljx6iG2HR/bZ7Zj8xSLmqTJbY n8d5+uPgKbVs++78P1Yf8Ig880bCPGrZR4Q9VTIzHV8WtexMhEX32/yDsO11kqWgli3x9McB taw+1pk3EuZdv5Z9f9H9Guiuwb3XtsGtuTbiXkGz0Xzag0pYJR+x11DmN2v9vdF343q9btZJ NM9LGyQexWzprYlycoN8hsKacbz8gzSCTSKejmAWwZYwZ9EdMWg8ejBu4C1+kOfouHE+iRkp w3V7bf/qnfHg/G47et3F9JQJluRpNohz60YwRxxa/HYuXgKTZ1xZAT2B7cEtZfTdlNv28Zqb KXmTMpc6sSxYwkvUsuaNo23Z7eWFUi6q7utuPuLBoXxKZhFHiBctnkL3dHQTDnoNJZwLtUum O64SSlzDoYTjJJVZBC1HN0Ai23Ta4hS8xkPjem/VTnP0pIsX4K23bsFMvfSGUq3K00tVv+q7 CYszEg92t+jkZd7NP4ifWIdtQHN0Zc0feQljFS9Ry7YHzZZKL/1+0R1CySeONpSkHkF8LMUH R5Ns/xzKczKfg55JnpJ5dR8JuYSD4GKEXALxSU8kkEum2ysdwXtL73joho8vQKVvV+42qNwo 4o5Dww1FyN2B5+9LcSizwdA1IqY6v1B6y8LTOpQYVkEtm79JbQXxlWhe493xYLhcPvr918vB y3z03mQ+oo640Rc+tIbW/Gat3sy8vLM/mXAbvH03SLjb0ksgPunmTM0VyKWtT6E7HS9CHLyd jp5PIsm2ZftnEDDIPNBdz1225rhmnnFHbxG6uSkbIB5icqyZLWpuqvhkxfvQOyPB0ImJjK65 GDaIFm8MrIJatuAuFsdXonWDzN/pzOP61EaHG13J9s+hPA96ZiQWamj1ZuaVCKIkvAs+Oot0 y/ike9mKDQr3TzfDOBlxdkP5JJJsW8YX4NBBz+RVVpLnUG65hL2wiVC1t9z4oNlAOSPpPPUR hxoo4w7tWyyBWvbw4kaJpufz9vaWS9IcIt2rez8auvXMP+QOemYUPtT1xVGewV7HkoSD+7s+ 5fRzaHIKBz3ya89UN8jR09x1rz0vHj1y+gYy2nF70ExDTHiowcPOuLIaM/nPL5TeMn1aJxPD Kqhl/3B8e9m3Ld829F67lkHHbj7bIOatajSfRC8zh24DbyWDfNrXQYMgn7jXNg0lgeCkpFdP zzCYWi5y21eZghchbhknMJTt0EE9bW//JNZTGVoJkphm+qQHS6Gvm7KeYqrbg0N5eh3NibS5 BTM1I5h/HerVPU1eMnGDdjW89Lqptq/NF/o6xBMp2X677t2O8bJgCZetZfFcD741cCcqxGJi 0nJbaLmEAWxRy6JM91/JSw/3OlhMTFpuCyec9ekAACAASURBVC2XMIAtallUevDXa/jyUC0W E6+JbQ8sjVoWAAAAq6KWBQAAwKqoZQEAALAqatkPJL5rqvYbrZ7ybVsHDbrKt6AN5Xm9tYp/ Vo4epDClB9j+0KJ08ivO+tkpPM5LTdY0eUWbP1drOqnnyz3lzRvF24faId4a3vFrrO0TUct+ oHw/jQY84YZOl3pHz6Uq/rq17Hwy93pucvSn79vcSXz6v10fMHRhwk8/y10nz/AB6ZVclae6 tO+ecsO/+athlrbeC6/XeZZ3ddSyH6CWbVHLHjFoSVhq2VwC1LKPTOCRTp7hErVst/x6lpPc 8JU6lVr28a5cy3qf/Lef59+P7Lag19K8X7Rd9K8dtAl43UcnZbZsR9enEExq95aeWJtMt9f2 r+bp2M0rWAqve5BekGc8092I4nk3T9zQqTEbvH1oZvSqcy1G6OaszzoOErdpV0ZPqZ3sLppy XnIJBwHbrOL2wRzFDM1xlcS8Bu1kvXndjwSnSclfPFiygEPnKJ54MOsgnziIfrA7o2D12gXZ vQ7WLejenXLirbZNO804AYguW8sGW7w9aL4btFS6t126qZoRlAT0VL074Ggob2rtzU6Mlugl ZphbNE/3ZAWZBONOnrjgdTef9q+50efP9eh59w4GSXZfJA6KW26XVW4biPNKH0xs6aHGyrji ykzOK3dxHXHwNriAQ+cod1W2B5UgQ1NOJCkuY2IPBOI2b1/wegVv6TlA8XK17HEHu13Ok6qX wEH3XyVaopd3F9vd0Yb6dh0xkaFsu0Mk8jlo9IN2y9ADWLxmcwMNLaOeVUmDRKj58+U1TiST y7ZwsmbaB800HnQoQu1V6b01uQ7dBie84XebeePu5OKj68q1bLuBDr0n6k+XNlWzo5m/Pqm4 pZnA0L0vfScNLuz0dN7mbm1eMkF6uaXIrU/3xE3mc9DouXPdpme+3sUMkgxmlJh4ehnFIHqD +YTFBOJQSuNEMrlsCyd7+3CR24NmS7Ovd4KCHZJOW1lMfXPGwdsp6/kkkmxbtn8GAYPMA2Iz b7jcZYKEK9ey8cHye2K3i5Jq3DE3qbi716t7NabvpGYOiV6FtzYxt26EoYkUnrjJfA4aPXeu vQhxbkqSQa+Sy61wk0+uRm6s+au7MJlctg+YrHgwfSnFCTz4Dqz0Hb1LKw1OeMNXundvLEEX THqJWja3y+N9OfruqVL1Esg9abpzUaIlegW3ifmno+eIiaQTmz81o4+BodEP2i3zSSaul6HL QZm4mMN8g/mpdedVeCEX3uL0+3acvzl6YSa36QXs9hqKkA5SmLByjQ9dfUM3DSVDs3u8S+Mu mHTZWvb2xT1I3PG7xm9fPOPbvejF7N6Fb/7GbRMwxwoSGEq1HX1oCu1Yu3eDaEoEsZd4cr2+ 8evcWrWN41Mgnndltc2OYj7zo5ef6zhCdzN0G5cMpJxZL6U259E5ziccJGBmriQQJzM07i7t INS2ZTvZIP49cpC/2Us53bkz2I1gvjaHiCcejBvMqNtAPNidkbJ65muv79DrNklzCm8fakOZ XYK/Iu3KteyMg3bYEWG5GIC1cM0OOXq5OB24sQ0WRy1ro5YFcBCu2SFH3zY5HbixDRZHLWtb aFsvlCqAG9fsoOM+Weh+qR3AEqhlAQAAsCpqWQAAAKyKWhYAAACropb9wOhP5Tjuf0p4s+jZ DuVWOIvgZ5E8YPQjhnjweT8DZadtT3SwRc2+VVnNtzyacjm84Aa7Wfe3bvvHpNQe0ZM8ifsT 5P7X0aXW2ytr0gbcZXiEc97EcBxq2Q94W3Z7/Oht/YCn2u2wGSkP7yCTmRGD4+khnnjeH0O5 cZsPHu9pJDarSlV891m6l8N5NtgD7jPx8ZkE5pMXK5hzbrOtdsuNzmK+vdjykbXsSW5iOA61 7AfOcEejls2NGBzPDfHc8/4Y+uqZ60ktG4svh1NtMGpZ5eA5t9kWtawZ/yQ3MRznyrVs+yWD +6ZsN2uwX4NNvAvuRVYOesOlR99dq9t3d43NqzpYCi9OEGp0zePgu0mZN6N2gpMnwnur/LyL i6wc7Hb38jHbe6kG4lPsZRik7eXWnu44TnAiynvdnBV4+gbbHmkz91bAjGD2CvJpDyqjp5Nv x1LyDI5s18GLIB4UF1OZWrBiQTNvqcX2ZpduereKiY+uhrg+ZhxzWYa2WRuqGwG6y9ay3q5t d7D5rhfKe6t7kcQHg+HmR49nPZqbPuhobubUhnIOIoiJeRG8t44478oiT57l0dUL8g9ux90p BxkGByfXvDv92l5iF++th22w4PyavRLnxUxmdHa55L2hR0/Q0EWqH5zZ5ImpjZ6y3DrH6d2m J55YjSD/bTJxkPToN2fKXgQMuWwtu1V4SSiR9WhKr/kH3tCs22teST4Y9KCb8tDDcq3znsu8 8BmwfWtobwRbVzlNcceHTX9m0ZSclTiP32Dp6yV9ee6IwQvPTjfP0SSVgGLyk6d4F2p0qZX2 3riBXbOjV+N+vG0Zb0tlFHHKu8Yl0WC6ci3bXo25+2Cwz3Z9lSt/dDhl9MK7f/dSj1+bL8QT 0R1Iv82JqZr36zgxM2DtedcXufCgl4++N9pRWl6XYAFn9nNu+ulFC/b5+TeYOaI5lyBC3MvL VpmInvzNWjE9fi5Jc5MHR7oL6+VjDpSYWq69OaluF6+ZvovMcburcQ/bDtSdozlEN6U2Tnyu u/lDd9latnuVxge9UEHf0XfF4ZQ7UTyvoVnHl3rcqzt6N44YvBt/KFXPs877UOZVB7184r0x tET6glft5/nrvarXqW4shRMcyko53g2evgmI8WeS7DY+Lp/RULn23b56l/ToQ3k+5iZWeBtB 2vVr2be3t/lH+9HlhTdWkJI+0GgaiTt4MOjR9UTtKSsJMjnl9KBVix+8290q7aNCD1i+n4/e e2av7onojnX0vIa6z2/LNpPgeDdOLjc9/kySuTwfuXWPaB938boro5fcxw66iU3eEPT8Ibps LXvb7CFlJ93F0eKr0WwgHjRjtn/VR+/eCLybl35f0AcNFiFYB6WXF0G8g8QnPUhDzLN7sI2p L3LbSxm0Td7Mp83EO2KeFDGgmaGYtrcN4rPjvR4aPeh1s05lvMjm9LsNxINtTG//5Nat28s7 6WaS3dFzyevxxSTTp2NoYdOn+OasmNlFWYpuVmLfbrbBEKOr4aVkHtmK57Lbdd1tdvPXR8kf oivXspd30DXApbUizhqAx98HuPPgDKhlF0YtizvOGgBqWbwmatklHfSFCb7esS5OHIDbY28F 3HZwEtSyAAAAWBW1LAAAAFZFLQsAAIBVUcu6HvPzMubjmxESYV/qO58eM9lDRxF/1ozYt21g /pyaWt7WfcDQXSUX5uNnYY7lHQmWOj4L5lujc3z8ma0d8Xo3zKfM6HrLiKeglrU98tkzOfoL 1rKFqT643Dwu+L06URJQatnRLgni1q0aOjHrwrEecH0Fe0A5uD1S9VY326PtCvREr/loCFxv GXMzut46PBi1rI1a9syoZdv4bXUSjE4tm2swM9bDatmbvDGoZZVe89EQuN4yUss+xZVr2fir Y9sj9+Ntm13L3cHgCWFGC0LFGbYRgvzNtMV1aF/HvR55MMg8WJ9gsmKoOJngtXlqhkaJp+aN uHs3nn43sjnW/KTMURJDm3NJnOv2r6ODxrPYvaus1W6VRjeDGWQX0Asy9JaXxu64uIbxiTDz 8ZbFDKWMaAbMRQumoPQSz77XQFz2dqxgat4s2l5D+eyO7F4fsT7xXHKLabZJ9MKoy9ay3vVg HmwbxC8SAbuhusnfwquum7Z+0LuiEqEKD3YzGWrcHUtMJu4en5rcwXh05YiX2C7yTjzl3Dbr TkoMOLPI6Vko14s5x/lREhdFEL97ls2Y+ukbmp2YeffdIO3uiF6okmiT6zMaIQgbLGY8teDU j57cdug4sW6St+wKK43FHOK5KL2Q8BK1rHlQvPskblLKVk7kmZuUfqdu7xoBJdRQnt3u3VC5 ZIZOVpBM+6cSUF8HLw3lsSTm4A2tNJu83Ha9dhIBh05l4TXuxZ+8ipURdwe7G8OMs3vcmmch mJqYWzCj4GD3EvMy7L6O0xiKFjfoZquHChIbzbB9a/6mkVjq4CzHHdO5KWdZj6AnNpQMRNSy nYPzz7n2eXDQTSGXdptq+5Y5HTEls6+5RHoyQ+tjRtNPlphM+6eXW5C8N644unnEDNJdtPag l9ho/kNDe7uiG7B70JxFLpR3arx56bMe2gzt7Mywcea5CSqNze0hjrvN3JyFtyZBbvF+Tkfz TlObdhs53o3x2b85K9wNe7MWXz81uwSU114+4lnOrU93Rl5jPYKe2FAyEFHLdg4mLu/0Nd9t kJiUftkMXeFiqO7BXK+h9TE76idLTMa8BU9uD+XuZt70u0GGNlVt/qNDT+5/JfOjr/GgbyIf j7luwcYYSlLsNZTn6Gqbl5iXRje3XGExFK3tmL61DhU6oztt5mHXnYUetvxG2s1NOR0zM0qH QsJL1LIzzyrzxRGPzG7yQ41LpuwNlFuBo+8FQ40LT5aYzxHr4L1VuwO9voXbIBhamcvktn/A LNK5mQFHR/SOiEl2R5+8BrsHE6/1xt2dkIvWBlEu4e5u9OLkVjjXcZtkN1Q3wujN86D1GWo8 uYeHkoHosrXs7Yt93166u4Pdq27X1zwY3AfjNLwLzxwinmYwqfQ6eIkl4s8fbNNQGpsNticr N5ddg9HXJevQRjaPmNNXVthrdj8yOSlz9Hg63qlURjEX4eZsBmVQL+E2gaFl8SJ3T9nokf05 DidlLog5Cy89cQ27YUeXxTunbRtzJ+SiKafDjGzGD8LGDZRN1b7WF6obqhtB6dXtaM60TS9e im60OIK3eXK9MOrKtexx2HPASXAx3j19KZ6ewJldaXGuNBdcA7WsSvz3HIBH4mK8e/pSPD2B M1t9cXgC4syoZQd0v4oB4MG4HreeuBqcCM9lnho8AXFa1LIAAABYFbUsAAAAVkUtCwAAgFW9 bi1b/k0/kwGP+yak4DucrvGdT90fxTIZuf3JLOmAyGHNAQCe16plz/x/Yh6UTxy2+2MCz687 hfR0zrxbyj1l+z0+DgDgeqhlz4JaNuegWrbttdayjKKWBQAs6sq17O4LxO1f7weDXl5Ls0EQ xDsYjxLnY/bypmwmb1Zs7XDdtM3Xo3PpjtU2UEbRF9abVzxlMfLo1LyDb+HZV3q1Dcz23cVR Vv7+1zaZ3Wtlpm13AAAuW8t6z8vtwfZ48JT13r1ZhUJ3aDPh0Xzi12IoM5Pu67jB0MGhJcpN QVwNL4L31uTcg4Tjg+IZD3rpGc7vVSW+njOFLABg56VrWbGB9+j1StihAjHRQCk7zlPL6i27 ZUrhFMprWT3aZK/5PWwOUXvS09eO0hcAgC1q2X2DLa+l8jzeRvAidxPedRRnYWb1yFr2Jq/A LmawPrVTGDodcfB2mno+iV76GfcO3j6cfjCpob3aPb9vc7VssDEAAK+MWtZtELTsPo/FyLmE u7MwGxcWgkrjxFjd44VTGDodQyOev5YdamA69NpJ7FgAwCujlu032D0+a4sJMVT8WZcYoTs1 Pb44aO5geix9CkrpVniij1vGxIlOb6rJbMVRqGUBAEMuW8vevnhUd5/97eu21y6s8noXxDso hrr1nvHeazOrbiHYnYs5r8QKDC2REqGdwtA56g6nBEmcfb1X+zq9zrcP94m+OPqSdpMfmunu dXzuAAAv4sq1LHBtFHMAAFDLAquilgUAgFoWWBW1LAAA1LIAAABYFbUsAAAAVkUtCwAAgFVR ywIAAGBV1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBV1LIAAABYFbUsAAAAVkUtCwAAgFVR ywIAAGBV1LIAAABYFbUsAAAAVkUtCwAAgFVRywIAAGBVl61l397etq+3fz1uILHlg5M5brin O+fUElsi132my4N7YUhuYygNVjx98WoUzmjFxUl7/AI+8kw9bKu/1J45s+vXskdvtcnCpTYB rqtnyZ0FalnEhvbVwyqJM6iazsveP4+Y7El24Hke+ngYatmygQpbphPgGnsWalkcgVrWQy07 iVr2tPGRcPFa9u0L5rvm61377p1uO9DuuBcqGNFr733FxOweTyH44os+l20zMX53VYNR4oRz mbc5tH+KEbyT6E25HXfofHn5D3X3UjoivaGDykyHzulQfKVByQTj07dN/v5ud0ZByzbUoSeu nY43R2+aZsttqLa9tz5tF28icYRgvuIq7U5usAjdCJMtb0ULGDQQUwpeB4MGObfnVDkLu/bt 7IL4o1PGES5ey956V4LXMj64C+XdFLyDQTPlSDyXoeFK5iLGj+9f6cVPZx50z0XI5T96vsSt pbTs3l7L01NS7eavZ5K4CSgJzBzsjr67HLpXtxnzuSdul9LoTUNZDT1sd8N3V7h2n4iLIEZI tzxiAZUZje7G3KDpszCa3uhY7URQ5UVr2ftx7z510I1MbzaZQHc4kz7WzFq1fyqjxAl38zET 62Y+GfYWTrMbf3T03Vu5czSZntl9aMUS+dfONNFrZoLm5TC0M+N85veV0tKTu9yGVqPkplQV IRfqiNtX4mDhAh598R4xo6pBhyaCKtSylTeyba8tL2bQLG7TTSCYghcnDuXNJZFq+6c3ip5w d+LxHJWJJ8Ka09STGZpUu0rd5L2s9PTiUxafR3G3BNOPM1FmqifQ7ZWeYPtnd75ebt1V6sZU puAti0k/iW0DMXPxXS9zJZnEPhmduL6pxLCJg4UL2N05VYMWzkg5O+UTQRVq2cxtwhyoO2h8 pXmJdS+AoSmYLfXu+sEg1fbPYBbiwdzEh+5u+sH2dbwJvWRmttZonpPp6fEnN/bkiU43SPQq uRxyOzOxr/QpDD2Sc5fb0GpMFhO5+6cXQQ+VuxILb9GHLuARzxczVOGMDl1bbyKo8rq1bPvW QVdycIENXVRDCQwNtz0YZyse9OKL2Zbf0XIHSyJ4mSuhqp5GYp5meqO7Vz+P6Str8okVx1QS qJpg0GZoZ4q9jr5YTPr5Ul7PzGvoLCvZzqSaHndy/z9sAQtTesxWH8rkoIsFM6hl90fai+dt wwwS94pT8vp2s9q9a0YWh9t18eZihhqK72WYDqjcnoZOjZeVEsFMpv2rGeeg/OPuway3B3Pp 5SbSJmCOPnlO41S7GdZOMH697S6eryBUItuhg15KwalRopmZt/OKuwQZihHi86isUmIRzAgz Y5UvoBnTSyme5tBZC3LupjH6epeJuXpDY6HcZWtZBXtrJ7cgLGNsifWJHxjnccKU8O78W+hU yeQ8dwpPGf0CZw0PQC2LP9IXhH9u6pZYn/MXIu8eltLbAR6T+bOccwtd7E71+Ck8ZQEvdtbw AC9ay77CoyVhaE1e5Ak9Y/X1OWHyJ0wJgTOcryvdqZ71yejjF/BKZw0P8KK1LAAAAC6AWhYA AACropYFAADAqi5by+rfZ3OG78g5Qw7vHpPJfZT2RbfLAxw3Vi5ybT6FOSRCPXern+dCUzxx eXf/8838dy4WrnzwP9WtdX5jhaeyPX1HLJRyD3/8N90+cjg8EbXsKbb7GXJ49+DHZ1Ute54F jOW25fzs5qNRy853f4DyDEuu7lptWP028nij/0NtomPQ8pGF/glv0UvfbTCEWvYUG+4MObyj lj0UtezST5fzbzNq2SNGnPHEWjZYqCOc8Ba99N0GQy5ey5pfWwm+LLV7N2gWD20O4SUTBNRD zSRgTk1fIjOZeOnaUeIVGM0hWAFzNeJFUNZtaOLdgO1fxTTatZqJ1s7LWyivu5dh+zp+NzjX 3cy3ae8WQZxFMBdlXH1Jy5dXXCsvzvb4aOT2r+Jw7ULttG3EUeYPdhOOFyEOa65YYohdkkH+ QYT0mpiZKzlXpbEd+rhpzpwXHOHKtezu0ro1O7v7rtn+NnKPUJLxdrweajIBL6vgXe9gnMat WVgxiDfr+GAQIXFqumOJE88ttd5LOR2jk+r2SuyWmW0zmnkwhVyomcbbg/o+FLOdvH6VHKoi 7w7GG2MruOgOTXI34sygQdjJIbxo3lu1a6Jk/oBTE6RREn/yvOAIV65l29fpu3/751AOuWtG DzXfK2g5dP9tj5tLFy++GXnygaE8USYfTruD8cQPmpHyVJt8Qpi99GS6F5F4xekPjCMek0pj r6MeTb86xIMzXRILXrjyu/g7iYCJO0+3QfrO022QuwS6V5mSxmQ+8/cKpeVQr9wtdDI+jvZy tWx7B1S2Y/fJuhvaG6I7XC5UupfScjdK8Pxo0zD/jF+0EdqW3bSHVsAcYjSB0YmPzijRq01p flJtL+XdXRxviG0vc/V2eYoxu7lNLoI3Uy9bPVo8RyWmuFZB8Phcx5MdWvl4Xt4cvbe8Uymu SW4n6CcxvSXMKQRnxDzuBYw76g3EjaSkoU82ztM7KO6HdPw4VRR6uVo2aBl0af9Mj9u9pBOh ChNoD3Yv6biBuXTxDU6fS9xSaZC47Yo303ji6RnpveajdSPMzGtm23SD65krKcWhhsYdipZY wKq1Kr9UJ2+G3czTSerdu6Fqpza/b9vjJVtrqLt4r8ilYTroej8iPgq9bi2rX2O5m9Hb29vk PU4PNZmA1zL+q3LF6rfmIx6QQw26WQ09nHLDzc8onY++r8xek5dbItuqzLsHhxIzG2+zHYpW sry5G5Hy4ojhbs5ibik754gkvRwmL+Ru2KEppAOmJzLa/WFpnCo+jnblWvbOPL49ErzbNjBf t0PchMvDSzIRaiYBr6U5hLmAQSbx6+5lby5RN4fuWU5k1d0nu7RHXwczGurl5TM5Ke9ExN31 E7Hr5bW5Rxs9HcEuGl2E0XHbWcTT9M5UYnnFtQrijCaz6yJ2705/N5B5PJdk3FLJoTs1fc8E KxZMIQgYzK7bIL0m3bM5OWKcxrbBodPsTipOErUuW8s+wCts01eYIwAAWBe1bN4r1HmvMEcA ALAualnY+PoIAAA4P2pZAAAArIpaFgAAAKuilgUAAMCqXreWNb8ZVP8O0TN8L2kih7ZLcOTt Q7UJHLeAcarPOnFPGfegQc+w+RPm037kxBdd5Mfr3qZGo5W3nHfE7evpMz3VDs8lc6opvDhq 2f7BRJzjIng/3C431pv1wy/Ng3ozMYFn1bKJviWoZRc1ecWVjMtYyg/7nImf6H7+RYvjPP0q PlX5+LBtg4NQy/YPJuIcF2H+ZtRGMGNSy9aill0UtewZxqKWLY/z9KuYWhaFrlzLml91uh/Z XdVxZdaGurdvj3uDejWWEsF8a5uDOFw7cfPITbg4lVrWW7d20HZewWv9zI6OG69bsAfMLl5W SijltMYb4CacxMKwM1NoX7dhvQhmYmbY3QvlvLc7RJxXHKcbKl4N8/XQhuk2G52OOEdxrHbZ gxPkJSmmtG15663qtk0cKn0wzmr3Il6ieBnbFzdnPdtBuzl7i2ZOSukVNMvlo0ytPRg08HLo ZogSl61lg/16a3Zne3AolNjy1lyZYoSg8cyN6ba5FIP4Qzl32ygJxwuin1kzmXihRucSd+y2 9Bro2cYL272BFoZNT8FMxgsbRChsuUsgTiZxxXVDDV13Qwf1sKPTiYfrLlfuwryP0jaYXHal +8wm19fZG6hq0MlMzJYl+Z9hr+o7px1dyRBVLlvLblVdyXpMr0Gc3mgyuencj7ctg/a7t0Yv UfEusDvY/hm3D/IR7z5Dt6TaO2ncywyb3gCmwssk0Xj0YZDIdnK1h8bqRjgoVKJlMG7ifugN p+cwdGHu2hyxW7oHuzkP7Ssx/9xzJ+41dGomt0G3wdn2qn46PEN3Y4y6ci37tnE/sn03OOiF 6nZvBzW774J3X+uNvRzaIPq9LB4iHsg7BcpJaf/0JmjOJR63bROsQG7n6CdI2QNiL2U6uyRL wuamcNucLy89s3si23gP7LLS56VESKet75N2VeNBh+boNY57dQ/u8hwd1BSfl6E8xe7t6+B0 mM0SS5o713H+3e0xtDf0RdPzV6K17duVF5PUewX7Mz7LqHLZWnZ+v8ZhJ7t3U003Vi6Y9s7l HTGHDt7qpiou4DafXW5Dy6Ik3323O5ehrOZP6xH7eT5sbgr316OPrpkpzC+RF60bIZG2koyY VUl9UHUWlAZDmY/G0fOMu3dD6enpqRaepvvr7iIXXoxegzi+Es1TeC+NT4eSLcpdv5Z9e3s7 4iGdu1Bz98ehxuLFEzwD4ga5h0qwbsr0j3iEDNUlR+wcJZSZ9uR+NjM86DLpTqGb5xEr8+Ar bn4bVIUafeIenUNu+3nJlKckHjQbHHRBJTIRB1WuwcK9MZRqd4j5fOZPd5xte9NDrcvWsrfN 7tntwrv4YBuqexc2W3oH2zxHGwdXWvfKad81j7Qro9xi2mzji99bNC94vMheJsq4uT3QZhhn pYcyc9M3gJ5hOuzkFOLczJbeqe9ma07Qi9kG784rnoV+xpV8ujuqO6g3x9x09DmaY7WNvWZB MumUbvKqKmdKnJF30JvaLgElVLyMbeMgjbZN93R4LRNL3XYPOnbzMXPwsopf77rHCQdJYt6V a1kAd2e+k1blduY5AmfGtYOlUcsCL+HMzypqWSS8XcvTF/O5CQAzqGUBPE3tU5znMTDqDJU0 MIlaFgAAAKuilgUAAMCqqGUBAACwKmrZ0znbty6dLZ8hXvJHf4tYInjbJTjS/b9G4gQSXfQ4 uV5vzY+5AQBAQS1bKaic5oM83WkTC1QVbaNjzdeFb/7PYe1WvV6zOL2T1LJHjAgAuDBq2UrU smezUC1rRjBjUssCAHB32Vp29zg3vxp7P2JWCbvXXvd4CPN48KXhbebd4dpU48i5Btt8ErNQ wm7blEy5PbNmzJIkg1S7M2qDtEObUza7B329BmZ8L09vfYa6e4l5Z7ld/O70AQAv5cq1bLcG Gm05dHCXTPd1nLlS5SiREw3iKQ/NAL0msgAAIABJREFU4uYve+GUzbDmNOeTNMPqM4ojBF2C qq47Sje9xIbv7o2hkyKmAQDA7dq1bPz6iLK1qpYVG+zKHaWI0Yf2hhtN0ns9c4IS5ys3o8dM uQ0SF7W79ru39FG89EY3vJJA4qQMXWIAgJf1KrXsltkgPth23x43Bw2SidsHjc0pdPPcBRcb tDl0lzSYhbj+wXD6lPUVzuXQDRtEU9bf7O61j4cQz473wju4fbcdQjwpXgNz55iZAwBwe51a VmygP8XNUHGBclBiiTyHGus14tBYuTpSmbI+dC6Hkhl5lFq2jRMMcXQtG3TpjihOofsuAOCV vVwtaz659ad4ruotrGWDj6mGyoWqEmdoFkPRRqeZqKueWMsGNVm3HvUaKNtPSS+x4Y84Kel/ DwAAXspL1LK3L6o38+CteWq2jYPubTMzmW40M3MzeFAWxJG9IN1JTc4iDhu/Npc9jnxzTqI5 o/kkd90TM/LSi4+0cxTPxc1ZH2Xl9fUpOSnmiN35AgBeymVr2SE8FAEAAFZELXu7UcsCAACs iVr2dqOWBQAAWBO1LAAAAFZFLQsAAIBVUcsCAABgVdSyAAAAWBW1LAAAAFZFLQsAAIBVUcsC AABgVdSyAAAAWBW1LAAAAFZFLQsAAIBVUcsCAABgVdSyAAAAWBW1LAAAAFZFLQsAAIBVUcsC AABgVdSyAAAAWNVla9m3DyntC4fuNigcbiaT546ldymZyCNXI+Hk6QEAcE5XrmWDv3bbH+fo gR5ZlD8s/ivUsgAAIOFValnziP5uofMUiI8MNRmfWhYAAJhetJZtv/fg/bV50OtujrI92Mbc jRukEXTfjRXHH51y3D747ohg1nECbZ67Lt2JeH3bmQ4lFkx2qJfYUlzA3dTigZQGMweDsQAA eIxXrGW9AqJtEBde3YoqjqmkMZNebsrmRILXo7M2D+rrHKcRJzyUWGJlJuMn3lXm3s155iAA AE9HLVv/UC8p4MTXj5lIbQIPyLn984hRamdRWEp2c4575WplAACe4kVr2a22/UK17GMmMtT4 6Fq2nXIbc6iWFdfQzLww/nwtq6yM2Cs44sUHAOApXrSWjdtXlYCFJctkepMTGWrcHasqZ1Oi lg0SG2owGf+gk1XVi/oVAHBOr1LLHlEXdj8Ae1gtu83k/LXszFJ00xDTPmJlzLNQvhrKrssV 0PMrDwDA4125lt3y3jXbe3F2B28VVV0befT1LpOgKBHHaoN7EXaNlVS77+oHzTTiBHKJeaOY vYItFMcXF7Cb0lDOXq+gpbI4AAA8zGVr2cfgWY67h20Gdh0AAHfUssP4XAqmQzcDuw4AABO1 bEb3y9x4QUfvB3YdAAAtalkAAACsiloWAAAAq6KWBQAAwKqoZQEAALAqalkAAACsiloWAAAA q6KWBQAAwKqoZQEAALAqalkAAACsiloWAAAAq6KWBQAAwKqoZQEAALAqalkAAACsiloWAAAA q6KWrfT/AACAC3l2ZYE+atlKbHoAAC6Dx/oSqGUrsekBALgMHutLoJatxKYHAOAyeKwvgVq2 EpseAIDL4LG+BGrZSmx6AAAug8f6EqhlKwWb/u1Dj8wKOeWnrI321oi7j75rRg6G2x3JJSbO aHSs0bkowYOx2ol0RwFwPdSyS6CWrRTXssFfu+3xYN06b+jdtsFo/EQC5ohBGm2ZqIyuF4hB r9HF6c6l29dL3jzIxQi8LGrZJVDLVtJrWfOI/i6OdvT5ekAtazbwqjTz3W78oZoy6DW/ermD 1LIAYtSyS6CWrZSuZXdfwWy/oGkeqUkalm7hGJ+v0fjiZ5ltY/Ng0D0ed7SWDfLpds/1Co7r B3fvtplQywJ4Ry27BGrZSrlatluaUMI+hVeh5krJIIjY/Sm1rFKmm//oGu2ljBU3oJYFUI5a dgnUspXmv8eAWvaElPrp6A9lvbHEBLxmR38uq/ca2uTi1WSOsh1r90JcJQCvg1p2CdSylea/ x8CrV8TPunAc/XzpcYb6pmtZvdacr2Vzb43WjpNpU8sCEFHLLoFattIDvscAjzFzvnJhu+1z CQwVryvWsvoCtgepZQHEqGWXQC1bKfczubZP0G4ty2P1MZRadvRz2biu6nZJ1LLd0lnZlt08 H9DLa5BYduXKopYF8I5adgnUspXSvyvhftCsk7bdt0cqU0cjOGXK+Yqj6dVYkEAcJxgx2Ifx KF6G3V65scxLwJxInKTXJhgrSBXA66CWXQK1bCU2Pd5R/QDABfBYXwK1bCU2Pd5RywLABfBY XwK1bCU2PQAAl8FjfQnUspXY9AAAXAaP9SVQy1Zi0wMAcBk81pdALVuJTQ8AwGXwWF8CtWwl Nj0AAJfBY30J1LKV2PQAAFwGj/UlUMtWYtMDAHAZPNaXQC1biU0PAMBl8FhfArVsJW/Tt79s s/t7QXEG3d+z2j2n8W9hHToophR3L8wEAC6PWnYJ1LKVupuegmAhbVW3e7dtH0Qwu+sH9ZRG 88xlAgCvgFp2CdSylahlL8Ms5toG3SNxLasMuoswVF4reYq9vIMAcGHUskuglq00VMu2Ncr2 iPelZDMUDqLXsl7JWFjLtn+llgWAQ1HLLoFatlK6lvVeB73wAN5HreKHsjf/JLZ/NY/EAwUx g8SC+N6gQSgAuDBq2SVQy1aa+Vw20QBHEz+XDSpOr2Yt+Vy2G1OpbnOf5gLAK6CWXQK1bKXj atnggzocp7aW7UZO1LKJlolall0H4DVRyy6BWrbSAz6XxSMphaNZyHb/+XF0LTtZ8vKlAAC4 Ucsuglq2Et9jcDHByov/0ohPohlTr2WV10FKyqDsNwCvjFp2CdSylQ6qZW/O/x40mS26vG9O zRWO5se0XkzvM12vu9l3+1Y3vtnFDAUAL4JadgnUspXY9AAAXAaP9SVQy1Zi0wMAcBk81pdA LVuJTQ8AwGXwWF8CtWwlNj0AAJfBY30J1LKV2PQAAFwGj/UlUMtWYtMDAHAZPNaXQC1biU0P AMBl8FhfArVsJTY9AACXwWN9CdSyldj0AABcBo/1JVDLVmLTAwBwGTzWl0AtW0n5HbbmbzHd vZhX/mtIzY6X/6Wmyu+bFRsEa5XoFa98rhcAYIdadgnUspXiTb+tJLzXo7pVy1BRNTrQtWuj XXHp/QtEaRCXv6O94n+T5HoBAFrUskuglq0UbPqg9KGWPaH3qc3UskGo7rhxr25lTC0LACWo ZZdALVtpqJZt32o/k2trqe3B4OvdiVrWjHY/Yn5e6BVeQajuwVPVWyW1rPLu6CijYw3V0wCA d9SyS6CWrVRVy5ol1K6KjcOO1rLeiPHQcQNlRnFWT5eoZb1/YFDLAsByqGWXQC1b6ehaNj7o xdzpzqKwKo3zPH9pNVrLDrWPh4uDDNWyYi8AwA617BKoZSsV1rJt9ZmuZcXkEyN6B83S2Sym 9Qr7KUZrWf2v8VjdINSyAPAA1LJLoJatNPn/fumfYpbXspMfwQY1XzyW3uspHlbLds/jbeQj 9lwvAMAOtewSqGUrTf5Mrski0hxrtJYt+Vx2std5PKaWTbw1XxkDALqoZZdALVup8HcltC29 cjD+mFMvX+6hvE/1goPtjMxpKgdPVW952QbnxZymGartEuyNIFp3rO5xAICJWnYJ1LKV2PQA AFwGj/UlUMtWYtMDAHAZPNaXQC1biU0PAMBl8FhfArVsJTY9AACXwWN9CdSyldj0AABcBo/1 JVDLVmLTAwBwGTzWl0AtW4lNDwDAZfBYXwK1bCU2PQAAl8FjfQnUspXY9AAAXAaP9SVQy1Zi 0wMAcBk81pdALVsp2PTxryp9ruCXoAZpn2oK5Y6Y3eTq3df/PPtHzOQp2eqDps9Fe0Xov8H4 wfeB9opOZ7jdhPoKAIuill0CtWyluJbtHjmaN2Jcy+pvXYk5u/liNN39hMseZ/L0f/bo6U1G vtd2Xpv4H4GPWZw2yXSGbanaXQFgXdSyS6CWrUQtexnltWxVHXyeZX/ZWtYM5VVy5rsHZdId wjwpcZlrvtW9Orw2wHKoZZdALVspXcuaX5i7H4kfRXH3bV/va3+FtexlHmD3lTcXsF3bXeOb UBC0Yb2Dbw29rzkvJQ3z9W76Xiaj69O29Hrps97FNPPX16G7pG0+wV+Vt4am2S5+d4igTfet 0YDAuqhll0AtWylXy8YP4OChO3MwkZsY7RrMZQ9KsaFFnjl3ib61aeQy0XvNjzXfpTvlrVwt a5aqZvvJFfNGV0b03rr/uZvC24Y5L2A51LJLoJatlPt/v6qqHO+gOVB8fPd07KZ9PfpSB68L G8+UaGb8wh1oJl8bX9/YMwuVmLKXWPzX7luJaSoNRoN7ocxbgT5lYCHUskuglq0kfi7b3vTb YnHoWevVmmL1KT6hX+pZtUQta26b3UFvGwzVQMoKKBt4Jn47lhh/cnTxEoivjuBi6e6BeLih dQ4yUeYSx3yp+wNeB7XsEqhlK+nfYzBZ0HgH46Ena1kl7ctYopaN+3rKa9n5GmtohUdDHT2R xF+7b1HLAidBLbsEatlK87Ws+dg44qkcpJf7IOpiRuuGYJFH1zNRy3YzDFLKpeGldHQtO7Ni Bx00j+gXzmTZGq+YfpF2MxxqMDQ0cGbUskuglq109M8x2LYUu3sll5mhGcRL+61htl+UVzcE dVu72kGo7RHx3JnRlL7x7JRQ3bm0G6Bdq8n4o7M2uwSnT4yzi6ZM89YsuNmyOyMxvV2qcSZ6 huIUvBUAFkUtuwRq2UoHbXoeDCe33AlaLmEAeApq2SVQy1ailn1Ny52g5RIGgKegll0CtWwl atnXtNAJ4uu/AKCjll0CtWwlNj0AAJfBY30J1LKV2PQAAFwGj/UlUMtWYtMDAHAZPNaXQC1b iU0PAMBl8FhfArVsJTY9AACXwWN9CdSyldj0AABcBo/1JVDLVmLTAwBwGTzWl0AtWyn9O2yr 8KNDq4i/6nMolPfrQINe5u9K3TVTfmuo8otVb/4vPo2TPEKQW6ttKa5JOg3viPebXcUg3XPd TVjk5RmvW9ugm5J4LuIIifajE9wdOaJ7dzpvjW4XL4jefjtE1a64GGrZJVDLVnpuLXu/H5XH fEHec2hmQYYeTsrZbJ+geqjgoO647dEu9dBklWb6Wdj91Rti6LhZ/cRDV612bieIs1O6DEns ydEJttVbeXcvN69lTjpCYtHMI5d8XlDLLoFathK17GU8t5YVW46Wd+0TN3gGKw6tZW9hemIt KwbvNu5mZUYbWvnuuT5otePMvSPdLSqGzaU31Fj5F0i6ltU3avcsP6uW1c8UtSxOi1q2UrqW ffvCroH5L/744RFUYPGI9zbbm+/ur97srkcpOMw13Np2NF+YQcyxgiS9v5pjdSfYvvB2ZjyR eNy2vZm2F8SbbHC821IJqCya2VcJEmTeXY225eh9o3swWC4xQtvA21rdzRN09zKJW3Z32mT3 OMP4rfZ6vP91d8UFfw2S1E/f0K64DGrZJVDLVsrVst1H4+721I3f7as3uOS9SdEtOOKHQXxO u0G2FYn5zDbH7bYJpuOlFycfTCQxrpm2txXjCyFYtG6EoJmyaGZfJUiQedslyFZc4fjdoapF L4bi7uJVI77eHYz3TxCkpHuc4f0t83oXrzjzhfl69L4RHNRnty5q2SVQy1aar2XN9nHLoL0S Rz/4UnYroD8tgndH657ucyLxTIoLqSCB9MH2Ty9VM219Ne7HxTJO39tDi+YN0Q0SVDB6wt3C JWg/dHB07rsSTb/bdMuv0ctqdDpK/dft7v1VeUusUPWWQ+du6OAlnxfUskuglq1U+D0Gbx/a dWmPt8xRlOA35574UnYroD8tgr96fYMTEYTtjhu0ER9vJQfbP+/v7va8l3bb15us3ix+y2wp Lpo3RDfI0LaJU/VGDBrHB4P0huLot6Btl3afiDerxEXqvTXZ3fur8lb3vlFyd4rTmL/c1kUt uwRq2Urz/+9X97Y+Gly86Q+1fAVmQWa+CF57XRJnJ44cdOw+mIOyrORg+2d3Xt0MvV56s/gt s6W4aN4Q3SDemTKrFmVSwZorCcdvDc29PTjZRblw0n/tXjKJ7t5flbeUClVs2d23hbviMqhl l0AtWyne9Er1M1mDtse3fSdrlJeSO0E3a8WCErY9O0OPmdxzSI+T2yczr4OUxKfmfOkgNk6c jvhIons3z6pCNo6cOBeJraXXZ2ZKF65l02s1WciKEVZHLbsEatlK3U3/9gXleHtw6F7TrZOC 4G3fYKBLEouwdg23dl28J8327Hh7oJtDdxvoR5QnYjB3L3J3e+eSNPsq144eUOkeDD2Ug9hd XDezy1vDO9hG6J7lNh9vRl6o4MSZycR57toEyXTTnuxutlTeMud4E9aqu5LdRQtWUpnsNVDL LoFattLJN/1V7zWIcd4Va63SebI9TybAEU7+WMc7atlKJ9z03r/L8To474q1Vuk82Z4nE+AI J3yso0UtW+mcm/7aXwCCgrOPI7CvcHnnfKxjh1q2EpseAIDL4LG+BGrZSmx6AAAug8f6Eqhl K7HpAQC4DB7rS6CWrcSmBwDgMnisL4FathKbHgCAy+CxvgRq2UpsegAALoPH+hKoZSux6QEA uAwe60uglq3kbfr2NwGe4ecyTuaw/X2Gp5pXCX1GZst4Tbq/AVLsm+gOANBRyy6BWrZSd9M/ vbYoTODN+t3ctUM8iz4jr2XcJV66YPS2Zh3qDgAYQi27BGrZStSy5aM8xTlr2fZdZZ1XPxcA 8ETUskuglq00VMvuShPzK8W35qM4s6V4sP1r0N0bvZ1LUMsuWkgpFWpQd3Zr3/TnsmYOsUVP AQCcAbXsEqhlK43WskGR5DXwWh5xMC5JX/NzWbEY3TIbmJHbf3XEa7sbbtcs+HcIAEBBLbsE atlKic9lgzbdulPvHiegHxQHWr2Emq9lze5BCbvtOPS5rH6aAACjqGWXQC1baaaWbT+K8xrH n8NRy84bqiaDlruD3X+QJGpZfXQAwChq2SVQy1ZK17KF1SS17LzJz2XNaG+NoOVQMsroAIAE atklUMtWmq9lu5/Lxgcnu3cPmnNRKqq1TNay3QUZ+kfIaC17vdMBAM9CLbsEatlK899jcBOq SfODvba72TIodtuWXqq7g8HHjesWUuaMgn9+mOvcLogZxzubZnelZTw6AEBELbsEatlKbHoA AC6Dx/oSqGUrsekBALgMHutLoJatxKYHAOAyeKwvgVq2EpseAIDL4LG+BGrZSmx6AAAug8f6 EqhlK7HpAQC4DB7rS6CWrcSmBwDgMnisL4FathKbHgCAy+CxvgRq2UpsegAALoPH+hKoZSux 6QEAuAwe60uglq0UbPq3xiMTi3nJ6EnmpnOqRTAFv5vXPKHecQDAiqhll0AtWymuZbtHjhbU rGZ6cYbbdy9Zy7b1q/dWty8AYEXUskuglq1ELVuSzxmYud0PUssCwCugll0CtWyldC0bfCH7 5pRQYvdtX6883Y3iHQmibb/CHuSgzOsk9Do+1wAAcH7Uskuglq2Uq2XNCnVXNSothw62mQS1 rDKEmbk4rxPq1rItvTsAYAnUskuglq2U+3+/CivUuGyNa9mbX8Lq46Z7nU1bqXv/qOh2BwAs ilp2CdSylcTPZb0vxKc/gvVK5KBoNnMLalkxQyXbbj5nEP9jgFoWAF4BtewSqGUr6d9j0C3p Jj+CNUOVfC7bnQK1rNIAAHB+1LJLoJatNF/Lep+JKi2HDuaS6R5M9zqh0X9+BH0BACuill0C tWylo3+Owbal2L1tFucWvA6i6b3MKZy28jNXe3fca/DYTAEA9ahll0AtW+mgTU9hBADA41HL LoFathK1LAAAl0EtuwRq2UrUsgAAXAa17BKoZSux6QEAuAwe60uglq3EpgcA4DJ4rC+BWrYS mx4AgMvgsb4EatlKbHoAAC6Dx/oSqGUrsekBALgMHutLoJatxKYHAOAyeKwvgVq2EpseAIDL 4LG+BGrZSvHvsPV+5Wnix8d2fxUtJuXOl/crbXfv7g6aLbtH9JbdEXNdgvWJf8EvAKyCWnYJ 1LKV4lrWO1JVy6JQ4nzF9Z9XDYtlq1kRepWxnonSRYl5m9vPAHBO1LJLoJatRC17GaPnKz6o RwsK5apa9tYrVSdjsjkBXAa17BKoZSvN17Lel6HbL+MGce7FhxnHTObWlCxiJqM5BxM5laNr WbNjt5n4cSm1LACUoJZdArVspcnvl00c9N4NWrZ1Z9BrMr1uVqelnK9d++CgUsvGa6LUsspr 793ROHEtG6weACyEWnYJ1LKVJj+X7daFu3e9j8r0+tLLUG+sh+rGPBXlfMXtu122b3ULvl2o 7qqKZzAuauOYQ7U+AKyIWnYJ1LKVHlnLttVPbS3rlSnBQS+UmMCpPLKW9ZbIfMurZdviUkk4 rmXFmN4+BIDVUcsugVq20oM/l1W6pGvZmQbUst0u3lveyii1bCLhbi2bSPv8JxcARNSyS6CW rXR0LVvVZahUjSMUFtOnMloatsfFai8YSO8epyQm3E0siLnWyQUAEbXsEqhlK83/roT2XfNg osC9x7kJ1VKcyRE5n018vpS3gpi7g2bL4Ej72lvG+7tmwvooZkyvbzvcac8yAMSoZZdALVtp lU1PbQEAQNcqj/UXRy1b6cybXvnIDQAA3J35sY47atlKJ9/0fMEXAADdyR/reEctW4lNDwDA ZfBYXwK1bCU2PQAAl8FjfQnUspXY9AAAXAaP9SVQy1Zi0wMAcBk81pdALVuJTQ8AwGXwWF8C tWwlNj0AAJfBY30J1LKV2PQAAFwGj/UlUMtW8jZ9/MtCvSPx8W2DM/y+0PlxzzALUzer02YO AJhBLbsEatlKYi1r/kb7mVp2tIsoMXThWCcpCpXTdJJUAQC1qGWXQC1bKdj07a+QFX+pLLXs cylpnCRVAEAtatklUMtWmq9l269T3xvrH9zuuisBvQZBqPavo4PGs9i92/YNRokbDHlkQQ8A OBVq2SVQy1aarGWD6rYNYkZu+4oBvZZB/qMH41ncrNKzapSZctOr7Nu0g0odALAiatklUMtW ijd9t4QdKii3B71yar4ADSYyH9+jfJiaK74TusnsjlDOAsBlUMsugVq20nwt25akuapuNKBS y1aFEqu9uKRWRkl/XLrtNVqqUssCwGVQyy6BWrZS4eeyuzZig9H2uQL0iFo2+Lxz/nPZGdSy APCyqGWXQC1bqbvp469Ql1SBSsA2+FBV+sRadrL4TujWsqPFLgBgFdSyS6CWrTRZy94+/Or2 7ohXJHXr4zbg7cOS1BvIzOT2Ye3o1ZHmoF7CbQLdZemOojQQmVkNnSMAwIqoZZdALVtpiU1P vQUAgGKJxzqoZSstsempZQEAUCzxWAe1bKUlNj21LAAAiiUe66CWrcSmBwDgMnisL4FathKb HgCAy+CxvgRq2UpsegAALoPH+hKoZSux6QEAuAwe60uglq3EpgcA4DJ4rC+BWrYSmx4AgMvg sb4EatlKbHoAAC6Dx/oSqGUrBZte/w20+rtH4KfPAgDwjlp2CdSyleJati0TzYO7BjWZhbaj FI5IWQwAWBq17BKoZStRy3phAQBYDrXsEqhlK3W/x6CtGndHdtWt12v3utuxbeANeu84Gq2N E4zYDhHPYhdW6QUAwCRq2SVQy1aaqWW9ItV7K363LU/b117MtmM3WvfgbjhziO4sxF4AAJSg ll0CtWwl5f/9CkpYr/GuV1vCBh2D190Gk9GCWjYRYSgxAADmUcsugVq20mQt+7YR9DI/jvU6 7t4tqWXNaHEO4nDxLMzE4qkBAJBGLbsEatlKM7VsXEQGtez8B5bzH392ew01HqplzSEAAJhH LbsEatlK4s+X7ZatejE30zGRWzr57nC5WQyV7AAADKGWXQK1bKWZWva2KeNGS9K4471BUFzq n4960cwcRkvnxPTbZChqAQAlqGWXQC1biU0PAMBl8FhfArVsJTY9AACXwWN9CdSyldj0AABc Bo/1JVDLVmLTAwBwGTzWl0AtW4lNDwDAZfBYXwK1bCU2PQAAl8FjfQnUspXY9AAAXAaP9SVQ y1Zi0wMAcBk81pdALVuJTQ8AwGXwWF8CtWwlNj0AAJfBY30J1LKVxN9hqxxX3gUAAMehll0C tWyluJZtC1Pz4K5BTWZFzpYPAADHoZZdArVsJWpZAAAug1p2CdSylbrfY7CtBc0ju+rW67V7 3e3YNmjTaxvsDpqjeL2GpuZNEACAJ6KWXQK1bKWZWtYrUr234nd3NajZPYg5dNBs0E1gKEMA AB6PWnYJ1LKVlP/3Kyhhvca7Xm0JG3QMXscHc2FzB2/hpAAAeApq2SVQy1aarGXfNoJewVfw u2GHatlEWGpZAMBlUMsugVq20kwt2/2Svflnt+NNKBC7Ba4elloWAHAZ1LJLoJatJP582W7Z OvStAumOR+Sj92ozoZAFAJwKtewSqGUrzdSyt039N1qSxh3vDYJi0WxghjW/zSDuZbaklgUA nBy17BKoZSux6bdGa1NqWQDAqfBYXwK1bCU2/dD36QZ9AQB4Oh7rS6CWrcSmvwnfz+B1OS4l AAASeKwvgVq2EpseAIDL4LG+BGrZSmx6AAAug8f6EqhlK7HpAQC4DB7rS6CWrcSmBwDgMnis L4FathKbHgCAy+CxvgRq2UpsegAALoPH+hKoZSt1f++X91uy2h/LuvsdsGIvAABQhVp2CdSy leJatv0Fs2Yx6lWx3V9sCwAAClHLLoFatlL3c9n2dXvQa0ktCwDAI1HLLoFatlKiln3b6LZs u1DLAgBwEGrZJVDLVhqtZYc+djUbAACAg1DLLoFatlK6lh39XNZsAAAAClHLLoFatlL6ewxu I5/L3jbfZmC+CwAA5lHLLoFathKbHgCAy+CxvgRq2UpsegAALoPH+hKoZSux6QEAuAwe60ug lq3EpgcA4DJ4rC+BWrYSmx7Mw6UWAAAASklEQVQAgMvgsb4EatlKbHoAAC6Dx/oSqGUrsekB ALgMHutLoJatxKYHAOAyeKwvgVq2EpseAIDL4LG+BGrZSmx6AAAug8f6Ev5/xBO8xuhLdyQA AAAASUVORK5CYII= --------------070507010902080703090500-- --------------050708040602020203020202--