--On Tuesday, December 22, 2020 21:49 +0000 john heasley <heas@xxxxxxxxxxxxx> wrote: > Wed, Dec 23, 2020 at 08:44:29AM +1300, Brian E Carpenter: >> > If IPR arises after adoption, the draft should >> > automatically return to an adoption call - but much better >> > to simply not allow it. >> >> Firstly, an adoption call is not a formal or required part of >> the IETF process, it is simply a pragmatic step that some WGs >> use (see RFC7221). So we can't have a requirement to repeat a >> step that isn't required in the first place. > > so discard it, forcing them to start from the beginning. > >> Secondly, we have no power to "disallow" late IPR disclosures. > > make it painful. > >> Sometimes people only discover patents late, and do us a >> favour by notifying them. That particularly applies to third >> party disclosures, or patents elsewhere in a large company**. > >> Sometimes people are legally or contractually unable to make >> disclosures until their employer decides to publish an >> application. > > That is not a valid excuse. They know about it, therefore > should not submit the draft until they decide what they're > doing. > >> I'm sure there are other cases too, such as when an IETF Last >> Call triggers a disclosure by somebody who has been unaware >> of the draft until then. > > back to the beginning of the process. John, The "if you fail our test, start over" approach seems to ignore two things. First, and most important, our IPR policies represent an attempt to balance maximizing the disclosures the IETF gets (and gets in a timely fashion) with maximizing participation and bringing work here. If we make the requirements too onerous or make those who are developing work that might have IPR implications feel that we are setting traps for them, their reasonable and logical response is to take the work somewhere other than the IETF or to not try to standardize it at all. In very few cases will either of those options help the Internet, much less the IETF. Second, it is typically the case (or at least we hope and pretend it is) that, once a specification has gone through a few iterations, it represents the work of multiple people, not just the original author(s). Even if it were reasonable to punish the authors by doing a reset on the spec if they generated a late disclosure, it isn't fair to those who have contributed in good faith. And, if the late disclosure comes from someone other than the authors, punishing them may not be fair either. And, as with the above, the perception of "not fair" can lead to people and work going elsewhere. And that is, at least IMO, why our usual practice is that, when a disclosure shows up that could interact with specification under development, someone (typically a WG Chair if a WG is involved) points it out and asks whether the IPR claim justifies changes in the spec or a change of direction. It isn't clear to me that we can do better than that... and it is clear that we could figure out worse ways to deal with the problem, maybe of which would involve rules that are intended to be "one size fits all". john
