Hi Robert, Thanks for your comments, please see my replies inline:
> -----Original Message----- > From: Robert Sparks [mailto:rjspa...@nostrum.com] > Sent: Tuesday, October 20, 2015 11:10 AM > To: Dongjie (Jimmy); General Area Review Team; p...@ietf.org; > draft-ietf-pals-redundancy-spe....@ietf.org > 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:ietf-boun...@ietf.org] On Behalf Of Robert Sparks > >> Sent: Saturday, October 17, 2015 5:31 AM > >> To: General Area Review Team; i...@ietf.org; p...@ietf.org; > >> draft-ietf-pals-redundance-spe....@ietf.org > >> 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 > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
