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:
Robert wrote: > 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. 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 <rjspa...@nostrum.com> wrote: > 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." > > ----- > > 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. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
