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

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Oct 2015 16:30:56 -0500

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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 17 Oct 2015 10:52:26 +0200

Robert,

Thanks for your review of the draft.

As PALS WG co-chair, I would like to address one point in your review:

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 IPR declaration is against the original individual
draft, draft-dong-pwe3-redundancy-spe. The IPR declaration was from a
company that was not represented as an author on the draft, and offered
free licencing with reciprocity. At the time, no concerns were raised by
either the authors or from anyone in the WG in response to the declaration.
This, IMHO, is normal operating procedure when IPR declarations are made,
especially by non-author entities and early in the process. The usual
concern is when declarations come in late in the process, especially from
an author company. Neither was the case here, it was still an individual
draft. And of course, the declaration was clear for all to see during both
WG adoption and WG LC polls.

Thanks,
Andy

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 17 Oct 2015 16:11:48 +0000

Hi Robert,

Thanks for your review. As Andy explained, in the Routing Area, there are multiple points in the process where folks are made aware/reminded of IPR and we follow RFC6702 suggestions. And for folks not participating actively in the Working Group, they still have the opportunity at IETF Last Call (which has a pointer to IPR) to discuss/express concern.

If you would like to discuss/recommend additional considerations for the IETF to follow on IPR, it would be good to change the subject line as I don’t think the current subject line is much of an attention-grabber☺

I’ll let the authors answer your questions on the draft itself.

Again, thanks for your careful review-
Deborah

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Saturday, October 17, 2015 4:52 AM
To: Robert Sparks
Cc: General Area Review Team; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-art LC review: draft-ietf-pals-redundancy-spe-02

Robert,

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 IPR declaration is against the original individual draft, draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that was not represented as an author on the draft, and offered free licencing with reciprocity. At the time, no concerns were raised by either the authors or from anyone in the WG in response to the declaration. This, IMHO, is normal operating procedure when IPR declarations are made, especially by non-author entities and early in the process. The usual concern is when declarations come in late in the process, especially from an author company. Neither was the case here, it was still an individual draft. And of course, the declaration was clear for all to see during both WG adoption and WG LC polls.

Thanks,
Andy

On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

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

-----

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 20 Oct 2015 02:34:03 +0000

Hi Robert, 

Thanks a lot for your review and comments. Please see my replies inline:

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Saturday, October 17, 2015 5:31 AM
> To: General Area Review Team; [email-masked]; [email-masked];
> [email-masked]
> 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.
> 
> 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 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.

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

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

> 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.
And for an implementer IMO there is nothing new to be considered.

Best regards,
Jie

---

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Oct 2015 22:09:37 -0500

> 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.
> Agreed, will move it to the introduction of the document.
Thanks.
> 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.
> 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.
> 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?

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 20 Oct 2015 08:44:10 +0000

Hi Robert, 

Thanks for your comments, please see my replies inline:

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, October 20, 2015 11:10 AM
> To: Dongjie (Jimmy); General Area Review Team; [email-masked];
> [email-masked]
> >> 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.
> >>
> 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? 

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

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 11:15:55 +0100

Robert:

Many thanks for your detailed review. I will send some technical comments on this
topic but wanted to answer you and Andrew on the IPR issue separately:

Andrew wrote:

> The IPR declaration is against the original individual draft, draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that was not represented as an author on the draft, and offered free licencing with reciprocity.

OK. Interesting background information.

> At the time, no concerns were raised by either the authors or from anyone in the WG in response to the declaration. This, IMHO, is normal operating procedure when IPR declarations are made, especially by non-author entities and early in the process. The usual concern is when declarations come in late in the process, especially from an author company. Neither was the case here, it was still an individual draft. And of course, the declaration was clear for all to see during both WG adoption and WG LC polls.

I think this is the key. The standing practice at the IETF is that IPR gets declared, timely, and the information is used by the participants when they decide things like whether they support document adoption (among many other factors). I find that there is often no explicit discussion but those that care take the information into account, in careful and competent manner and through consultation with their colleagues back home etc.

So, it appears that the right thing happened here, and your answer above is the right one for Robert’s question.

However, I have one question, as I started digging… First, this is one of those many cases where an individual draft has an IPR declaration and the later adoption into a WG draft doesn’t lead to a new declaration. Our tools usually track this correctly, as long as the replaced-by information is correctly updated. (WG chairs: please check that this happens when you adopt documents.)

But in this case I noticed that http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 1 IPR whereas https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does not. But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 does. What gives? Robert, do you know if the tools version does not track through replaced-by? Getting such information properly displayed in all cases might be important, as many people use the tools server to view drafts.

In any case, my question is, I think, not relevant to the question of whether the group properly considered *this* case, because at the time that the document was adopted, it was an individual draft and therefore likely correctly displayed in all tools. The date of IPR declaration was Nov 2012, and the first WG document on this (in PWE3) appeared in December 2012.

Jari

> 
> Thanks,
> Andy
> 
> 
> On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks <[email-masked]> wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 22 Oct 2015 06:46:43 -0400

Jari,

(I removed some of the the cc:s for this reply).

Thanks, that’s exactly the case, the IPR was announced in November 2012,
prior to the PWE3 WG adoption poll.

I think you just uncovered a tools page bug. Looking at the datatracker,
the replaced-by information is correct through the draft’s lifetime, and
the IPR follows all the way through. However, the tools page only shows the
IPR for draft-dong, and not the subsequent drafts. I seem to recall this
having worked properly in the past, perhaps it’s an unintended side-effect
of the recent datatracker upgrades?

Cheers,
Andy

On Thu, Oct 22, 2015 at 6:15 AM, Jari Arkko <[email-masked]> wrote:

> > The IPR declaration is against the original individual draft,
> draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that
> was not represented as an author on the draft, and offered free licencing
> with reciprocity.
>
> > At the time, no concerns were raised by either the authors or from
> anyone in the WG in response to the declaration. This, IMHO, is normal
> operating procedure when IPR declarations are made, especially by
> non-author entities and early in the process. The usual concern is when
> declarations come in late in the process, especially from an author
> company. Neither was the case here, it was still an individual draft. And
> of course, the declaration was clear for all to see during both WG adoption
> and WG LC polls.
>
> I think this is the key. The standing practice at the IETF is that IPR
> gets declared, timely, and the information is used by the participants when
> they decide things like whether they support document adoption (among many
> other factors). I find that there is often no explicit discussion but those
> that care take the information into account, in careful and competent
> manner and through consultation with their colleagues back home etc.
>
> However, I have one question, as I started digging… First, this is one of
> those many cases where an individual draft has an IPR declaration and the
> later adoption into a WG draft doesn’t lead to a new declaration. Our tools
> usually track this correctly, as long as the replaced-by information is
> correctly updated. (WG chairs: please check that this happens when you
> adopt documents.)
>
> But in this case I noticed that
> http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 1
> IPR whereas https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02
> does not. But
> https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 does. What
> gives? Robert, do you know if the tools version does not track through
> replaced-by? Getting such information properly displayed in all cases might
> be important, as many people use the tools server to view drafts.
>
> In any case, my question is, I think, not relevant to the question of
> whether the group properly considered *this* case, because at the time that
> the document was adopted, it was an individual draft and therefore likely
> correctly displayed in all tools. The date of IPR declaration was Nov 2012,
> and the first WG document on this (in PWE3) appeared in December 2012.
>
> Jari
>
> >
> > Thanks,
> > Andy
> >
> >

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 13:34:31 +0100

Robert, Jimmy,

Thanks for the review & discussion.

From my perspective some of the things that Robert raises are very valid
questions. The particular item that I’m perhaps most interested in is the
text in Section 3.2, which seems like explaining what happens in an example,
but it also uses normative language and keywords to say what various entities
should do. Yet, the example is just one example. Is there a need to lift the
keyword statements out of this paragraph and generalise them to make
sure that the specification is about the general case and not about the
example? Alternatively, maybe I misunderstood the purpose of the keyword
statements.

(I also agree with Robert that the document is fairly hard to read. This isn’t
the first document in the IETF to be like that, and I didn’t feel that this
issue is discuss-worthy.)

Jari

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Oct 2015 09:46:59 -0500

On 10/22/15 5:15 AM, Jari Arkko wrote:

<trim/>
> http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 
> 1 IPR whereas 
> https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does 
> not. But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 
> does. What gives? Robert, do you know if the tools version does not 
> track through replaced-by? Getting such information properly displayed 
> in all cases might be important, as many people use the tools server 
> to view drafts.

Yes, the tools servers don't currently follow replaces the same way the 
datatracker does.
Henrik is aware of it, and is working to make them say the same thing.

RjS

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 15:53:15 +0100

> Yes, the tools servers don't currently follow replaces the same way the datatracker does.

Cool, thanks!

Jari

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 23 Oct 2015 07:46:16 +0000

Hi Jari, 

Thanks a lot for your review and comments.

As said in my reply to Robert, we will separate the specification and the examples.

Also we would try to improve its readability.

Best regards,
Jie

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, October 22, 2015 8:35 PM
> To: Robert Sparks
> Cc: Dongjie (Jimmy); General Area Review Team; [email-masked];
> Subject: Re: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02
> 
> Robert, Jimmy,
> 
> questions. The particular item that I'm perhaps most interested in is the text in
> Section 3.2, which seems like explaining what happens in an example, but it also
> uses normative language and keywords to say what various entities should do.
> Yet, the example is just one example. Is there a need to lift the keyword
> statements out of this paragraph and generalise them to make sure that the
> specification is about the general case and not about the example? Alternatively,
> maybe I misunderstood the purpose of the keyword statements.
> 
> (I also agree with Robert that the document is fairly hard to read. This isn't the
> first document in the IETF to be like that, and I didn't feel that this issue is
> discuss-worthy.)
> 
> Jari