Subject: Meeting minutes - 2nd version

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Dec 2006 01:04:30 +0100

Here are the minutes in ASCIIfied form, with some information from the 
on-screen notes interspersed.

Comments still welcome.

             Harald

Minutes of the IPR WG meeting, San Diego, 67th IETF, Monday, November 7, 
2006

Agenda:
15:20 Administrivia — Agenda bashing, etc. – 5 min
15:25 Outbound Rights — What rights the IETF grants others – 75 min
16:40 Milestones and Goals — What we're going to do and when, including a 
replacement for 3978 – 35 min
17:15 Wrapup, next steps
17:20 End

1: Administrivia — Agenda bashing, etc.
- No agenda bashing
- Elwyn Davies to take notes
- Scott Bradner (SOB) does jabber

2: Outbound Rights — What rights the IETF grants others
Harald Alvestrand (HA) presents:
- Considering draft-ietf-ipr-outbound-rights-01
Chairs believe this represent consensus that group can agree on

Asking for issues to be raised against the documents.

Big Issues:

=-cite all, translate, all change code ? rough consensus?
John Klensin (JK): unless we get it right have to retune every few months
Joel Halpern (JH): Not including legalese - so clarify what is the problem?
JK: Doesn't believe we have lasting stable consensus about what we are 
looking for.. is it the
same as we were looking for a few years ago
Issue is stability of specification - we have shown that we can't get it 
right
Expanding rights requires right to do so.. ? back to authors

Scott Bradner (SB) (original issue): Change code is a bit terse
HA: see draft for specific text
Ted Hardie (TH): section 5.5: Attempts to move legal drafting off to 
somebody else but makes it
difficult for legal drafters. Things about copyright are not very clear. 
Problems in this
section are really about inbound rather than outbound… if inbound has 
restrictions then
may make it difficult to get to what we want on outbound.. Can we punt to 
inbound side?
Maybe say that if inbound is unencumbered then straightforward. For 
encumbered punt to
wg that is putting forward the code
JH: View when writing draft that all code must be able to be used according 
to our
rules… didn't see a way to avoid this because it would involve looking at 
every individual
case. Joel though this was consensus.
TH: View that this the consensus but was not the effect of the text as 
written. Better if
Joel put what he just said into a new version of s5.5. Need to get rid of 
inbound license
issues. Ought to be clear that just by looking at (new) rfc can apply ietf 
rights .. but there
might be additional rights.
SOB: Agree with TH but need to be clear that it applies to new RFCs and not 
those that
have 'no derivative rights' restriction.
BC: Should we remove all material relevant to independent submissions in 
the draft? Is in
the purview of the wg to constrain what should apply to independent 
submissions?
JH: Doc uses IETF contributions very carefully.. claims that this sidesteps 
the problem

Brian Carpenter (BC): Missed this but are we declaring out of scope all 
discussions of matters relating to independent submissions?
JK: If this replaces 3978, need to be consistent about saying 
something/nothing about
independent submissions. WG has to make its mind up about whether it is 
touching
independent submissions.
HA: Is this all issues?
Extra issue: How do we handle old rfcs?

Big issues list, as summarized on slide:

Cite all, translate all, change code
Concern: Stability of specification?
Addressing stability: Need language stating how expanded rights can be 
granted (process)
Copyright issue

HA (Consensus call): Take consensus on this doc as a set of rights we would 
like to grant (12 for, none against, 1 confused)
SOB: Need clear definition of what is code
HA: How do we deal with concern of stability of specification
HA: Possible to move this over to the inbound side
JK: Could put text in to give authority to grant more (expanded) rights
JH: How would we reach a consensus on what sort of rights we could grant
JK: Problems discussed on mailing list include lots of issues with special 
cases.. tends to
take an essentially infinite amount of time to reach a consensus
SOB: Remember nobody can grant more rights than we have received
HA: No it is supposed to be expanded up to what we received
SOB and lawyer have been trying to write an RFC for 3978bis. involves 
allowing small
changes to boilerplate for special cases.
SOB: wanted to make clear that IETF Trust are constrained to grant only up 
to the
available inbound rights.
HA: The WG does not wish the IETF to ask for copyright transfer (but this 
is an inbound
issue)
TH: His belief is that the IETF Trust is the rights manager. Are we trying 
to figure out who
should allowed to give them permission to grant exceptions
JH: Somebody needs to be able to allow the trust to make an exception in a 
particular case.
We need to be able either to allow the trust to be able to this of their 
own bat or decide who
can give permission. Suggest trust be able do exceptions but blanket rights 
need an IETF
consensus process
Jonne Soininen (JS): Speaking as IETF Trustee - need a clear statement of 
how the trust should be instructed. Need an 'authority' behind it. Need a 
process
Steve Bellovin: Personal take would be IESG's request
JS: personally agrees with it
HA: Consensus Call: Suggested text: per slide consensus:
- Special cases: IETF Trust (as requested by the IESG or IAB)
- Blanket rights: IETF consensus process
- Yes: 14, No: 0, Don't know: 0

TH: Agrees but one point: items not approved by IESG? Eg IAB .. should we 
consider
e.g., IAB to grant exceptions for IAB docs
BC: IAB could probably grant rights for IRTF as they have authority.. need 
to look at IRTF
doc processing doc.. could be delegated to IRTF steering group
BillFenner: Could say special rights from document stream owner
JH: Just say IESG or IAB
SB: What about RFC editor for independent submissions?
Various: This is out of scope.

HA: move on to small issues.. is JH ready to write language? JH thinks he is
HA: Code vs non-code? Adequate definition?
BC: Suggestion: Chunks of code should be explicitly marked. Only way to 
document this
easily
SOB: Considers putting in signposts will not hold up over time.. JH has put 
in a list in draft
JH: Considers list to be exemplary.. thinks there should be explicit 
labeling but doesn't like
it.
HA: suggested 'some obvious cases': Should avoid signposts but need to have 
some way to
decide.
BC: Could do a registry of formats deemed to be code.. alternative to 
signposts
SB: Thinks that first sentence of 5.3 is adequate
JK: Agrees with last point. Isn't keen on registry.. could copy all 'code' 
into a database
BC: If you use 'intended' then you have to say who makes the judgment.
(3 people in favour of rules, 2 in favour of markers)
Stefan Wenger: Why not both in the draft?
JK: Do both as appropriate (use rules by default but can mark if no clear)
TH: Both case: If somebody didn't put something in that matched the rules 
and didn't mark
it then it isn't code.
JH: thinks both s a good thing. Avoids judgment call on borderline cases. 
Only have to
maintain the rules.. can put in code markers (as an author)
Concensus to go with both.

HA: New issue: How to handle "no derivative works" RFCs
SOB: Need to explicitly say that code cannot be extracted from no 
derivative works, maybe.
BC: Puzzled. Technically they could be AD sponsored, not just independent 
submissions.
TH: Treat no derivative works as equivalent to 'no code' throughout.
JH: Add note to s4 that because of inbound rights .. we don't get any from 
"no derivative
works" docs so can't make any grants of outbound.
HA: this is now an inbound rights issue.
HA: Do we mention independent submissions? (silence) assume therefore 
consensus not
to.

HA: New (small) issue - Section 5.5 may be too specific for stating for 
consensus of IETF
JH: Allowing people to put in extra notices doesn't reflect IETF desires.. 
can't punt on this
one
TH: If a wg has allowed code that would not allow the outbound rights we 
want.. then the
wg should have done exception processing.
HA: suggest new words: We wish to make it clear that the user of an IETF 
document
have the rights they expect (what we want to give).
Leave out stuff about extra copyrights.
BC: can't do this because of 3978.. this isn't just inbound rights so we 
can't just punt on it
What is the minimum we can say to avoid getting into a conundrum later. We 
probaly
need to say that docs should not contain any text that distorts the 
outbound rights (to code)
we wish to grant.
SOB: 5.5 is not specific to code. Otherwise good. May need to have some 
statements in
inbound rights because this is a denial of right to put in some statements.
JK: maybe s/distorts/defeat or restricts/
JK: Some of this may be handled by putting in text to stop something 
overriding our
intentions

Slide text:

There have been contexts where the material in an IETF contribution is also 
available under other license terms.  The IETF wishes to be able to include 
content which is available under such licenses.  It is desirable to 
indicate in the IETF contribution that other licenses are available. 
However, the IETF does not wish to have IETF Contributions contain 
additional copyright notices and licenses, as that introduces a number of 
additional difficulties.  Providing the correct legal approach to such 
indications is left to the IASA, as all legal language is.

HA: how to handle old RFCs?
BC: has an idea.. put in a statement sent to trust to do the best they can 
do
HA: .. to get equivalent rights to the best extent that they can
SOB: 1 Draft needs an explicit effective date
2. Several classes - ancient history up to 2026, middle - need to ask 
authors, new ones
controlled by new doc. Trust needs to negotiate with ISI about ancient 
history as a best
effort.
JK: Jon Postel was of the opinion generally that reproducing old docs in 
toto was not a
problem but anything else is a gray area.
JS: Trust is trying its best already. Need not say it!
BC: Ought to say it anyway although it's a no-op
HA: Believes we have covered all issues.. JH instructed to make new version

New agenda topic: Milestones and Goals — What we're going to do and when, 
including a replacement for 3978

HA: Two sections: philosophy (written by SOB), boilerplate (written by 
Jorge Contreras)
Intention is that IETF ought to be able to approve minor changes consistent 
with
philosophical goals to handle special cases and minor errors.
JK: How is minor defined? Would decisions be appealable?
SB: If it is not obvious, its not minor.. but this is tricky
BC: How do we engineer appeals mechanism?
HA: How do we maintain 'no derivative works' RFCs
We permit publication of such docs but doesn't understand what that means!
SOB: Original aims: Allows company to publish how a thing works but not 
build standards
etc out of it. The intent was that pieces could be copied
JH: "No derivative" works are effectively not really IETF contributions.. 
so maybe
disallow them.
SOB: Disagree: Some docs (eg NFS) are background or starting point 
material. You can't
alter that but you could alter it and use it as you will. Not a good idea 
to stop this.
TH: Believes that if somebody came to IETF with some material that they 
publish as a no
derivative works doc but then go on and modify it - this is a good thing. 
Expects that this
will be rare. If something comes along that would eventually break outbound 
rights then
need to start exception process asap.
JH: Can't see how it will work?
JK: What JH said come close to line between copyright and concepts that the 
words
describe.
JK: Note they are external docs.. might be able to get the lawyers to draft 
something that
distinguishes between docs from external sources and documents built within 
the IETF
process.
HA: Consensus call: The function of providing publication of outside 
documents with a NDW clause is useful, and should continue.
Yes: 9, No: 1, Don't know: 0

BC: Why did Barry vote no?
Barry Leiba: Different view of how IETF should handle IPR and how his 
company should
handle these issues. Not very certain.
HA: If you can express it better, please send to mailing list.
HA: (More timeline.)
- December: Revised –outbound, WG Last Call
- January: Resolve issues, -outbound to IESG
- January: 1st draft of 3978bis
- March: Discuss 3978bis in Prague
- April: WG Last Call on 3978bis
- May: Resolve issues, 3978bis to IESG
- June: Close WG
- No need to meet in Chicago??????
Thank you all for coming, see you in Prague.

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg