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

[Robert Sparks <[e-mail]>]

On 10/19/15 9:34 PM, Dongjie (Jimmy) wrote:
> Hi Robert,
>
> Thanks a lot for your review and comments. Please see my replies inline:
>
>> -----Original Message-----
>> From: ietf [mailto:[e-mail]] On Behalf Of Robert Sparks
>> Sent: Saturday, October 17, 2015 5:31 AM
>> To: General Area Review Team; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Gen-art LC review: draft-ietf-pals-redundancy-spe-02
>>
>> 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.
> We will expand the acronyms on first use in next revision.
That won't change how hard this is to read.

Expanding the acronyms on first use won't make the prose later in the 
document any different.
The use of acronyms for the elements involved in almost all of the prose 
is unnecessary. The words for them are short enough.
>
>> -----
>> 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.
>> -----
> I hope Andy and Deborah have solved your concern on this.
>
>> 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.
> Agreed, will move it to the introduction of the document.
Thanks.
>
>> 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.
> Yes, the first part of section 3 defines the operation of S-PE.
>
>> 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,".
> We will remove "in general" in next revision.
>
>> 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.
> Good question. The last sentence of section 3.1 and 3.2 can be moved up into the main part.
>
> Since section 3.1 and 3.2 specifies the typical scenarios, my feeling is they are more than examples. May be better to keep them in section 3?
No, I don't think so.

If they can't be removed, then there is some part of this addition to 
the protocol suite that you are specifying by example, rather then 
specifying the behavior explicitly. That usually means you're 
under-specifying, and hoping people will infer (guess) the right thing 
to do in the unspecified cases. You will end up with better 
interoperability by being explicit.
>
>> Is it worth more explanation in the document why you've added the MUST NOT
>> in the first paragraph of section 3?
> Because if S-PE Bypass Mode is used, the S-PE will not receive the PW status message originated by T-PEs. We will add some explanation about this.
Thanks again.
>
>> 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.
> Since this document is mainly about reusing the redundancy mechanisms of RFC6870 on the S-PE nodes, we think the security considerations of these referenced documents could suffice.
That misses the point - whatever is important in those considerations 
for what this document is talking about is buried.
Why didn't you just copy the security considerations section of 6870 
into this document? (I'm not suggesting you do that - your use of 
"mainly" above says that wouldn't be enough. _Why_ it's not enough is 
worth capturing in this document.)

Isn't there something to new to say here about failure cases? You 
essentially have some new actors that (if they were to misbehave, or if 
someone could pretend to be them) could _cause_ at least the S-PE to 
believe there was a failure. Is that already discussed somewhere?

> And for an implementer IMO there is nothing new to be considered.
>
> Best regards,
> Jie
>