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

[Alexander Vainshtein <[e-mail]>]

Brian,
Lots of thanks for a prompt verification and for the much better corrected text.

Regards,
       Sasha 
Email: [e-mail]
Mobile: [phone]


> -----Original Message-----
> From: RFC Errata System [mailto:[e-mail]]
> Sent: Wednesday, August 06, 2014 8:36 PM
> To: Alexander Vainshtein; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; rfc-editor@rfc-
> 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
> <[e-mail]>
> 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