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 <jari.ar...@piuha.net> wrote: > 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 > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
