headers
Marshall Eubanks | 5 Sep 16:22
Picon

Trust decision on new Trust Legal Provisions (TLP) Effective 12 September 2009

Greetings!

This message is to announce that the IETF Trustees have reached  
consensus on
a new version of the Trust Legal Provisions (TLP), to be effective 12  
September, 2009. The
Grace period for old-boilerplate will begin on that date, and last  
through 12 December, 2009.

The new document updating the  Trust Legal Provisions was approved by  
the Trustees after a consideration of "last call" comments in a  
telechat on September 3rd, and is available from

http://trustee.ietf.org/policyandprocedures.html

or directly at

http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf .

Informally, this version has been referred to as "TLP Version 3.0."

The requests for comments for this change were issued on June 23, 2009  
1:32:05 AM EDT and updated July 18, 2009 12:55:41 PM EDT, in messages  
entitled

Proposed Revisions to the IETF Trust Legal Provisions (TLP)

The Trustees would like to thank everyone who participated in the  
vigorous discussion about these changes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Glassey | 17 Sep 20:49
Picon
Favicon

Re: [Nea] IESG query re Expert Review

Stephen Hanna wrote:
> Alexey Melnikov (APP AD) has provided many useful comments
> on PA-TNC and PB-TNC. One issue that he has raised is
> whether Expert Review should be required for IANA registration
> of vendor-specific values in the NEA registries and, if so,
> what the expert guidelines should be. Alexey has asked the
> NEA WG to reconsider and discuss this matter. Therefore,
> I'm raising this topic on the NEA list and cc'ing Alexey.
>
> The text in draft-ietf-nea-pb-tnc-05.txt on this matter
> is in section 7.1:
>   
Sorry not possible... the type of thing that Alexey is asking for is 
legally impossible for the IETF to do with the Use License in the 
current state its in and since all of NEA to date has been published 
under that its a bit late to be thinking about doing anything to 
interfere with how people use IETF protocols.

A simpler way to do this would be to change the IETF copyright so that 
it forces the implementor to implement the standard per the Use 
Statement which is really what Alexey is talking about but since most 
all IETF protocols dont have best-practice use models with their 
specifications this also would be a pain.

The problem for NEA and all other WG's today is that NO ONE is forced to 
implement the entire part of a IETF standard to declare they are IETF 
compliant because of the ANY AND ALL USES clause in the license. They 
dont even have to claim their product passed interoperability testing to 
claim their IETF compliant because of that specific language.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Glassey | 21 Sep 00:28
Picon
Favicon

Why is a I-D obsolting a RFC?

Chair - why is a RFC being obsoleted by an Internet-Draft?

Seems to me like an impossibility. No I-D can in and of itself strip any 
RFC document without issuing a new RFC to replace the old one. Since an 
I-D is NOT a RFC this is an issue.

This is a problem per se like this one... 
http://tools.ietf.org/html/draft-ietf-ntp-autokey-06

Todd Glassey
Permalink | Reply | 4 comments |
headers
Todd Glassey | 21 Sep 00:47
Picon
Favicon

Re: Why is a I-D obsolting a RFC?

Todd Glassey wrote:
> Chair - why is a RFC being obsoleted by an Internet-Draft?
>
> Seems to me like an impossibility. No I-D can in and of itself strip 
> any RFC document without issuing a new RFC to replace the old one. 
> Since an I-D is NOT a RFC this is an issue.
>
> This is a problem per se like this one... 
> http://tools.ietf.org/html/draft-ietf-ntp-autokey-06
I forgot to mention that per IETF rules the AutoKEY brief is also filed 
as Informational Only (per the current filing) and as such cannot 
possibly replace a standards-track document like RFC1305 (whether its 
better technology or not).

So we need to resolve this with a new NTP Standards Practice 
work-product which includes the v4 additions and the autokey security 
additions and the RFC needs to be re-set as "not Obsoleted" until the 
actual replacement work is published.

Todd
>
> Todd Glassey
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipr-wg
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel M. Halpern | 21 Sep 01:09

Re: Why is a I-D obsolting a RFC?

Actually, looking at the documents, the only problem (if there is any 
problem at all) is that the draft, when it is published as an RFC, will 
update RFC 1305 rather than obsoleting it.  So the header line should 
probably say "updates" rather than "obsoletes."  And that is clearly 
allowed.

Yours,
Joel

PS: Your initial note seemed to be objecting to some other aspect of the 
process.  I-Ds are frequently labelled as to their intended status. 
That labelling is perfectly legitimate, and is understood only to take 
effect when and if the document is published as an RFC.    So your 
initial question points to a non-issue.

Todd Glassey wrote:
> Todd Glassey wrote:
>> Chair - why is a RFC being obsoleted by an Internet-Draft?
>>
>> Seems to me like an impossibility. No I-D can in and of itself strip 
>> any RFC document without issuing a new RFC to replace the old one. 
>> Since an I-D is NOT a RFC this is an issue.
>>
>> This is a problem per se like this one... 
>> http://tools.ietf.org/html/draft-ietf-ntp-autokey-06
> I forgot to mention that per IETF rules the AutoKEY brief is also filed 
> as Informational Only (per the current filing) and as such cannot 
> possibly replace a standards-track document like RFC1305 (whether its 
> better technology or not).
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Todd Glassey | 21 Sep 03:27
Picon
Favicon

Re: Why is a I-D obsolting a RFC?

Joel M. Halpern wrote:
> Actually, looking at the documents, the only problem (if there is any 
> problem at all) is that the draft, when it is published as an RFC, 
> will update RFC 1305 rather than obsoleting it.  So the header line 
> should probably say "updates" rather than "obsoletes."  And that is 
> clearly allowed.
RFC1305 is a standards track document. This is published for 
informational purposes. I just want the paperwork right for the standard.

Todd
>
> Yours,
> Joel
>
> PS: Your initial note seemed to be objecting to some other aspect of 
> the process.  I-Ds are frequently labelled as to their intended 
> status. That labelling is perfectly legitimate, and is understood only 
> to take effect when and if the document is published as an RFC.    So 
> your initial question points to a non-issue.
>
> Todd Glassey wrote:
>> Todd Glassey wrote:
>>> Chair - why is a RFC being obsoleted by an Internet-Draft?
>>>
>>> Seems to me like an impossibility. No I-D can in and of itself strip 
>>> any RFC document without issuing a new RFC to replace the old one. 
>>> Since an I-D is NOT a RFC this is an issue.
>>>
>>> This is a problem per se like this one... 
>>> http://tools.ietf.org/html/draft-ietf-ntp-autokey-06
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 21 Sep 18:33

Re: Why is a I-D obsolting a RFC?

Todd:

The "(if approved)" is in the header for a reason ....

Once the WG is finished with the document, they will send it to the 
IESG for consideration.  That will result in a Last Call.  That seems 
to be the time to offer advice to the IESG.  At this point, I belive 
you should be offering advice to the WG.

Russ

At 06:28 PM 9/20/2009, Todd Glassey wrote:
>Chair - why is a RFC being obsoleted by an Internet-Draft?
>
>Seems to me like an impossibility. No I-D can in and of itself strip 
>any RFC document without issuing a new RFC to replace the old one. 
>Since an I-D is NOT a RFC this is an issue.
>
>This is a problem per se like this one... 
>http://tools.ietf.org/html/draft-ietf-ntp-autokey-06
>
>Todd Glassey
>_______________________________________________
>Ipr-wg mailing list
>Ipr-wg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/ipr-wg
Permalink | Reply | 0 comments |

Gmane