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

["Andrew G. Malis" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/gen-art
>
>