Subject: Agenda sketch, IPR WG meeting in Prague

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Mar 2007 14:33:01 +0100

This is a proposed agenda. Suggestions for improvement are welcome.

Date: MONDAY, March 19, 2007
Time: 1300-1500 Afternoon Session I
Place: Congress I

Agenda:

1300: Agenda bashing, selection of scribe
1305: Outgoing rights draft
  - Verification that no issues have been raised
  - Hum for approval to send to the IESG
  Draft: draft-ietf-ipr-outbound-rights-02

1315: Incoming rights draft
  - Introduction: Sections 1, 2 and 7
    - Do they say the right thing?
    - Are they sufficiently clear?
  - Legal language: Sections 3-6, relevant definitions from 1
    - While we're waiting for Jorge's proposed text: comments?
    - Do we depend on "Note Well", on boilerplate, or both?
  - Rechecking consensus from Montreal: Do we need the legal text
    to be in this document?
    - As "initial version, to be modified by the Trust"?
    - As "this is the boilerplate, never modify it unless you
      have to"?
  Draft: draft-ietf-ipr-3978-incoming-00

1445: Summing up, next steps
1500: Close of meeting

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Mar 2007 15:24:37 +0100

>  Draft: draft-ietf-ipr-outbound-rights-02

How about holding a WGLC on the document?  I interpreted your call for
issues to be about what to discuss in Prague, and I don't have a
strong opinion since I won't be there.

I don't believe the document is ready for the IESG yet.  There was a
long discussion with discussion on -02:

http://thread.gmane.org/gmane.ietf.ipr/4430/focus=4432

None of those comments have been incorporated into the document.

I believe it is important that we understand what problem we are
attempting to solve here.  Unless the problem is made clear, I don't
see how the IASA would be able to get the legal text right.  I don't
believe there has been sufficient discussion to build a wide
understanding of the problems caused by the current rules.  The start
of such discussions were cut short when I tried to bring it up in
Vancouver.  To illustrate, outgoing-02 says:

3.1.  Specific Issues

   There are a number of specific concerns that have been raised over
   time, which this document acknowledges and addresses.

What concerns are these?  I suggest that the document contains a list
of specific concerns that have been acknowledged.

Thanks,
Simon

---

From: "Joel Halpern" <[email-masked]>
Date: Fri, 09 Mar 2007 07:22:20 -0700

As I said earlier on the list, section 3.1 is currently 
scheduled to become a single issue, which I will move to 
the appropriate place for that single issue.  I am happy 
to have a section on Specific issues, but since I don't 
have text for it, I was planning to delete it.

Yours,
Joel M. Halpern

On Fri, 09 Mar 2007 15:24:37 +0100
  Simon Josefsson <[email-masked]> wrote:
> 
> To illustrate, outgoing-02 says:
> 
> 3.1.  Specific Issues
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Mar 2007 16:02:20 +0100

> None of those comments have been incorporated into the document.
Right. The document was emitted on Jan 22, your comments were made on 
Jan 24.
Joel wanted to hold off on a nits-fixing version of the document until 
he knew whether or not there were substantive issues that needed changing.

If you believe there are such substantive issues, please raise them 
using ISSUE: messages.

Full disclosure: My two calls for issues to be raised and one agenda 
scheduling an approval without discussion ARE intended also to point out 
to people that unless they read the document, AND raise the issues they 
see using the "ISSUE:" protocol, they have only themselves to thank if 
they get ignored.

(I assume the typos don't need issue numbers.)

                      Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Mar 2007 16:09:12 +0100

Simon,

I don't fully understand your comment. This topic has been
the main topic in the WG for a very long time, has been
discussed in several meetings, issues have been tracked
and resolved, and now we have a document edited on behalf
of the WG under specific directions from the WG Chairs, which is
in its third version. It's quite likely that some of your
comments have not been dealt with in the way you personally
would prefer; that's the point of rough consensus, after all.
I'm sure if I went back through the record, I'd find the same
for some of my comments.

WGLC is not a formal requirement by the way, though it is
very common practice. The essential point is for the chairs
to be sure that all comments have been heard and
considered (which may include not implementing them, if
there is no consensus to do so). WGLC is a mechanism for
that.

As always, a positive hum in the meeting must be confirmed
on the mailing list. That will happen whether it is named
as a WGLC or otherwise.

      Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Mar 2007 16:13:11 +0100

One more comment:

"I would like to see further discussion" is NOT an issue.

Issues are of the type "I think this is wrong, and should be changed".

                    Harald

Harald Alvestrand wrote:
> scheduling an approval without discussion ARE intended also to point 
> out to people that unless they read the document, AND raise the issues 
> they see using the "ISSUE:" protocol, they have only themselves to 
> thank if they get ignored.
>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Mar 2007 16:29:11 +0100

> see using the "ISSUE:" protocol, they have only themselves to thank if

Sigh, I've now tagged the paradox as ISSUE:

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 11 Mar 2007 14:00:20 +0100

Thank you. But could you also point to the specific section where you see 
the paradox?

I'm assuming that you're referring to your note of January 29, with the 
subject line "Re: Restriction on the right to modify", since that's the 
only recent message where the word "paradox" occurs, but I'd much prefer to 
have in your own words where you see the issue, and what you see the issue 
as being, as part of the issue raised.

Note that the document that goes to Last Call should, ideally, be the same 
words as the document that is published as an RFC, so if the finished RFC 
is going to say anything about itself, the draft needs to say so too, and 
put the disclaimers in the "Status of this memo" section.

(It's a perfectly consistent position to say that the finished document 
shoudn't talk about it, but I don't see it as consistent to say that the 
RFC should but the I-D shouldn't.)

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Mar 2007 16:06:09 +0100

Harald Tveit Alvestrand wrote:

> could you also point to the specific section where you see the paradox?

Yes, see <http://permalink.gmane.org/gmane.ietf.ipr/4438> and your
reply in <http://permalink.gmane.org/gmane.ietf.ipr/4450>, there are
five occurences of "rough consensus" in the draft, and one occurence
of "no consensus".

> I'm assuming that you're referring to your note of January 29

Yes, in reply to your article (ipr:4450 in GMaNe's NNTP counting).

> I'd much prefer to have in your own words where you see the issue,
> and what you see the issue as being, as part of the issue raised.

"Consensus" is IMO a magic word.  It's used by Chairs or shepherds
when they send a publication request + questionnaire to the IESG
before an IETF Last Call, or similar occasions (as WG consensus),
and it's implied (as IETF consensus) by an IESG approval.

> Note that the document that goes to Last Call should, ideally, be
> the same words as the document that is published as an RFC

Yes, and authors don't know what the outcome of the IETF Last Call
will be, they better don't talk or speculate about it.  They also
say "intended status" and "memo" (or similar, but not "standard").

I also don't see the point for speculations about possible reasons
for the alleged rough consensus like "bad idea" or "too complex".

A list of examples (RFCs) which won't be possible anymore under
the proposed rules would be more instructive for the Last Call.

A Last Call trying to figure out if its prefab outcome in the I-D
is correct is just too odd.  What if folks consider "share alike"
as good and simple idea in the Last Call, but not good and simple
enough ?  The IETF consensus might be not "rough", not "bad idea",
and not "too complex", but "one size fits all is KISS, and giving
authors a choice is a waste of time".  I-Ds are no crystal ball.

> It's a perfectly consistent position to say that the finished
> document shoudn't talk about it, but I don't see it as consistent
> to say that the RFC should but the I-D shouldn't.

RFCs contain IESG notes, the result of RFC editor notes, or AUTH48
fixes, where that's not necessarily a paradox anymore.  At some
point in time "RFC XXXX" is also replaced by the real number, and
the intended status is replaced by the real status.  I don't see
this as inconsistent.

Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Mar 2007 11:17:08 -0400

With regard to this specific question, the reason for the 
descriptions is that I (and many others) have frequently found it 
very helpful when RFCs explain the reasons why working groups came to 
specific conclusions.  Particularly when that conclusion is to NOT go 
down a specific path.  If the WG thinks the description is wrong, or 
does not want it, I will of course remove it.

Yours,
Joel M. Halpern

---

From: Scott W Brim <[email-masked]>
Date: Sun, 11 Mar 2007 11:24:29 -0400

On 03/11/2007 11:17 AM, Joel M. Halpern wrote:
> With regard to this specific question, the reason for the descriptions
> is that I (and many others) have frequently found it very helpful when
> RFCs explain the reasons why working groups came to specific
> conclusions.  Particularly when that conclusion is to NOT go down a
> specific path.  If the WG thinks the description is wrong, or does not
> want it, I will of course remove it.

I'm strongly in favor of documenting history, for institutional
memory, although that information might be in an appendix.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Mar 2007 16:36:59 +0100

> If you believe there are such substantive issues, please raise them

Simon proposed to add a note about appeals (against substantial
modifications of the legalese / boilerplate), and I think we can
recyclye RFC 4693 chapter 2.2 paragraph 5 for this purpose:

| A decision by any other body than the IESG to approve an ION can
| be appealed to the IESG, in which case the IESG can nullify the
| approval.  A decision of the IESG can be appealed using the common
| IETF appeals procedure, except that an IESG decision to nullify an
| IAB decision to approve an ION cannot be appealed to the IAB.

Replacing "any other body" by "IASA" and removing the possibility of
IESG decisions I get something in the direction of:

| Decisions of the IASA how to implement this RFC, and future
| modifications of these decisions, can be appealed to the IESG, in
| which case the IESG can reject these decisions.  As specified in
| [BCP 9] IESG decisions can be appealed to the IAB.

Something like that could be added at the end of chapter 1, maybe
there are better places to add it:  How about chapter 6 ?

Is the appeal chain stuff (IAB) relevant ?  RFC 4693 apparently 
doesn't have it.  I'd like to be sure that it should work with an
I-D.carpenter-ietf-disputes-NN, and not introduce new special cases.

Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Mar 2007 11:45:33 -0400

I am still not sure I understand your concern.
If I am reading you right, you are objecting to my document the 
consensus of the working group.
Your objection seems (and I may be misunderstanding your words) to be 
based on the assumption that the rough consensus of the working group 
has not been determined yet.  But it has been determined.  The chairs 
have determined the conclusion reached by the group, and directed me 
as to what to document.  This pass is for confirming that 
determination, not reaching it.
As such, I see no contradiction or paradox in documenting the WG 
Rough Consensus in the I-D which will become the RFC.

Yours,
Joel M. Halpern

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Mar 2007 22:39:26 -0400

--On Sunday, 11 March, 2007 11:45 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> If I am reading you right, you are objecting to my document
> the consensus of the working group.
> Your objection seems (and I may be misunderstanding your
> words) to be based on the assumption that the rough consensus
> of the working group has not been determined yet.  But it has
> been determined.  The chairs have determined the conclusion
> reached by the group, and directed me as to what to document.
> This pass is for confirming that determination, not reaching
> it.
> As such, I see no contradiction or paradox in documenting the
> WG Rough Consensus in the I-D which will become the RFC.

Joel,

This is a little different, I think, from Frank's concern (see
below), but while I agree with Scott Brim and others that
recording history is important -- especially with something
whose origins have been as bumpy as this document -- it feels to
me that, if the WG wants separate "inbound" and "outbound" docs
(as has been the declared consensus), we would be lots better
off with three documents:
  -- inbound (just the principles and rules, please)
  -- outbound (just the principles and rules here too)
  -- history, context, and rationale
rather than folding parts of the third into the other two.

Just my opinion, of course.

Frank, while it would not be my preferred style either, if
statements about consensus are going to make it into an RFC,
they need to come from somewhere.  We have often found that
trying to sort such statements out after Last Call, in some
magical process among authors, the IESG, and the RFC Editor,
risks producing statements that surprise the relevant WG.  From
that perspective, I think what Joel has done is quite
reasonable: he has prepared a draft of an RFC for the WG (and
the community) to review.   If one disagrees with any
substantive aspect of it --presumably including disagreeing with
him about whatever consensus he claims exists-- then one should
clearly speak up about that.  But it doesn't seem to me that a
procedural objection to the claims he is making makes much sense
and, unless I misunderstand, that is what you are raising.

best,
     john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2007 17:13:23 +0100

> memory, although that information might be in an appendix.

It's good practice as long as the separation between agreed and
definitive text and rationale is clear to every reader.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2007 17:18:32 +0100

I agree that documenting an appeal chain is always good,
but BCP 101 already documents the appeal chain for
IAD/IAOC decisions. Therefore, I think it would
be wrong to include another (different) procedure here.

    Brian

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 12 Mar 2007 20:47:04 +0100

> definitive text and rationale is clear to every reader.

Okay, I propose text for one "rough consensus" I really care about:

- modification.  While there has been discussion of restricting the
- rights to make such modifications in some way, the rough consensus is
- that such restrictions are likely a bad idea, and are certainly very
- complex to define.
+ modification.
+
+ The Working Group considered proposals where authors could optionally
+ pick more restrictive rights like "share alike" in addition to the
+ "by attribution" specified in section 5.2, but finally decided that
+ one binding version is better.  One of the reasons to reject otional
+ choices was that this could be too complex.

While I'm at it, I don't recall that the 5.2 decision was only a "rough
consensus", how about removing this qualifier ?

- There is rough consensus that it is useful to permit the quoting
- without modification of excerpts from IETF Contributions.  Such
+ It is useful to permit the quoting without modification of excerpts
+ from IETF Contributions.  Such

Frank

---

From: "todd glassey" <[email-masked]>
Date: Mon, 12 Mar 2007 16:49:45 -0700

Brian -
the creation of an ongoing stream of evidence as to what the IETF
did and did not do as part of its 'vetting process' is a key part of any
real standards model, especially in proving from a retrospective view that
nothing unequal or nefarious, or that favored one effort more than another.
The same is of course true of why certain design decisions were made as
well, although from a Design Standpoint, most any technical decisions
can easily be traced. The real issue is in proving a uniform standards
process that makes a level playing field for one and all.

Why this is important to the IETF, is that I am not supposed to trust you or
any of the management of the Standards Board to not hurt my interests, I
shouldn't have to. Nor should anyone else.

Its not that any of the management are not trustworthy, that has nothing to
do with the issue, and that issue is whether the processes and methods of
the IETF force one to trust in the people rather than the process to protect
them and their initiates.

I am strongly in favor of capturing ALL vetting text and discussions and
that these convo's, whether indexed or not, are included in what I called
"An IETF Standard's Portfolio" several years ago...

Todd

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Scott W Brim" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; <[email-masked]>
Sent: Monday, March 12, 2007 9:13 AM
Subject: Re: ISSUE: I-Ds talking about their own consensus are not ready for
Last Call

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 12 Mar 2007 22:14:26 -0400

On Mon, 12 Mar 2007 17:18:32 +0100

> be wrong to include another (different) procedure here.

Strong agreement.  In fact, I'm tempted to label it out of scope.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 13 Mar 2007 23:28:26 +0100

> Strong agreement.  In fact, I'm tempted to label it out of scope.

In that case, a sentence saying "Appeal procedures for IAOC decisions are 
documented in BCP 101" should be sufficient. Pointers are good.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Mar 2007 19:05:36 +0100

Harald Tveit Alvestrand wrote:

> In that case, a sentence saying "Appeal procedures for IAOC decisions
> are documented in BCP 101" should be sufficient. Pointers are good.

Yes, it certainly got me to read RFC 4071 up to chapter 3.  But now
I'm lost, the I-D talks about the _IASA_ to define the legalese, and
RFC 4071 chapter 3 talks about the _IAOC_

Who is actually supposed to figure out what the I-D means, IASA, IAOC,
the IETF Trust, some other entity ?  Does it end up in the hands of the
IAD with a threatening "you're supposed to implement this, a.s.a.p." ?

Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Mar 2007 17:12:54 -0400

As I said to the list, the outgoing rights document will be clarified 
to indicate that the document expresses the IETF preferences to the 
trustees of the IETF trust.
There is a defined relationship between that trusteeship and the IAOC.
Whether you consider the IAOC appeal chain sufficient or not is 
probably up to you.  We certainly can not legally change the 
structure of the trust.
And we specifically do NOT want to have to have a working group 
review each and every small chagne that the trustees determine needs 
to be made.

Yours,
Joel

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Mar 2007 00:29:20 +0100

> There is a defined relationship between that trusteeship and the IAOC.

Yes, found it:  Any IAOC member has the duty to serve as trustee (says
4371), and only IAOC members are "eligible" to be trustees (says the
trust agreement), and that apparently means that if somebody leaves
the IAOC they automatically cease to be a trustee, and if somebody is
a new IAOC member they're asked to confirm in writing to fulfill the
duties of a trustee.

IOW trustees and IAOC are supposed to be the same group of persons,
minus those who refuse to confirm this in writing (but that would be
in violence of RFC 4371, any anyway a strange situation).

> probably up to you.

Harald's proposal with a BCP 101 pointer is fine.  You'd probably also
copy the "trust agreement" reference from RFC 4371, and move the set
of these references (4071, 4371, trust agreement) from "informative"
to "normative".

In theory the trust isn't bound by IAOC decisions, let alone any IAB
or ISOC appeal decisions trying to overrrule the trust.  In practice
it's (supposed to be) the same group as the IAOC, and so they likely
agree with such decisions (if they're compatible with the purpose of
the trust).

> We certainly can not legally change the structure of the trust.

Yes, 7.1 (b) and (e) etc. in the IETF trust agreement should suffice.
Besides the trust can't terminate itself before 2010-07-01.

> review each and every small chagne that the trustees determine
> needs to be made.

Simon's point was about the possibility of appeals, not WG reviews.

I didn't know the fine print in 4071, 4371, and the trust agreement,
if it's not only me maybe your I-D could summarize the relationships
in an informative appendix (?)

Frank

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 15 Mar 2007 10:53:13 +0100

> in an informative appendix (?)

Seconded.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Mar 2007 11:28:15 +0100

>> in an informative appendix (?)

I know this stuff is complicated, but it's bad practice to duplicate
such material, even informatively, since the slightest inconsistency
can lead to confusion.

My hope is that http://www.ietf.org/IESG/content/ions/ion-procdocs.html
will be maintained as a guide to the labyrinth.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Mar 2007 12:03:14 +0100

> will be maintained as a guide to the labyrinth.

That document doesn't mention IASA, IAOC or the Trust in any detail,
so it would need quite some work until it can serve as a useful
reference on this topic.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Mar 2007 12:03:14 +0100

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Mar 2007 13:55:54 +0100

>> will be maintained as a guide to the labyrinth.

Hopefully the maintainer returns to a TXT format usable with rfcmarkup:

With that I'd get direct links to the tools server for something like
RFC 4333 from section 2.9.  The HTML output of xml2rfc offers a link
from 2.9 (administration) to 5.1 (references) for RFC 4333, and from
there a link to ftp://ftp.isi.edu/in-notes/rfc4333.txt, a "dead end".

The tools server would use links staying in its own "hypertext land".

> so it would need quite some work until it can serve as a useful

Chapter 2.1 in 4071 titled "alphabet soup" helped me (well, only after
Harald got me to read BCP 101, and the IETF tools server told me that
BCP 101 consists of RFC 4071 and RFC 4371 at the moment... :-)

With the proposal to add a pointer to BCP 101 about appeal issues all
we still need are IMO _normative_ references to RFC 4071, RFC 4371, and
the IETF trust agreement.

BTW, RFC 4333 doesn't state that candidates are supposed to do critical
things like "confirm in writing" that they're willing to follow the
laws of the Commonwealth of Virginia wrt. the IETF trust.  So maybe a
scenario where the trustees are a proper subset of the IAOC isn't that
unlikely (?)

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 18 Mar 2007 17:13:21 +0100

Hi Frank,

> Hopefully the maintainer returns to a TXT format usable with rfcmarkup:

In cases where the xml file is available, text can be produced with
xml2rfc.  If xml is not available, text2html with some tweaks can
produce something fairly readable.

For a very early cut of assembling something like this, try

   http://www1.tools.ietf.org/html/ion-procdocs

> The tools server would use links staying in its own "hypertext land".

Should work for the above link now, and for all tool servers and ions
shortly.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 18 Mar 2007 18:28:57 +0100

Henrik Levkowetz wrote:
 
> In cases where the xml file is available, text can be
> produced with xml2rfc.
[...]
 
>    http://www1.tools.ietf.org/html/ion-procdocs

That's nice... :-)  I've immediately replaced my old link 
http://tools.ietf.org/html/draft-carpenter-procdoc-roadmap
by your version.  

> Should work for the above link now, and for all tool
> servers and ions shortly.

Great, thanks.  Copied to the tools list for info.

Frank