Dear Nabil,
can we avoid different interpretation of the same abbreviation (RDI):

   RDI   Remote Defect Indication for Continuity Check Message

   RDI   Reverse Defect Indication

AFAIK, the latter form is the interpretation used by both IEEE 802.1ag and
Y.1731. How useful is the first form?

Regards,

Greg


On Fri, Jan 4, 2013 at 8:17 AM, Bitar, Nabil N <[email protected]>wrote:

> Hi Dave,
> Related to abbreviations comment below and to be clearer, I renamed the
> original terminology section to "Abbreviations and Terminology". I also
> created a subsection called "Abbreviations" ,and "Terminology" became the
> second subsection.  Here iis how the edits look
>
> 3. Abbreviations and Terminology****3.1. Abbreviations****
>
>         AIS   Alarm Indication Signal****
>
>    AC    Attachment Circuit****
>
>    BFD   Bidirectional Forwarding Detection****
>
>    CC    Continuity Check****
>
>    CCM   Continuity Check Message****
>
>    CE    Customer Equipment****
>
>    CV    Connectivity Verification****
>
>    E-LMI Ethernet Local Management Interface****
>
>    EVC   Ethernet Virtual Circuit****
>
>    LDP   Label Distribution Protocol****
>
>    LoS   Loss of Signal****
>
>    MA    Maintenance Association****
>
>    MD    Maintenance Domain****
>
>    ME    Maintenance Entity****
>
>    MEG   Maintenance Entity Group****
>
>    MEP   Maintenance End Point****
>
>    MIP   Maintenance End Point****
>
>    MPLS  Multiprotocol Label Switching****
>
>    MS-PW Multi-Segment Pseudowire****
>
>    NS    Native Service****
>
>    OAM   Operations, Administration, and Maintenance****
>
>    PE    Provider Edge****
>
>    PSN   Packet Switched Network****
>
>    PW    Pseudowire****
>
>    RDI   Remote Defect Indication for Continuity Check Message****
>
>    RDI   Reverse Defect Indication
>
>    S-PE  Switching Provider Edge****
>
>    TLV   Type Length Value****
>
>    T-PE  Terminating Provider Edge****
>
> ** **
> 3.2. Terminology****
>
> This document uses the following terms with corresponding definitions: ***
> *
>
> - MD Level:  Maintenance Domain (MD) Level which identifies a value in
> the range of 0-7 associated with Ethernet OAM frame. MD Level identifies
> the span of the Ethernet OAM frame.****
>
>  - MEP:    Maintenance End Point is responsible for origination and
> termination of OAM frames for a given MEG.****
>
>  - MIP:      Maintenance Intermediate Point is located between peer MEPs
> and can process OAM frames but does not initiate or terminate them.****
>
> Further, this document also uses the terminology and conventions used in
> [RFC6310].****
>
>
>
> Thanks,
>
> Nabil
>
> From: <Bitar>, Nabil N <[email protected]>
> Date: Wednesday, January 2, 2013 11:28 AM
> To: "Black, David" <[email protected]>, "[email protected]" <
> [email protected]>, "Bitar, Nabil N" <[email protected]>,
> Sagessi <[email protected]>, "[email protected]" <[email protected]>
> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
> Subject: Re: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06
>
> Hi Dave,
> Sorry for a late reply addressing your comments. Please, see inline.
>
> Thanks,
> Nabil
>
> From: "Black, David" <[email protected]>
> Date: Monday, August 20, 2012 8:57 PM
> To: "[email protected]" <[email protected]>, "Bitar, Nabil N" <
> [email protected]>, Sagessi <[email protected]>, "
> [email protected]" <[email protected]>
> Cc: "Black, David" <[email protected]>, "[email protected]" <[email protected]>,
> "[email protected]" <[email protected]>
> Subject: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please
> see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06
> Reviewer: David L. Black
> Review Date: August 20, 2012
> IETF LC End Date: August 20, 2012
>
> Summary:
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> <NB> Thanks.
>
>
>
> This draft covers defect behavior for Ethernet pseudowires,
>
> including defect state mapping and PE defect reporting behavior.
>
> The draft is generally in good shape.  I found a few minor nits.
>
>
>
> 1) The draft uses a lot of acronyms - while each acronym appears to
>
> be expanded on first use, an additional section near the start of the
>
> draft listing all of them would be helpful.
>
> <NB> Done.
>
>
>
> 2) There's a typo in the first paragraph of section 2:
>
>
>
>      covers the following Ethernet OAM (Opertaions, Administration and
>
>
>
> Opertaions -> Operations.
>
> <NB> Thanks. Done.
>
>
>
> 3) The following normative reference is incomplete - please add additional
>
> information that will enable a reader to locate the referenced document:
>
>
>
>      [MEF16] "Ethernet Local Management Interface", MEF16, January 2006.
>
> [MEF16] "Ethernet Local Management Interface", Metro Ethernet Forum
> Technical Specification MEF16, January 2006.
>
> <NB> changed it to :
>
>
>
> 4) idnits 2.12.13 did not like the pagination:
>
>
>
>   == The page length should not exceed 58 lines per page, but there was 22
>      longer pages, the longest (page 1) being 61 lines
> <NB> That will be fixed.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

Reply via email to