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

[Jari Arkko <jari.arkko@xxxxxxxxx>]

On 19 Jan 2017, at 17:09, Russ Housley <housley@xxxxxxxxxxxx> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail