Re: [PWE3] [Errata Verified] RFC5601 (4069)

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 07 August 2014 04:01 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65D51A0A99; Wed, 6 Aug 2014 21:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBV6M_OOihbP; Wed, 6 Aug 2014 21:01:05 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE041A0A96; Wed, 6 Aug 2014 21:01:04 -0700 (PDT)
Received: from DB4PR03MB623.eurprd03.prod.outlook.com (10.141.235.14) by DB4PR03MB622.eurprd03.prod.outlook.com (10.141.234.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 04:01:01 +0000
Received: from DB4PR03MB623.eurprd03.prod.outlook.com ([10.141.235.14]) by DB4PR03MB623.eurprd03.prod.outlook.com ([10.141.235.14]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 04:01:01 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: [PWE3] [Errata Verified] RFC5601 (4069)
Thread-Index: AQHPsZ0cTt9B/tK/qE6RM/UugAdBVZvD9ctAgAACF4CAAIxtGA==
Date: Thu, 07 Aug 2014 04:01:00 +0000
Message-ID: <1407384054140.37254@ecitele.com>
References: <20140806173601.7195B18001B@rfc-editor.org> <01d71ed3a97243f386a0a7a9247e91df@AM3PR03MB612.eurprd03.prod.outlook.com>, <CAA=duU2MSRLPvYqnyDAdaHyruxDwZRwAkAno3iZib=Ch93f0fg@mail.gmail.com>
In-Reply-To: <CAA=duU2MSRLPvYqnyDAdaHyruxDwZRwAkAno3iZib=Ch93f0fg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [164.40.145.154]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 029651C7A1
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377424004)(377454003)(24454002)(51704005)(13464003)(252514010)(92566001)(74502001)(95666004)(31966008)(85306004)(74662001)(19617315012)(106116001)(99396002)(16236675004)(15975445006)(46102001)(64706001)(79102001)(86362001)(20776003)(81542001)(92726001)(87936001)(36756003)(106356001)(2656002)(105586002)(85852003)(4396001)(83072002)(16601075003)(80022001)(101416001)(76176999)(76482001)(19580395003)(19580405001)(83322001)(19625215002)(15202345003)(16297215004)(50986999)(107046002)(16799955002)(15188155005)(66066001)(19627405001)(81342001)(77982001)(21056001)(54356999); DIR:OUT; SFP:; SCL:1; SRVR:DB4PR03MB622; H:DB4PR03MB623.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_140738405414037254ecitelecom_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/bR8d3bJGbV3RJfFceXG79fNuR2s
Cc: "brian@innovationslab.net" <brian@innovationslab.net>, "pwe3@ietf.org" <pwe3@ietf.org>, "davidz@oversi.com" <davidz@oversi.com>, "thomas.nadeau@bt.com" <thomas.nadeau@bt.com>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [PWE3] [Errata Verified] RFC5601 (4069)
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 04:01:09 -0000

Andy,

Lots of thanks for an important input. There was no way I could guess that from the Errata System report as it only mentions Brian as the verifier.



Adrian, Brian

Lots of thanks to both of you!



Regards,

Sasha

________________________________
From: Andrew G. Malis <agmalis@gmail.com>
Sent: Wednesday, August 6, 2014 10:35 PM
To: Alexander Vainshtein
Cc: brian@innovationslab.net; davidz@oversi.com; pwe3@ietf.org; iesg@ietf.org; thomas.nadeau@bt.com
Subject: Re: [PWE3] [Errata Verified] RFC5601 (4069)

Sasha,

Just to give credit where it's due, Adrian was the source of the improved text.

Cheers,
Andy


On Wed, Aug 6, 2014 at 3:29 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
Brian,
Lots of thanks for a prompt verification and for the much better corrected text.

Regards,
       Sasha
Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>
Mobile: 054-9266302


> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>]
> Sent: Wednesday, August 06, 2014 8:36 PM
> To: Alexander Vainshtein; thomas.nadeau@bt.com<mailto:thomas.nadeau@bt.com>; davidz@oversi.com<mailto:davidz@oversi.com>
> Cc: brian@innovationslab.net<mailto:brian@innovationslab.net>; iesg@ietf.org<mailto:iesg@ietf.org>; pwe3@ietf.org<mailto:pwe3@ietf.org>; rfc-editor@rfc-
> editor.org<http://editor.org>
> Subject: [Errata Verified] RFC5601 (4069)
>
> The following errata report has been verified for RFC5601, "Pseudowire (PW)
> Management Information Base (MIB)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5601&eid=4069
>
> --------------------------------------
> Status: Verified
> Type: Technical
>
> Reported by: Alexander ("Sasha") Vainshtein
> <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
> Date Reported: 2014-08-05
> Verified by: Brian Haberman (IESG)
>
> Section: 12
>
> Original Text
> -------------
>  pwAttachedPwIndex OBJECT-TYPE
>      SYNTAX        PwIndexOrZeroType
>      MAX-ACCESS    read-create
>      STATUS        current
>      DESCRIPTION
>          "If the PW is attached to another PW instead of a local
>           native service, this item indicates the pwIndex of the
>           attached PW.  Otherwise, this object MUST
>           be set to zero.  Attachment to another PW will have no
>           PW specific entry in any of the service MIB modules."
>      DEFVAL { 0 }
>      ::= { pwEntry 10 }
>
> Corrected Text
> --------------
>  pwAttachedPwIndex OBJECT-TYPE
>      SYNTAX        PwIndexOrZeroType
>      MAX-ACCESS    read-create
>      STATUS        current
>      DESCRIPTION
>           "If the PW is attached to another PW instead of a local
>            native service, this item indicates the pwIndex of the
>            attached PW.  Otherwise, this object MUST
>            be set to zero.  Attachment to another PW will have no
>            PW specific entry in any of the service MIB modules.
>            This object may be modified only when the value of
>            the associated pwAdminStatus object is down(2), and
>            the associated pwOperStatus object has value down(2)
>            or notPresent(5) such that the row in the pwTable
>            represents an inactive PW."
>      DEFVAL { 0 }
>      ::= { pwEntry 10 }
>
> Notes
> -----
> Description of the pwEntry object in the same RFC states that "The read-
> create objects in this table are divided into
>            three categories:
>            1) Objects that MUST NOT be changed after row activation.
>               These are objects that define basic properties of the
>               PW (for example type, destination, etc.).
>            2) Objects that MAY be changed when the PW is
>               defined as not active.  A change of these objects involves
>               re-signaling of the PW or it might be traffic affecting.
>               PW not active is defined as one of the following
>               conditions:
>                   a) The pwRowStatus is notInService(2).
>                   b) The pwRowStatus is notReady(3).
>                   c) The pwAdminStatus is down(2).
>            If the operator needs to change one of the values for an
>            active row, the operator can either set the pwRowStatus to
>            notInService(2) or set pwAdminStatus to down(2).
>            Signaling (or traffic) is initiated again upon setting
>            the pwRowStatus to active(1) or setting the pwAdminStatus
>            to up(1) or testing(3), respectively.
>            3) Objects that MAY be changed at any time."
>
> In further states (in tthe same description) that "By default, all the read-
> create objects MUST NOT be changed after row activation, unless specifically
> indicated in the individual object description."
>
> pwAttachedPwIndex object is used to stitch a couple of PWs represented by
> two different rows in the pwTable, with the pwAttachedPwIndex value in
> the row representing one of them set to the pwIndex of the other one and
> vice versa.
> Since there is no way in the SMIv2 paradigm to create two rows in the same
> table in a single atomic operation, setting a this attribute in a pair of rows is
> only possible when both are created. In order to do that, read-create access
> mode of the pwAttachedPwIndex object has to be interpreted as ability to
> set its value when the row represents an inactive PW.
> In accordance with the quoted description, such an interpretation must be
> explicitly specified in the description of this object.
>
> Such a specification is missing in the current text, hence the default
> interpretation of the read-create access mode is holds.
> Proposed text fixes this problem.
>
> --------------------------------------
> RFC5601 (draft-ietf-pwe3-pw-mib-14)
> --------------------------------------
> Title               : Pseudowire (PW) Management Information Base (MIB)
> Publication Date    : July 2009
> Author(s)           : T. Nadeau, Ed., D. Zelig, Ed.
> Category            : PROPOSED STANDARD
> Source              : Pseudo Wire Emulation Edge to Edge INT
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3