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

["Andrew G. Malis" <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>