[Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02

Robert Sparks <rjsparks@nostrum.com> Fri, 16 October 2015 21:31 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEA1A1B49; Fri, 16 Oct 2015 14:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 XeiC8k07LSeP; Fri, 16 Oct 2015 14:31:02 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EC71A1B3E; Fri, 16 Oct 2015 14:31:01 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9GLV0i6007247 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 16 Oct 2015 16:31:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, pals@ietf.org, draft-ietf-pals-redundance-spe.all@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <56216C90.4060606@nostrum.com>
Date: Fri, 16 Oct 2015 16:30:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/VR1-i_yN6w2Oy58Sc9RUns1jb38>
Subject: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 21:31:03 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pals-redundancy-spe-02
Reviewer: Robert Sparks
Review Date: 16 Oct 2015
IETF LC End Date: 19 Oct 2015
IESG Telechat date: 22 Oct 2015

Summary: Almost ready for publication as PS but with issues that need to 
be discussed/addressed

This document is hard to read. It is more acronym-laden than it
needs to be.

-----
There is a process issue that the IESG should pay attention to.
The shepherd writeup says this:

   "There is one IPR declaration (1911) raised in November 2012 against
    an early version of the draft.  There was no discussion in the WG
    related to this."

That happens sometimes, but it's much better to have a real indication
that the group considered the disclosure and explicitly decided not to
change directions.
-----

The last sentence of the 2nd paragraph (declaring multi-homing on both
sides of an S-PE out of scope) should be moved earlier in the document.
The introduction and perhaps even the abstract can be clearer about
what _is_ in scope.

It needs to be clearer where the normative description of behavior is.
I think you're intending it to be the first part of section 3. I have
not worked through the references enough to ensure that it is complete.

The third paragraph starts off "In general, ...". Are there any
specific cases where the requirements that follow do not hold? If so,
there needs to be more description. If not, please delete "In general,".

Are sections 3.1 and 3.2 supposed to be only examples? Would the
specification of the protocol be complete if they were deleted? If not,
something needs to be moved up into the main part of section 3.
For instance, is the SHOULD at the end of 3.1 a requirement placed by
this document, or is it restating a requirement from somewhere else?
Similarly, please inspect the SHOULD in the second paragraph of 3.2.

I also suggest moving 3.1 and 3.2 into their own section, clearly
labeling them as examples.

Is it worth more explanation in the document why you've added the
MUST NOT in the first paragraph of section 3?

The security considerations section only points off to other documents.
Most of those just point to each other. Chasing it back, there's some
meat in the security considerations section of 4447, and some in 5085,
but it's a real chase to find what's relevant.  Please consider calling
out what an implementer needs to consider explicitly here.