Re: [Gen-art] Gen-ART review of draft-ietf-pwe3-redundancy-bit-07.txt

"Aissaoui, Mustapha (Mustapha)" <> Wed, 27 June 2012 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 273B221F86A8 for <>; Wed, 27 Jun 2012 13:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lCY1nSqFfVCr for <>; Wed, 27 Jun 2012 13:22:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB89121F8665 for <>; Wed, 27 Jun 2012 13:22:03 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id q5RKLutW000436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jun 2012 15:21:56 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id q5RKLuxB020745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Jun 2012 15:21:56 -0500
Received: from ([]) by ([]) with mapi; Wed, 27 Jun 2012 15:21:56 -0500
From: "Aissaoui, Mustapha (Mustapha)" <>
To: "Miguel A. Garcia" <>
Date: Wed, 27 Jun 2012 15:21:55 -0500
Thread-Topic: Gen-ART review of draft-ietf-pwe3-redundancy-bit-07.txt
Thread-Index: Ac04tNVtXAkzBuQLRKy+X09n0lIVbwby0yMA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Cc: "" <>, General Area Review Team <>, Andy Malis <>, "" <>, Stewart Bryant <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-pwe3-redundancy-bit-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jun 2012 20:22:05 -0000

Hi Miguel,
Thank you again for the second review of this draft. All your comments are accepted and will be included in the next version.


-----Original Message-----
From: Miguel A. Garcia [] 
Sent: Wednesday, May 23, 2012 3:22 AM
To:; Andy Malis;; Stewart Bryant
Cc: General Area Review Team
Subject: Gen-ART review of draft-ietf-pwe3-redundancy-bit-07.txt

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft. For background on Gen-ART, please see the FAQ at <>

Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-pwe3-redundancy-bit-07.txt
Reviewer: Miguel Garcia <> Review Date: 23-May-2012 IESG Telechat date: 24-May-2012

Summary: The document is almost ready for publication as a standards track RFC, but has some minor issues that should be fixed.

I reviewed version -06 of this document. At that time I had a few comments. Most of them have been successfully addressed. In this review I am addressing the leftovers and new issues.

Major issues: none

Minor issues:

- In my previous review, I highlighted that many lowercase 2119-reserved words (like "must", "may", etc.) should actually be written in uppercase to be really normative. Rather than analyzing each case on a one by one basis, the authors have systematically written in uppercase all 2119-reserved words. The problem is that now some uppercase 2119-reserved words don't make sense, and should be reverted to lowercase. Allow me some examples:

   * Sections 1 (Introduction) and 2 (Motivation and Scope). Since these are descriptive sections in nature, normative text should not be written here. If there is a need to write normative text, it should be written later in any of the procedures sections.

   * Section 5.2, 1st paragraph, the "MUST" does not really have a normative intention as it is currently written:

    One endpoint node of the redundant set of PWs is designated the
    Master and is responsible for selecting which PW both endpoints MUST
    use to forward user traffic.

   * Section 15.2. I understand that this section describes scenarios or examples of architectures. Therefore, it does not make sense to write normative statements in here. If you need one, it should be written in any of the procedures sections. There is a "SHOULD" on the 4th paragraph of Section 15.2. The same applies to the last paragraph in Section 15.4 and last paragraph in Section 15.6.

Nits/editorial comments:

- The abstract has added a new sentence at the end. Unfortunately there is a new reference "in RFC 5542 [9]". Abstracts shouldn't include references. Just write "... in RFC 5542".

- There is an extra dot at the end of the second paragraph in Section 6.1. The same happen in the last paragraph of Section 15.3. And yet the same in the third paragraph of Section 15.4, and the second paragraph in 15.6.

- Section 15.4, second paragraph, the term "Figure" is repeated.

- Section 15.5, the last paragraph starts with some strange indentation.

Miguel A. Garcia
Ericsson Spain