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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert, 

Thanks for your comments, please see my replies inline:

> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: Tuesday, October 20, 2015 11:10 AM
> To: Dongjie (Jimmy); General Area Review Team; [e-mail];
> [e-mail]
> Subject: Re: Gen-art LC review: draft-ietf-pals-redundancy-spe-02
> 
> 
> 
> 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.

Sorry for making this document hard to read, could you provide some advices on how to improve the readability? 

> >
> >> -----
> >> 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.

I got your point, and I think the document is not under-specifying. Thus we can move section 3.1 and 3.2 to their own section.

> >> 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?

I'm thinking about whether the new procedures on S-PE would introduce any new attack vectors. 

What about we say something like: "Since PW redundancy is provided on the S-PE nodes, it is important that the security mechanisms as defined in [RFC 4447], [RFC 6073] and [RFC 6478] are implemented to ensure that the S-PE nodes and the messages received by the S-PE nodes are not compromised."

Best regards,
Jie

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