Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

[Jari Arkko <[e-mail]>]

On 19 Jan 2017, at 17:09, Russ Housley <[e-mail]> wrote:

> Jari:
> 
>> * Russ Housley’s concern re: “IETF sanctioned” was resolved
>> per Brian’s and Harald's suggestions (Brian's mail on March 26).
> 
> I do not think that the change here is sufficient based on my reading of the thread that followed my comments.  I think my comment is addressed, but not all of the points that are made in that thread.  In particular, the output of the design team is the contribution, not every alternative that is discarded before being written down or presented.  Also, the reference to BCP 25 seems to scope this the design teams in working groups, not all design teams.

Hmm. I think I agree with regards to BCP 25 (do you have alternative
references or words?)

But I re-read the thread this morning, and a number of important
points were made along the way in the discussion. However, I
viewed some of those points as possible alternative ways to
tackle the original concerns, and there was a lot of back-and-
forth regarding them. For instance, John Klensin argued
that an output would necessarily be a contribution anyway.

The difficulty here is of course that we want to enable what
John and Brian and Sam talked about, that there are
gatherings that we want to enable that are not yet
IETF design teams but whose discussion may eventually
lead to some IETF design team or submission. Many of
my discussions with other industry people are that way:
“do you have this problem” or “how can we work together
to connect our gear”… and only some fraction of the time
these result in ideas for standards and IETF standards in
particular.

Ultimately, you have to draw a line somewhere. “This
is where IETF work starts and you are now under the
IETF IPR rules”.

Harald’s email from spring I thought outlined this in
practise very nicely:

If the documents clearly define the term "design team" as teams that are
created by a decision in an IETF process, I have very few problem
extending "IETF contribution" to contributions to the design team.

If (as I've sometimes seen) everyone who meets to hash out an idea wants
to call themselves + their friends is a "design team", then I see a
problem with the extension.

The lunchtime "bar BOF" would be a nice test case - arranged by WG
chairs over the WG (or IETF non-WG) mailing list, it would be an IETF
activity with IETF contribution; arranged between friends on the way out
of the preceding WG meeting, it would (I think) not be.

So where does all this leave us?

I’d argue that the output/non-output distinction isn’t the crucial
one. Outputs from design teams that go to the IETF are in any
case covered. But how do we want to cover the design team
discussion (incl. any silly alternatives), without impacting
my ability to have a discussion with my customer for instance?

I think I’d be happy if w extended the BCP 25 reference to
some other text that covers also non-WG design teams, for
instance teams that call themselves IETF design teams (whether
“sanctioned" or not).

But your suggestions are welcome.

>> * Russ Housley’s concern re: changes from the previous RFC
>> section is valid (Russ’s mail on March 25), and we will be acting
>> on that as explained above.
> 
> I look forward to seeing this text.  Since it does not exist yet, I think the IETF Last Call should be extended for two weeks beyond the availability of this text.

We are working on it. My hope is that we’ll get it done soon enough for
there to be more than two weeks left of the last call, but if not we will
certainly extend the Last Call.

Jari