headers
Harald Tveit Alvestrand | 10 Jun 01:34
Picon

IESG evaluation of our documents, current version

I enclose here the current evaluation record of the IESG for the two IPR 
documents.

As you can see, Cullen Jennings has chosen to raise a DISCUSS comment; I 
will respond to his points in a later message.

                  Harald

To: Internet Engineering Steering Group <iesg <at> ietf.org>
From: IESG Secretary <iesg-secretary <at> ietf.org>
Reply-To: IESG Secretary <iesg-secretary <at> ietf.org>
Subject: Evaluation: draft-ietf-ipr-3978-incoming-09.txt to BCP
         draft-ietf-ipr-outbound-rights-06.txt to Informational

--------

Evaluation for draft-ietf-ipr-3978-incoming-09.txt  draft-ietf-ipr-outbound-rights-06.txt can be
found at
https://datatracker.ietf.org/idtracker/ballot/2731/ 

Last Call to expire on: 2008-04-07

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Jari Arkko           [ X ]     [   ]     [   ]     [   ]
Ron Bonica           [   ]     [ X ]     [   ]     [   ]
Ross Callon          [   ]     [ X ]     [   ]     [   ]
Lisa Dusseault       [   ]     [ X ]     [   ]     [   ]
Lars Eggert          [ X ]     [   ]     [ . ]     [   ]
(Continue reading)

Permalink | Reply | 17 comments |
headers
Harald Tveit Alvestrand | 12 Jun 06:04
Picon

Re: IESG evaluation of our documents, current version

Cullen,

I'll attempt to comment on your points below - just a few words first about 
the format.

I'm trying to figure out, for each of the comments of your DISCUSS, whether 
it falls into one or the other case of:

- There's unclear language in the document, and it needs improvement before 
approval
- You have an opinion that is different from the consensus of the WG

On reviewing the text below, I think the "difference of opinion" is 
contained in your "comments" section, while the "DISCUSS" section is a 
matter of clarity of writing, and a couple of errors in the text.

If you (and the WG, and the rest of the IESG) agree with my understanding 
on these points, I'll ask the editors to prepare revised versions of the 
drafts incorporating the required changes. We may need to discuss the 
specific form of the changes some more.

--On Tuesday, June 10, 2008 01:34:12 AM +0200 Harald Tveit Alvestrand 
<harald <at> alvestrand.no> wrote:

> DISCUSSES AND COMMENTS:
> ======================
> Jari Arkko:
>
> Comment [2008-05-21]:
> The legend URL is currently non-existent. It should be created when the
(Continue reading)

Permalink | Reply | 16 comments |
headers
Frank Ellermann | 12 Jun 08:04
Picon
Picon

Re: IESG evaluation of our documents, current version

Harald Tveit Alvestrand wrote:

>> OLD: k. "RFC": the basic publication series for the IETF.
>> NEW: k. "RFC": the publication series used by the IETF among others.

Makes sense (see below)

---
> The "IETF Standards Process" is defined in section 1 (term g), as 
> encompassing what I think is essentially all the IETF's work. It's 
> important to have a consistent terminology, even when it's not
> immediately the obvious one.

1(g) is rather convoluted with a backwards reference to 1(a), which
are the contributions, boiling down to various cases of "note well".

> - Replace "IETF Standards Process" with "IETF Process" throughout
> both documents

That's clearer.

---
> <http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf>
> - I assume that this needs to be pointed to in order to show that the
> Trust is the repository of all IETF IPR - but I'm not sure why the 
> pointer needs to exist either, and would like commentary on that from
> the WG.

RFC 4748 has a link to the Trust PDF, maybe the draft tries to preserve
this.  RFC 4371 also has this link, the draft has a normative reference
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 12 Jun 23:43
Picon

Re: IESG evaluation of our documents, current version

On 2008-06-12 16:04, Harald Tveit Alvestrand wrote:
...
>> Section 4 limits rights assignment to "IETF Standards Process".  This may
>> be OK but I think "IETF Processes" would be better here.  Not all of our
>> work is creating standards (some of it is process-changing work) but I
>> believe the rights assignment applies to drafts on process changes.  Like
>> this one.
> 
> The "IETF Standards Process" is defined in section 1 (term g), as 
> encompassing what I think is essentially all the IETF's work. It's 
> important to have a consistent terminology, even when it's not immediately 
> the obvious one.
> This term has been used a lot - and not consistently across documents; the 
> initial usage in RFC 1310 seems to be focused on "the making of standards", 
> so one could argue that the usage in this draft is not the same as that 
> earlier usage, but this definition is unchanged from RFC 3667 (2004).
> 
> So I see two alternatives:
> 
> - Keep the document as it is
> - Replace "IETF Standards Process" with "IETF Process" throughout both 
> documents
> 
> I'd like to hear commentary from both the WG and the IESG on what 
> terminology they think best. As chair, I'll just have to insist on 
> consistent use of the term.

I think we should follow counsel's advice on this point. It will
only really matter if a dispute ends up in court and if the document
concerned spent some or all of its life *not* on the standards
(Continue reading)

Permalink | Reply | 2 comments |
headers
TSG | 13 Jun 00:16
Picon
Favicon

Re: IESG evaluation of our documents, current version

Brian

>>
>> I'd like to hear commentary from both the WG and the IESG on what
>> terminology they think best. As chair, I'll just have to insist on
>> consistent use of the term.
>
> I think we should follow counsel's advice on this point. It will
> only really matter if a dispute ends up in court and if the document
> concerned spent some or all of its life *not* on the standards
> track. I also think that consistency with RFC 3979, which defines
> and mainly uses "IETF Standards Process" (but uses "IETF process"
> twice), is desirable.

the issue is not whether a dispute ends up in Court, but rather when the
first one winds up in Court and what the liability profile of the IETF is
then.

Todd Glassey

>
> ...
>> The Trust Agreement is the document at
>> <http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf> -
>> I
>> assume that this needs to be pointed to in order to show that the Trust
>> is
>> the repository of all IETF IPR - but I'm not sure why the pointer needs
>> to
>> exist either, and would like commentary on that from the WG.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Contreras, Jorge | 19 Jun 00:48
Favicon

RE: IESG evaluation of our documents, current version


> I think we should follow counsel's advice on this point. It will
> only really matter if a dispute ends up in court and if the document
> concerned spent some or all of its life *not* on the standards
> track. I also think that consistency with RFC 3979, which defines
> and mainly uses "IETF Standards Process" (but uses "IETF process"
> twice), is desirable.

Either "IETF Processes" or "IETF Standards Process" would be fine.  
The term will be defined formally, so the choice of labels should be
 whatever makes the most sense.  Note that "IETF Standards Process" 
has been used previously in RFC 3978, so there could be some benefit
in the historical consistency.

> 
> ...
> > The Trust Agreement is the document at 
> > 
> <http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15
-05.pdf> - I 
> > assume that this needs to be pointed to in order to show 
> that the Trust is 
> > the repository of all IETF IPR - but I'm not sure why the 
> pointer needs to 
> > exist either, and would like commentary on that from the WG.
> 
> I would think that a clear pointer to the legal entity is useful,
> to convince an outside reader that there really is such an entity.
> But again, I suggest we do exactly what counsel advises on this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
TSG | 20 Jun 00:34
Picon
Favicon

IP Discolsure #201

FYI -
I changed (updated) the IPR #201 disclosure today to accurately reflect the 
licensing terms (as in "this is only available under commercial terms and NO 
GRANT of RIGHTS to the IETF is made"), and to further note the issuance 
dates of the US patent.

Thanks,
Todd Glassey
Permalink | Reply | 3 comments |
headers
TSG | 23 Jun 18:02
Picon
Favicon

Flaw in NoteWell

If an individual files a IPR notice and in that notice says "Hey Bozo's - 
The IETF MAY NOT USE THIS IP" and the IETF intentionally starts a WG to 
standardize a derivative of that IP, then the IETF and its member's and 
especially their sponsors are directly liable for damage that the public 
vetting of that IP does to the original holder's rights.

They also have committed a conspiracy by an electronic medium to steal IP 
belonging to another and to make it public property by relicensing it 
without release from its owners to 'the world'... This causes clear and 
intentional damage to the IP holder and as such makes all of the parties 
involved co-defendant's in the destruction of that IP...

This is a very serious matter since also under that same submission new 
commentary about that same IP would not become the property of the IETF if 
NoteWell is used to cover it since the IETF would be intentionally violating 
the IP Rights of the party holding that IP, as the IETF did to McNeil and 
myself by allowing of the formation of the GeoPriv WG in direct violation of 
IPR Notice #201, an act which has caused permanent damage to McNeil and 
myself.

Have a nice day -

TS Glassey
Permalink | Reply | 0 comments |
headers
TSG | 23 Jun 20:30
Picon
Favicon

What happens to IETF efforts when the IPR-Filing says "NO The IETF cannot have this IP"?

I have a question for the IPR WG -

'what happens to a WG which is founded after a IPR Notice about the 
ownership of that IP is formally filed with the IETF and that IPR Notice 
says "NO, THE IETF CANNOT HAVE THIS IP"'?

The question is simple - who owns all of the IP in the GeoPRIV WG. I claim I 
and McNeil do based on the filing of IPR Notice 201. And based on that claim 
now we actually have something VERY important to litigate if we cannot work 
this out.

Todd Glassey
Permalink | Reply | 0 comments |
headers
Contreras, Jorge | 24 Jun 04:02
Favicon

RE: IP Discolsure #201

Dear Todd,

Thank you for updating IPR Disclosure 201.

Under Section 6.4.1 of RFC 3979, IPR Disclosures must list the specific
IETF Document(s) or activity affected.  Section IV of your IPR
Disclosure does not appear to make reference to a specific IETF Document
or activity.

I would also like to draw your attention to Section 4(C) of RFC 3979,
which states that "The IESG disclaims any responsibility for ...
evaluating the applicability of any IPR, disclosed or otherwise, to any
IETF technology, specification or standard..."

Best regards,
Jorge Contreras

> -----Original Message-----
> From: ipr-wg-bounces <at> ietf.org 
> [mailto:ipr-wg-bounces <at> ietf.org] On Behalf Of TSG
> Sent: Thursday, June 19, 2008 6:35 PM
> To: ipr-wg <at> ietf.org
> Subject: IP Discolsure #201
> 
> FYI -
> I changed (updated) the IPR #201 disclosure today to 
> accurately reflect the 
> licensing terms (as in "this is only available under 
> commercial terms and NO 
> GRANT of RIGHTS to the IETF is made"), and to further note
(Continue reading)

Permalink | Reply | 2 comments |

Gmane