Re: [IAB] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[John C Klensin]

--On Tuesday, June 23, 2009 01:32 -0400 Marshall Eubanks
 wrote:

> The IETF Trustees invite your comments on the proposed
> revisions to the "Legal Provisions Relating to IETF Documents"
> (TLP) policy.  The proposed revisions are in rtf, pdf and doc
> formats and located at:
> http://trustee.ietf.org/policyandprocedures.html  under Draft
> Policies and Procedures for IETF Documents.
> 
> This is a summary of the proposed revisions:

First, something that is not on your list but that is
problematic, both from the standpoint of the text and from that
of what it might tell us about other changes noted below.

The statement in 2.b, in conjunction with a July 2009 Effective
Date (see the top of the document), leaves documents published
between the presumptive Effective Date of the procedures in
effect today and that date in a strange sort of never-never
land, since 2.b doesn't mention 5378.

I can only infer from this that the Trustees did not do a
careful review of the proposed new procedures in toto.  That is
not a good sign, especially if you are simultaneously asking for
a review period that is consistent only with documents that have
been thoroughly vetted (see below).

> 2.e -- the review period for TLP changes has been changed from
> 30 to 14 days, which is consistent with the last-call period
> for other IETF documents

Actually, no, it is not.  The IETF rule is 14 days for working
group documents... working groups that are open, maintain open
mailing lists and real-time archives for discussion, and where
the documents are I-Ds that are posted, generally available, and
that have achieved WG consensus.  The "WG Consensus" part is
particularly important given the example of Section 2.b of this
draft (discussed above) because such consensus implies that a
lot of people have examined the document carefully, typically
through multiple iterations (sometimes the process fails, but
that is clearly the expectation).   Any other flavor of IETF
document, including individual submissions that are posted as
I-Ds and discussed extensively on public (but non-WG) mailing
lists, requires a four-week review period.  That is a four-week
period after the IESG decides to initiate a Last Call.   I
cannot remember such a Last Call being initiated, ever,
immediately after a -00 I-D is posted and I believe current IESG
de facto procedures would make that impossible.  Realistically,
the shortest possible review period for a non-WG document,
measured from the first draft the community sees of the
document, is about six weeks and I suspect we haven't see that
in years and years.  In practice, it is probably even longer for
WG documents.

So, as 2.e reads in the proposed version, the Trustees will post
a planned TLP change and immediately request comment on it.
The first time the community will see it is when you make that
request.  BCP 101 notwithstanding, the Trustees apparently feel
no obligation to give the community advance warning that you are
considering TLP changes and what is in them and, unlike WG
mailing lists, interested members of the community cannot
subscribe to receive the Trustee mailing list nor access its
archives on a schedule contemporary with actual discussion.

Perhaps 14 days is reasonable. I think it is not for several
reasons, not least of which is that new legal provisions may
require that some members of the community consult with their
own organizational legal counsel before determining how and
whether to comment.  But it certainly cannot be justified on the
basis of alignment with IETF Last Call periods.

> 2.f -- this new language describes the conditions under which
> the IETF Trust will assume licensing and copyright
> responsibility for IAB, IRTF and Independent Stream
> submissions, should the managers of those streams request that
> it do so.

2.f(iii) is inconsistent with RFC 4844, the draft RFC Editor
Model document, and, I believe, with the intent of the
authorizing/ founding documents for the IETF Trust itself.
While the Trustees should clearly do what the IETF tells you to
do (as long as it is logically and legally plausible) wrt IETF
stream documents, your responsibilities are to the broader
community whose needs may, in principle, be different from those
of the IETF.  The statement here effectively requires that the
Trustees must follow the wishes of the IETF with regard to all
streams.  That is not acceptable and interacts in an interesting
way with a provision of the Trust Agreement (see below).

I suggested some alternative language to the IAB when we saw a
preview of this proposal.  I will attempt to find that and post
it to the IETF list.


In Section 3.c, there is a possible issue that I had not noticed
until I went back and reread the Trust Agreement in conjunction
with the provisions of this proposal.   That agreement, in its
Section 9.5, imposes some very specific requirements on any
licenses granted by the Trust for "IPR other than rights in IETF
standards-related documents".

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Simon Josefsson]

Marshall Eubanks  writes:

> 2.e -- the review period for TLP changes has been changed from 30 to
> 14 days, which is consistent with the last-call period for other IETF
> documents

John gave several reasons why this isn't good justification, and I agree
with them.  Reading his thoughts, my opinion is that changing the time
frame from 30 to 14 days is a change in the wrong direction considering
that these documents are not developed in an open way and that the IETF
community may want to ask their lawyers to review the changes before
responding.  In my experience, getting those answers takes significantly
more time than 14 days.

> 4.e -- this new section clarifies the legend requirements for Code
> Components that are used in software under the BSD License. In short,
> the user must include the full BSD License text or a shorter pointer
> to it (which is set forth in Section 6.d)
...
> 6.d -- the BSD legend/pointer described in 4.e above

The text in 6.d doesn't work.  Part of the BSD license (quoted in your
document) is this paragraph:

  Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

If you replace the BSD license with a pointer, you would violate that
part of the BSD license.

To avoid simple mistakes when changing things related to the BSD license
(which now appears to be the norm rather than the exception) I believe
it would be a good idea for the IETF Trust to talk with people and
organizations who understands open source licensing.  I'm sure the
Software Freedom Law Center could help here.

If the process to develop drafts were open and done on a mailing list, I
could have pointed out this earlier.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Russ Housley]

The IESG has prepared a draft statement as a companion 
document.  Since the two are related, the IESG would like the 
community to comment on the two documents at the same time.


On behalf of the IESG,
  Russ

--- Draft IESG Statement ---

This IESG Statement obsoletes all earlier IESG Statements regarding
Copyright statements in MIB and PIB Modules.

The IESG is providing this guidance to align current practice with
RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP)
(http://trustee.ietf.org/license-info).

IETF Contributions and IETF Documents often include code components
that are intended to be directly processed by a computer.  Examples of
such code components include ABNF definitions, XML Schemas, XML DTDs,
XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and
classical programming source code.  The IETF Trust maintains a list of
code component types.  A link to this list can be found on this web
page: http://trustee.ietf.org/license-info.

In addition to the code component types listed, any text found between
the markers  and  shall be considered a code
component.  Authors may wish to use these markers as clear delimiters
of code components.

Authors are encouraged to collect code into a separate section or
appendix.

The TLP requires copyright notice in IETF Documents, but not necessarily
in each code component within an IETF Document.  Authors may choose to
include a copyright notice as a comment when a significant amount of
code is collected together.  For example, authors may include a
copyright notice in a comment as part of an ASN.1 module or a
representation of a classical programming language file.  If IETF
Document authors choose to include a code component copyright notice
comment, they must follow the guidance in Section 6.d of the TLP.
Implementors that extract any code component from the IETF Document must
include the BSD license text as described in Section 4.e of the TLP.




At 01:32 AM 6/23/2009, Marshall Eubanks wrote:

The IETF Trustees invite your comments on the proposed revisions to
the "Legal Provisions Relating to IETF Documents" (TLP) policy.  The
proposed revisions are in rtf, pdf and doc formats and located at: 
http://trustee.ietf.org/policyandprocedures.html  under Draft 
Policies and Procedures for IETF Documents.


This is a summary of the proposed revisions:

2.e -- the review period for TLP changes has been changed from 30 to
14 days, which is consistent with the last-call period for other IETF
documents

2.f -- this new language describes the conditions under which the IETF
Trust will assume licensing and copyright responsibility for IAB, IRTF
and Independent Stream submissions, should the managers of those
streams request that it do so.

4.a -- the URL for the list of Code Components has been updated

4.c -- clarifies that the BSD License may not be applied to Code
Components that come from IETF Documents as to which the Contributor
has prohibited the making of derivative works.

4.e -- this new section clarifies the legend requirements for Code
Components that are used in software under the BSD License. In short,
the user must include the full BSD License text or a shorter pointer
to it (which is set forth in Section 6.d)

6 -- the language regarding placement of legends on IETF Documents has
been clarified.  Placement on the "first page" is no longer required,
and authority for placement of the legends is  with the RFC Editor and
IESG.

6.a - the words "to IETF" have been removed, to enable submission to
IAB, IRFT and other streams.

6.b -- a new sentence has been added to the legend that must be placed
on all IETF Documents, pointing out the BSD License requirements
described in 4.e above and emphasizing that code in IETF Documents
comes without any warranty, as described in the BSD License.

6.c -- some minor clean-up edits

6.d -- the BSD legend/pointer described in 4.e above

7.a -- correction of capitalization

Please accept this message as a formal request by the IETF Trustees
for your review and feedback on the proposed revision to the TLP
document. The comment period will end on July 20, 2009.

I expect the Trustees will decide on whether to adopt this revision
shortly after July 20, 2009.

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[John C Klensin]

--On Tuesday, June 23, 2009 09:54 +0200 Simon Josefsson
 wrote:

> Marshall Eubanks  writes:
> 
>> 2.e -- the review period for TLP changes has been changed
>> from 30 to 14 days, which is consistent with the last-call
>> period for other IETF documents
> 
> John gave several reasons why this isn't good justification,
> and I agree with them.  Reading his thoughts, my opinion is
> that changing the time frame from 30 to 14 days is a change in
> the wrong direction considering that these documents are not
> developed in an open way and that the IETF community may want
> to ask their lawyers to review the changes before responding.
> In my experience, getting those answers takes significantly
> more time than 14 days.

One additional comment on the review period and IAOC/Trustee
style of working more generally:

If one has to carefully review legal provisions, consult counsel
and others, and then comment with care and, when possible,
suggest alternate text, a review period of 14 days after one
first gets a hint that there will be document posted and seeing
the document falls into the "fire drill" category --I believe
faster than we require for any other document review in IETF or
IETF-related contexts.   While I assume that the Trustees would
be careful to avoid it if possible, holidays, vacation periods,
day-job project deadlines, and conflicts with other meetings can
easily turn 14 days into almost nothing, effectively providing
some portions of the community (not just individuals) with no
opportunity for review.

This is not a topic on which we want to have fire drills if they
can possibly be avoided.  We've repeatedly discovered that
inadequate review of IPR documents gets us documents that need
to be revised and retuned again, a process that wastes time and
creates confusion about exactly what provisions apply to which
documents.  We have even has reviews that turn out to be
inadequate when WG processes have been used with multiple I-Ds,
open community discussion of drafts, public information about
what was going into Last Call and what was not, and so on.  

However, after a few hour's thought, I believe that the basic
problem here isn't the difference between a two or four week
review window (although I still believe that two weeks is too
short).  The problem is that the IETF develops documents by
iteration before going into a Last Call/ Final Review process.
Our assumption is that Last Calls are intended as a last chance
to take another look at a document (not a first look) to catch
previously undetected and fairly serious problems... problems
that we assume won't be there because they would have been
caught in the iteration process.

The Trustees (and IAOC) have not been operating in that style.
Instead, we get documents like this one (and, as another
example, some of the RFC Editor-related materials) that are
thrown over the wall to the community with notes that
effectively say "we've finished this, you have NN days to
comment, after which we expect to make whatever changes we have
been persuaded to make and approve it".  In fairness, when the
changes have been significant enough, the community has usually
been given an opportunity to review them before final adoption,
but that is not required by these "here it comes over the wall"
statements and notes and the associated intended adoption dates.

This "throw it over the wall" model would be ok pragmatically if
the IAOC/Trustees almost always got things right.  After all,
the plan and hope for the IASA is that it would permit the IETF
community from having to deal with administrative details.  But,
using this draft with the serious problem Simon spotted and the
minor "no justification for adding boilerplate" one that I
spotted as the most recent of what have been many examples, it
appears that the IAOC/Trustees are composed of human beings with
many other things on their minds and calendars rather than of
infallible entities.  That is no surprise and not a criticism of
any of them, but it may call for some rethinking beyond
discussion of dates.

I have realized in thinking about this that my several irritated
note to or about the IAOC/Trustees in the last year or so have
been a result of this situation: if a document is going to be
thrown over the wall for this kind of final review (or, in the
more common cases, for IETF Last Call), I believe that the
community has the right to expect that it will be refined enough
that finding serious problems will be a rare event.  If
documents regularly come over the IASA/IETF wall that contain
significant problems or issues, then either the IAOC is not
doing its job or the review model is wrong.  While I apologize
for the irritated tone of some of those notes (probably
including the note I wrote several hours ago), the "not doing
the job" problem seems quite real.

I propose that, once the Trustees (or IAOC) have a preliminary
version of a document ready that they should post that document
for preliminary revi

RE: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Contreras, Jorge]

  
> But,
> using this draft with the serious problem Simon spotted and the
> minor "no justification for adding boilerplate" one that I
> spotted as the most recent of what have been many examples, it
> appears that the IAOC/Trustees are composed of human beings with
> many other things on their minds and calendars rather than of
> infallible entities. 

John -- this is just to note that the items raised by you and Simon
aren't errors caused by hurried or sloppy work by the Trust, they are
reasonable points of disagreement over policy and interpretation.  It's
certainly legitimate for you to raise and discuss these points, but you
shouldn't assume that, just because you or Simon have a particular
interpretation, the alternate interpretation embodied in the TLP is a
careless error.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Simon Josefsson]

John C Klensin  writes:

> Assuming that I'm not the only one who sees the recent patterns
> as problematic

I don't think you are alone with that impression.  The process you
outline (posting preliminary versions in draft-* form) sounds great to
me.  I suggested it earlier, and the IETF Trust response was at least
not negative to the idea.  Hopefully it can be implemented.  This would
also solve the problem of recording the history of document drafts, and
making sure documents are readily available via IETF mirrors even if the
main site is down or material is removed from it, which is another
concern today.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Andrew Sullivan]

On Tue, Jun 23, 2009 at 11:20:33AM -0400, Contreras, Jorge wrote:

> aren't errors caused by hurried or sloppy work by the Trust, they are
> reasonable points of disagreement over policy and interpretation.  It's
> certainly legitimate for you to raise and discuss these points, but you
> shouldn't assume that, just because you or Simon have a particular
> interpretation, the alternate interpretation embodied in the TLP is a
> careless error.

That remark suggests to me that John's proposal of iterative work is
justified.  If there are fundamental disagreements about policy and
interpretation, and not just picky details, that are coming out in the
short review period allotted, then presumably there are deep
disagreements that need to be worked out before the wider IETF can be
expected to agree to some policy.

Best regards,

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Yaakov Stein]

Could you change the wording "BSD License" to "revised BSD License"
to avoid confusion with the "original BSD license"
that contained the infamous "advertising clause" ?

Is pseudocode covered by the terms of redistribution of source code in section 
4 ?
The last line of the list of code component types is "classical programming 
code".
Does this imply a requirement that the code can be parsed by some means ?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Joel M. Halpern]

There is an explicit list of what is automatically covered as code.
After discussion, that list does not (did not, the last time I checked) 
include pseudo-code.
Document authors are free to mark their pseudo-code using the code 
marker if they want it treated as code.


The problem, as far as I am concerned, is that pseudo-code is not 
well-defined, and therefore including it in the general list, we would 
have ambiguity as to what was or was not covered.


Yours,
Joel


Yaakov Stein wrote:

Could you change the wording "BSD License" to "revised BSD License"
to avoid confusion with the "original BSD license"
that contained the infamous "advertising clause" ?

Is pseudocode covered by the terms of redistribution of source code in section 
4 ?
The last line of the list of code component types is "classical programming 
code".
Does this imply a requirement that the code can be parsed by some means ?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Simon Josefsson]

Yaakov Stein  writes:

> Could you change the wording "BSD License" to "revised BSD License"
> to avoid confusion with the "original BSD license"
> that contained the infamous "advertising clause" ?

I support making that change too.  (It was pointed out earlier.)

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Yaakov Stein]

Joel

Yes, I referred to that list when I quoted "classical programming code".

However, as the list does not include a set of recognized programming languages,
I thought that the issue was left open.

By code marker I assume you mean  ... ,
which is itself a kind of pseudocode.

Y(J)S

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com] 
Sent: Tuesday, June 23, 2009 19:13
To: Yaakov Stein
Cc: Marshall Eubanks; ietf list; IAB IAB; IESG; Trustees
Subject: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

There is an explicit list of what is automatically covered as code.
After discussion, that list does not (did not, the last time I checked) 
include pseudo-code.
Document authors are free to mark their pseudo-code using the code 
marker if they want it treated as code.

The problem, as far as I am concerned, is that pseudo-code is not 
well-defined, and therefore including it in the general list, we would 
have ambiguity as to what was or was not covered.

Yours,
Joel


Yaakov Stein wrote:
> Could you change the wording "BSD License" to "revised BSD License"
> to avoid confusion with the "original BSD license"
> that contained the infamous "advertising clause" ?
> 
> Is pseudocode covered by the terms of redistribution of source code in 
> section 4 ?
> The last line of the list of code component types is "classical programming 
> code".
> Does this imply a requirement that the code can be parsed by some means ?
> 
> Y(J)S
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Sam Hartman]

I too do not believe that reducing the review period of TLP changes is
at all reasonable.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Marshall Eubanks]

Simon asked that this go to the IETF list.

Begin forwarded message:


From: Marshall Eubanks 
Date: June 23, 2009 11:30:50 AM EDT
To: Simon Josefsson 
Cc: Trustees 
Subject: Re: [Trustees] Proposed Revisions to the IETF Trust  
LegalProvisions (TLP)



On Jun 23, 2009, at 10:18 AM, Simon Josefsson wrote:


"Contreras, Jorge"  writes:




4.e -- this new section clarifies the legend requirements for Code
Components that are used in software under the BSD License.

In short,
the user must include the full BSD License text or a shorter  
pointer

to it (which is set forth in Section 6.d)

...

6.d -- the BSD legend/pointer described in 4.e above


The text in 6.d doesn't work.  Part of the BSD license (quoted in  
your

document) is this paragraph:

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the  
distribution.


If you replace the BSD license with a pointer, you would violate  
that

part of the BSD license.

To avoid simple mistakes when changing things related to the
BSD license
(which now appears to be the norm rather than the exception) I  
believe

it would be a good idea for the IETF Trust to talk with people and
organizations who understands open source licensing.  I'm sure the
Software Freedom Law Center could help here.


Simon (removing the large cc list):

This language was added after extensive review and consultation with
open source experts, including members of the IESG.  There are  
several
open source projects (including some run by Yahoo) that use a  
pointer
for the BSD license, rather than the full text.  We do not think  
this is
a violation of the BSD language.  You may disagree, which is why  
there
is a public comment period for these documents.  But please don't  
assume
that these decisions were taken rashly or without serious  
consideration.


Can you name the open source projects that operate like this?  I've
never heard of a model like this before, and I'm interested to learn
about it if it is used successfully.


Dear Simon;

There was a lot of discussion about this inside the Trust, and I was  
originally in favor of
sticking with the BSD 15 line template and was very dubious about a  
"license by reference" approach. However, there was push-back on the  
length of this (from, e.g. Pasi Eronen), and then Russ found out  
that for YAHOO the



YUI JavaScript library and the Django web framework (used in
datatracker.ietf.org) don't include the license terms in every file.


The code contain this:

/*
Copyright (c) 2009, Yahoo! Inc. All rights reserved.
Code licensed under the BSD License:
http://developer.yahoo.net/yui/license.txt


It is not hard to find examples of this, both within Yahoo and  
without.

See, e.g., http://developer.yahoo.com/yui/docs/AttributeProvider.js.html

So, we researched the status of the BSD license in this regard.
I took it upon myself to query various people I know in the open  
software community (without, however,
using the name of the Trust or saying that this is for the IETF - I  
am, myself, involved in OSS, including in

the GNUGK effort).


While the individual responses are private (I could certainly ask  
people if they mind being quoted, but I wanted to get this out today),  
typical is this :



"Yahoo is following common practice."

I did not receive a single negative response.

I also talked with corporate counsel from a large corporation with a  
heavy IETF involvement, who at least did not object to this.


In addition, the other Trustees did their own research, and this was  
discussed both internally and externally over a period of over 2  
months.


And, of course, our own counsel, Jorge Contreras, researched this  
and agrees with the feasibility of the license by reference approach.


After all of this, the Trust developed consensus around the license  
by reference option.


So, I feel that the Trustees have done due diligence here.

Of course, there is never a final word on these matters. If you know  
reasons why this is inadvisable, I would be glad to hear them. That  
is, of course, why all of these matters go to community review.


I of course extend this request to everyone. It is important to get  
this right.


Regards
Marshall




Regards
Marshall





Which open source experts did you consult about licensing?

Providing background information and rationale behind changes when
posting drafts would give you the benefit of doubt about these  
issues,
and would probably build more confidence in the change within the  
IETF

community.

/Simon



___
Trustees mailing list
trust...@ietf.org
https://www.ietf.org/mailman/listinfo/trustees



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Simon Josefsson]

Marshall Eubanks  writes:

> Simon asked that this go to the IETF list.

Thanks for moving this back to the IETF list.  I believe these
discussions should be public.  Many considerations appears to have been
made that the wider IETF community is unaware of.

I would expect information like this to be part of the IETF Trust
minutes, but it seems no minutes have been published since September
2008: http://trustee.ietf.org/minutes.html

> Begin forwarded message:
>
>> From: Marshall Eubanks 
>> Date: June 23, 2009 11:30:50 AM EDT
>> To: Simon Josefsson 
>> Cc: Trustees 
>> Subject: Re: [Trustees] Proposed Revisions to the IETF Trust
>> LegalProvisions (TLP)
>>
>>
>> On Jun 23, 2009, at 10:18 AM, Simon Josefsson wrote:
>>
>>> "Contreras, Jorge"  writes:
>>>

>> 4.e -- this new section clarifies the legend requirements for Code
>> Components that are used in software under the BSD License.
> In short,
>> the user must include the full BSD License text or a shorter
>> pointer
>> to it (which is set forth in Section 6.d)
> ...
>> 6.d -- the BSD legend/pointer described in 4.e above
>
> The text in 6.d doesn't work.  Part of the BSD license (quoted in
> your
> document) is this paragraph:
>
> Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in the
> documentation and/or other materials provided with the
> distribution.
>
> If you replace the BSD license with a pointer, you would violate
> that
> part of the BSD license.
>
> To avoid simple mistakes when changing things related to the
> BSD license
> (which now appears to be the norm rather than the exception) I
> believe
> it would be a good idea for the IETF Trust to talk with people and
> organizations who understands open source licensing.  I'm sure the
> Software Freedom Law Center could help here.

 Simon (removing the large cc list):

 This language was added after extensive review and consultation with
 open source experts, including members of the IESG.  There are
 several
 open source projects (including some run by Yahoo) that use a
 pointer
 for the BSD license, rather than the full text.  We do not think
 this is
 a violation of the BSD language.  You may disagree, which is why
 there
 is a public comment period for these documents.  But please don't
 assume
 that these decisions were taken rashly or without serious
 consideration.
>>>
>>> Can you name the open source projects that operate like this?  I've
>>> never heard of a model like this before, and I'm interested to learn
>>> about it if it is used successfully.
>>
>> Dear Simon;
>>
>> There was a lot of discussion about this inside the Trust, and I was
>> originally in favor of
>> sticking with the BSD 15 line template and was very dubious about a
>> "license by reference" approach. However, there was push-back on the
>> length of this (from, e.g. Pasi Eronen), and then Russ found out
>> that for YAHOO the

Before continuing the response, should we understand that the rationale
for this change is to shorten the license text that has to be included
in derived works?  Did the Trust do anything to identify whether the
wider IETF community feels this is a problem?  In other words: on whose
behalf is this change made?

If that is the rationale, has an alternative to the BSD license been
considered?  The GNU All Permissive (GAP) license is comparable in size
to the excerpt in 6.d.  The entire GAP license reads:

 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.

Another option is to describe the common practice that many open source
packages are using: include a short blurb in the file or function that
contains the derived work, pointing to a file included in the
distribution.

 YUI JavaScript library and the Django web framework (used in
 datatracker.ietf.org) don't include the license terms in every file.
>>>
>>> The code contain this:
>>>
>>> /*
>>> Copyright (c) 2009, Yahoo! Inc. All rights reserved.
>>> Code licensed under the BSD License:
>>> http://developer.yahoo.net/yui/license.txt
>>
>> It is not hard to find examples of this, both within Yahoo and
>> without.
>> See, e.g., http://developer.yahoo.com/yui/docs/AttributeProvider.js.html

This usage is typical and fine.  In general, there are two reasons why
this usage is fine.  Only one condition needs to hold:

1) The publisher of the material is not a "redistributor" of the code
under the BSD license.

2) The copyright holder includes the BSD license in the package.

Note that Yahoo includes the entire copy of the BSD license where it has
used others code in the YUI package.

The new IETF policy text suggests that recipients redistribute 

Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[John C Klensin]

--On Tuesday, June 23, 2009 12:49 -0400 Marshall Eubanks
 wrote:

>...
>> After all of this, the Trust developed consensus around the
>> license by reference option.
>> 
>> So, I feel that the Trustees have done due diligence here.
>> 
>> Of course, there is never a final word on these matters. If
>> you know   reasons why this is inadvisable, I would be glad
>> to hear them. That   is, of course, why all of these matters
>> go to community review.
> 
> I of course extend this request to everyone. It is important
> to get this right.

Marshall,

As you will see in the much longer note I just sent in response
to a note from Jorge on which the Trustees were copied, my
fundamental problem here is not with one form of license
statement or another or with one phrasing or another, although I
think both need to be examined carefully and gotten right.

Instead, I think a fundamental disconnect has developed between
at least some portion of the community and how we understood BCP
101 and the intent behind it on the one hand and the
IAOC/Trustees on the other.

In my view, the IASA (including both the IAOC and the Trust) are
expected to be implementers of policy, not definers of policy.
I welcome policy _suggestions_ and drafts from the IASA but
believe that the IAOC and Trustees are obligated to be
sufficiently open and accountable that the community can really
engage intelligently in discussions of the policy issues.

When you say something equivalent to "the Trustees did a lot of
work, evaluated all of the options in private, and then reached
consensus and presented the community with the one option we
agreed on (also in private)" then I think you are violating both
the assumption about where the policy-determination
responsibility lies but fundamental norms of the community.   If
the document came to the IETF list with a summary of the other
options you had considered and why you had made those decisions,
the situation would be different.  If that summary was in
minutes that were published on a timely enough basis that they
could figure into this discussion, the situation might be
different.  But here you say "After all of this, the Trust
developed consensus" ... "and this is what you get", I think we
have a disconnect.

I note that the IESG is much more closely connected to the IETF
community than the Trustees and that they have explicit
responsibility and authority for determining IETF consensus.
100% of its "voting" members come out of a community selection
process via the Nomcom.  It does its work iteratively with the
community and many of its decisions are made based on
suggestions from, and after thorough vetting by, open Working
Groups.   It holds private discussions for convenience but
concluded years ago that the community would be much better
served by tracking systems that actually identify discussions,
options, and, where relevant, the reasoning behind decisions.
More recently, they have adopted models for narrative as well as
formal teleconference minutes in order to keep the community
better informed on a timely basis.  They seem to be about a
month behind on those, but that is hugely different from "no
minutes or other public record since September".

The Trustees, if only because of that lesser degree of
connection and less well defined responsibility for defining
policy and determining community consensus, have, IMO, a much
stronger obligation than the IESG, not for making decisions, but
for exposing options and considerations to the community for
decisions.

Another example of this arises in conjunction with the comments
that I made to the IAB and that were circulated to the Trustees
based on a draft the IAB had seen very short time earlier.
Apparently those comments reached the Trustees and you decided
(perhaps by default) to put them aside and get the draft out due
to time considerations.  At one level that is ok -- if you have
concluded that you have a deadline and need to get a document
posted, I'm ok with that (although the iterative and I-D posting
style I suggested would largely eliminate the problem of a
"deadline" associated with the community's first look at a
document (except in real emergencies).

But then I think your cover note should have said "The Trustees
want the community to look at this because we think most of the
details are solid even though we are still examining some of the
text" and not "Please accept this message as a formal request by
the IETF Trustees for your review and feedback on the proposed
revision to the TLP document. The comment period will end on
July 20, 2009. [...] I expect the Trustees will decide on
whether to adopt this revision shortly after July 20, 2009."
That sort of statement is appropriate only for a document that
is already debugged and that the Trustees believe is ready to
go... not one that, to borrow words from RFC 2026, "contains
known ... deficiencies".

regards,
john

p.s. Either you or Jorge have my permission to post my more
extend

Re: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Marshall Eubanks]

Dear Simon;

Just to save people from having to wade through lots of text  
unnecessarily, the major issue we are discussing here
is the "license by reference" aspect of the proposed TLP's BSD license  
requirements.


On Jun 23, 2009, at 1:16 PM, Simon Josefsson wrote:


Marshall Eubanks  writes:


Simon asked that this go to the IETF list.


Thanks for moving this back to the IETF list.  I believe these
discussions should be public.  Many considerations appears to have  
been

made that the wider IETF community is unaware of.



At least in this case, there was no secrecy intended - I just hit  
"reply all." It had

come to me with the distribution stripped out.


I would expect information like this to be part of the IETF Trust
minutes, but it seems no minutes have been published since September
2008: http://trustee.ietf.org/minutes.html



We are working on this and expect to get caught up soon - but minutes  
will rarely capture

all of the details of such discussions.


Begin forwarded message:


From: Marshall Eubanks 
Date: June 23, 2009 11:30:50 AM EDT
To: Simon Josefsson 
Cc: Trustees 
Subject: Re: [Trustees] Proposed Revisions to the IETF Trust
LegalProvisions (TLP)


On Jun 23, 2009, at 10:18 AM, Simon Josefsson wrote:


"Contreras, Jorge"  writes:



4.e -- this new section clarifies the legend requirements for  
Code

Components that are used in software under the BSD License.

In short,

the user must include the full BSD License text or a shorter
pointer
to it (which is set forth in Section 6.d)

...

6.d -- the BSD legend/pointer described in 4.e above


The text in 6.d doesn't work.  Part of the BSD license (quoted in
your
document) is this paragraph:

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in  
the

documentation and/or other materials provided with the
distribution.

If you replace the BSD license with a pointer, you would violate
that
part of the BSD license.

To avoid simple mistakes when changing things related to the
BSD license
(which now appears to be the norm rather than the exception) I
believe
it would be a good idea for the IETF Trust to talk with people  
and
organizations who understands open source licensing.  I'm sure  
the

Software Freedom Law Center could help here.


Simon (removing the large cc list):

This language was added after extensive review and consultation  
with

open source experts, including members of the IESG.  There are
several
open source projects (including some run by Yahoo) that use a
pointer
for the BSD license, rather than the full text.  We do not think
this is
a violation of the BSD language.  You may disagree, which is why
there
is a public comment period for these documents.  But please don't
assume
that these decisions were taken rashly or without serious
consideration.


Can you name the open source projects that operate like this?  I've
never heard of a model like this before, and I'm interested to  
learn

about it if it is used successfully.


Dear Simon;

There was a lot of discussion about this inside the Trust, and I was
originally in favor of
sticking with the BSD 15 line template and was very dubious about a
"license by reference" approach. However, there was push-back on the
length of this (from, e.g. Pasi Eronen), and then Russ found out
that for YAHOO the


Before continuing the response, should we understand that the  
rationale

for this change is to shorten the license text that has to be included
in derived works?  Did the Trust do anything to identify whether the
wider IETF community feels this is a problem?  In other words: on  
whose

behalf is this change made?


We received complaints about the February 15th TLP in this regard.




If that is the rationale, has an alternative to the BSD license been
considered?


The answer is yes, alternatives were considered, but this is a  
complicated issue.

Part of the advice we received from the legal people
we talked to was to use a common license choice, lest corporations  
simply never use the code, to save

the expense of getting legal approval of the license. BSD seemed
to be strongly favored here, as something that is well known and used  
by lots of parties. This advice, as
far as I can tell, was virtually unanimous, both to the Trust as a  
whole, and to myself and others in our

individual discussions.

The GAP below seems simple, but that doesn't mean that corporate  
counsel would regard it as simple. I do not
know. (In my experience is very hard to get a corporate counsel,  
especially counsel you are not paying for, to
say that anything is OK. I am inevitably reminded of the J.R.R.  
Tolkien's saying :


"Go not to the elves for counsel, for they will say both yes and no.")

All of this makes it hard for me to see the wisdom of adopting another  
license.



 The GNU All Permissive (GAP) license is comparable in size
to the excerpt in 6.d.  The entire GAP license reads:

Copyin

Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Sam Hartman]

I find myself in complete agreement with John's message.  I'll admit
that I probably don't have the time or desire to actually examine the
IAOC's actions if they were to be accountable to the community.
However, when I was involved in drafting BCP 101 it was my assumption
that the IAOC would be accountable to the community and to the extent
that there are people who want to take advantage of that
accountability, we should foster and support that.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Simon Josefsson]

This is another side-discussion that may be useful to do publicly,
forwarded with Sam's permission.

This discussion brings up another (subtler) point about allowing
re-licensing between works licensed under the BSD license directly and
works licensed under the newly proposed BSD-license-via-IETF-pointer.

If the new Trust text allowed recipients to re-license code back to the
original BSD licensed code, and not the BSD-license-via-IETF-pointer
license, I would not object to the new text.  It would allow me to do
what I prefer, and allowing others to do what they prefer.  I would
continue to feel that the new text is mis-guided and opens for solutions
that I believe are sub-optimal, but if others believe they want that
option, I would not be against having that option (as long as I can use
their BSD-license-via-IETF-pointer derived work under the original BSD
license).

/Simon

Sam Hartman  writes:

> Simon, I appreciate your concern about the BSD license.
>
> However, I'm not entirely sure why it matters.
>
> There are apparently some lawyers out there who believe the pointer
> approach is reasonable.  What's the harm in the trust permitting this?
>
> If your legal advice suggests that using that option would produce
> inconsistent results, then you can simply include the full text.
>
> I'll admit that I'd be totally happy with the GAP license or (given
> growing frustrations) the WTFPL as a license for ietf documents or as
> large a subset of IETF documents as we can get.  So, I'm not really
> bothered by options that some might view as inconsistent, provided that
>
> 1) I don't have to use them
>
> 2) If someone else uses them and I'm using their code I can go change
> it to something reasonable.

Simon Josefsson  writes:

> Sam Hartman  writes:
>
>> Simon, I appreciate your concern about the BSD license.
>>
>> However, I'm not entirely sure why it matters.
>>
>> There are apparently some lawyers out there who believe the pointer
>> approach is reasonable.  What's the harm in the trust permitting this?
>
> I haven't seen any references to lawyers that believe redistributing
> others BSD works and replacing the BSD license with a pointer is OK --
> do you have any links?
>
> The BSD license has peculiar wordings here ("Redistributions in binary
> form must reproduce ... this list of conditions ... in the documentation
> and/or other materials provided with the distribution"), so a general
> opinion about replacing licenses with a pointer would not apply as far
> as I can tell.
>
> If there are lawyers that really do believe the situation wrt BSD is OK,
> I'm fine with the trust allowing either case.  I'm basing my opinion on
> the assumption that there aren't any.
>
>> If your legal advice suggests that using that option would produce
>> inconsistent results, then you can simply include the full text.
>
> I couldn't if I receive the derived work from someone that didn't
> include the entire BSD license.
>
>> I'll admit that I'd be totally happy with the GAP license or (given
>> growing frustrations) the WTFPL as a license for ietf documents or as
>> large a subset of IETF documents as we can get.  So, I'm not really
>> bothered by options that some might view as inconsistent, provided that
>>
>> 1) I don't have to use them
>
> Me too.
>
>> 2) If someone else uses them and I'm using their code I can go change
>> it to something reasonable.
>
> I'm not sure you could do that in this situation.  You received their
> code under a license that points to some document for the BSD lciense,
> and that document does not allow you to change the license of that
> derived work.  So you are struck with the IETF pointer license.
>
> /Simon

Sam Hartman  writes:

> Simon, thanks for explaining your concern.  I agree that if I cannot
> replace the poinrter with the full text of the BSD license, then the
> trust language is problematic.
>
> I'd suggest that allowing this replacement might be an easy way to
> make progress.
>
> Although I seem to have written to you individually, which is not my
> intent.  If you think it would be beneficial, feel free to forward our
> conversation to a wider audience.
> Hmm, perhaps I should have added code begin and code end tags to this IETF 
> contribution:-)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)

[Marshall Eubanks]

On Jun 23, 2009, at 2:49 PM, Simon Josefsson wrote:


This is another side-discussion that may be useful to do publicly,
forwarded with Sam's permission.

This discussion brings up another (subtler) point about allowing
re-licensing between works licensed under the BSD license directly and
works licensed under the newly proposed BSD-license-via-IETF-pointer.

If the new Trust text allowed recipients to re-license code back to  
the

original BSD licensed code, and not the BSD-license-via-IETF-pointer
license, I would not object to the new text.  It would allow me to do
what I prefer, and allowing others to do what they prefer.  I would
continue to feel that the new text is mis-guided and opens for  
solutions

that I believe are sub-optimal, but if others believe they want that
option, I would not be against having that option (as long as I can  
use

their BSD-license-via-IETF-pointer derived work under the original BSD
license).


Can you send text / mods that would do that ? I am not sure I get it  
on the first reading.


Marshall




/Simon

Sam Hartman  writes:


Simon, I appreciate your concern about the BSD license.

However, I'm not entirely sure why it matters.

There are apparently some lawyers out there who believe the pointer
approach is reasonable.  What's the harm in the trust permitting  
this?


If your legal advice suggests that using that option would produce
inconsistent results, then you can simply include the full text.

I'll admit that I'd be totally happy with the GAP license or (given
growing frustrations) the WTFPL as a license for ietf documents or as
large a subset of IETF documents as we can get.  So, I'm not really
bothered by options that some might view as inconsistent, provided  
that


1) I don't have to use them

2) If someone else uses them and I'm using their code I can go change
it to something reasonable.


Simon Josefsson  writes:


Sam Hartman  writes:


Simon, I appreciate your concern about the BSD license.

However, I'm not entirely sure why it matters.

There are apparently some lawyers out there who believe the pointer
approach is reasonable.  What's the harm in the trust permitting  
this?


I haven't seen any references to lawyers that believe redistributing
others BSD works and replacing the BSD license with a pointer is OK  
--

do you have any links?

The BSD license has peculiar wordings here ("Redistributions in  
binary
form must reproduce ... this list of conditions ... in the  
documentation

and/or other materials provided with the distribution"), so a general
opinion about replacing licenses with a pointer would not apply as  
far

as I can tell.

If there are lawyers that really do believe the situation wrt BSD  
is OK,
I'm fine with the trust allowing either case.  I'm basing my  
opinion on

the assumption that there aren't any.


If your legal advice suggests that using that option would produce
inconsistent results, then you can simply include the full text.


I couldn't if I receive the derived work from someone that didn't
include the entire BSD license.


I'll admit that I'd be totally happy with the GAP license or (given
growing frustrations) the WTFPL as a license for ietf documents or  
as

large a subset of IETF documents as we can get.  So, I'm not really
bothered by options that some might view as inconsistent, provided  
that


1) I don't have to use them


Me too.

2) If someone else uses them and I'm using their code I can go  
change

it to something reasonable.


I'm not sure you could do that in this situation.  You received their
code under a license that points to some document for the BSD  
lciense,

and that document does not allow you to change the license of that
derived work.  So you are struck with the IETF pointer license.

/Simon


Sam Hartman  writes:


Simon, thanks for explaining your concern.  I agree that if I cannot
replace the poinrter with the full text of the BSD license, then the
trust language is problematic.

I'd suggest that allowing this replacement might be an easy way to
make progress.

Although I seem to have written to you individually, which is not my
intent.  If you think it would be beneficial, feel free to forward  
our

conversation to a wider audience.
Hmm, perhaps I should have added code begin and code end tags to  
this IETF contribution:-)

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Fwd: IETF Trust TLP

[Marshall Eubanks]

Monte is Founder and Executive Contact, xiph.org, and is responsible  
(as much as any person)

for Ogg / Vorbis. He was also one of my sources from before.

Regards
Marshall

Begin forwarded message:


From: Christopher Montgomery 
Date: June 23, 2009 2:32:07 PM EDT
To: Marshall Eubanks 
Subject: Re: IETF Trust TLP

On Tue, Jun 23, 2009 at 1:03 PM, Marshall  
Eubanks wrote:


I would be curious as to your perspective on the "license by  
reference"

issue as instantiated and the entire TLP support of open source.


First, I Am Not A Lawyer, and since the legal implications are
probably the most important, I'm not going to be able to comment on
the most important aspect.

As a creator, I am personally interested in license clarity.  So long
as it's absolutely clear what the license is, a code component or
document clearly referencing the correct license is more than
sufficient for me.  In the simplest sense (the code simply saying,
"BSD license, see file") was one of the great 'improvements' at the
time over the MIT license, which required the license be part of the
code.  You ended up with many files consisting mostly of pages upon
pages of various licenses and copyrights rather than code itself.

Coding is a massively collaborative exercise, and the licensing and
attribution have to scale.

Or am I missing completely what you're asking?


No, that was it.




Monty



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: IETF Trust TLP

[Sam Hartman]

> "Marshall" == Marshall Eubanks  writes:

Marshall> Monte is Founder and Executive Contact, xiph.org, and is
Marshall> responsible (as much as any person) for Ogg / Vorbis. He
Marshall> was also one of my sources from before.

The message you quoted is entirely non-responsive to the discussion at
hand.  He's talking about a COPYING file within a distribution, not a
reference outside that distribution.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Update to the IETF Web Site

[IETF Chair]

For the last 10 months, the IETF Secretariat at the direction of the
IAOC and input form the IESG and the IETF community has been working on
an overhaul of the IETF web site.  The goals for the new site were simple
and included:

1) Make it easier for those who are new to the IETF to get involved;

2) Make it easier for experienced community members to access the  
   tools and information they most need; and
   
3) Ensure that the web site is compliant with W3C standards and  
   accessible to as many people as possible.

The revised web site is currently located at www6.ietf.org.  Please
explore it.  One of the first places you may want to start is at the
very bottom of the left navigation bar, where you will see the
"Customize View" link.  The default view is "Normal" and if you click
on one of the other views you will see slightly different views of the
navigation bar and home page.  As you move through the rest of the site,
the navigation bar will be appear as you selected.

On July 6th, the new web site will go live as www.ietf.org.  The old
site will then be accessible at www4.ietf.org, but the Secretariat will
not be updating it any longer, so it will quickly become stale.

At the end of August, the old web site will be takes offline.  These two
months will be used to ensure that all of the web content is available
on the new web site and allow any tools that extract content to be
updated.

Any web site is a work in progress.  The IAOC and the Secretariat are
committed to continuing to improve the web site.  So, please let us send
email to the IETF Executive Director, Alexa Morris ,
with suggestions for further improvements.  She is looking forward to
receiving your suggestions and constructive criticism.

Russ Housley
IETF Chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

LC summary for draft-ietf-opsawg-operations-and-management

[David Harrington]

Hi,

Here is a summary of Last Call comments:

1) Cullen Jennings told chairs to pay attention; 
[dbh: no action required.]

2) Henning Schulzrinne concerned about slowing approvals, and applying
to new protocols and extensions.
[dbh: added text about the different needs for new protocols and
extensions]

3) Bernard Aboba concerned that IETF should focus on making successful
protocols, and Management Considerations may be an unnecessary
requirement. 
[dbh: this document went to great lengths to say that it was NOT
prescribing a Management Considerations requirement. sigh]
Management support is seldom a show-stopper. Wants differentiation of
need with new protocol versus existing protocols. 
[dbh: added text about the different needs for new protocols and
extensions]

4) IANA - no problem
[dbh: no action required.]

5) Miguel Garcia - GEN-ART + editorial 
[dbh: all comments fixed]

6) Sam Hartman - objects to BCP
* It does not reflect practices across significant areas of the IETF
interoperable mgmt not required for all protocols
document focuses on networking devices; document should be
scoped.
[dbh: removed "primary" goal]
[dbh: I added some text to "Designing for OPS and Management"
in the Introduction that talks about the traditional approach of using
MIB modules for networking devices, and that emerging technologies
have caused a change to IETF technologies and atrategy, and management
requirements.]
* It does not provide clear, actionable guidelines
normative requirements vs "might want to consider"
[dbh: added text about "when appropriate," a data model might be
used.]
* It is not sufficiently clear to be understood outside the O&M area.
fails to make distinctions (ops vs mgmt; config vs other mgmt)
document organization and discussions jumbled.
[dbh: removed the use of "operations model". It is unclear what the
"model" part refers to. Changed text to discuss operations, and
deployment, etc.]
[dbh: I moved the counter discussion, which was probably the most
jarring context change. I modified a few other places, but some
specific suggestions for changes might be helpful. YMMV]
[dbh: I removed discussions of data and control planes, and tried to
make the discussion general enough to also include services.]

7) Eliot Lear - Informational, not BCP
section 3.2 needs more applicability discussion
[dbh: I added some text to "Designing for OPS and Management"
in the Introduction that talks about the traditional approach of using
MIB modules for networking devices, and that emerging technologies
have caused a change to IETF technologies and atrategy, and management
requirements.]
[dbh: changed primary gola from interoperability to "the 
primary goal is the ability to roll out new useful functions and 
services in a way in which they can be managed in a scalable manner, 
where one has understood the network impact (as part of total cost of
operations) for that service."]

8) SM - does not scale well for BCP
[dbh: no action required.]

9) Sam (in discussion with Dan) - this document does not indicate that

a WG can decide "no management is fine".
[dbh: section 4.2 is very clear on that point]

10) Eliot Lear - need applicability scope
needs to be be smaller document
[dbh: not something I think we can accomplish without a rewrite and
consensus on whether to keep each detail. WG consensus was to not do a
rewrite at this time.]

11) Eric Rosen - opposes BCP status 
[dbh: no action required.]

12) Randy Presuhn - Thinks document is important; prefers
Informational to BCP.
[dbh: no action required.]

13) Joel Halpern - discussion on OPS guidelines versus requirement
[dbh: no action required.]

14) Andy Bierman - discussion of OPS guidelines versus requirement
[dbh: no action required.]

15) Tom Petch - Thinks abstract should be changed. I do not understand
his point well enough to take action, and, as he points out, the
document says it is not trying to solve the problem he raises.
[dbh: no action taken.]

draft-ietf-opsawg-operations-and-management-08 has been posted.

David Harrington
dbharring...@comcast.net
ietf...@comcast.net
dharring...@huawei.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [Trustees] [IAB] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Contreras, Jorge]

 
> The statement in 2.b, in conjunction with a July 2009 Effective
> Date (see the top of the document), leaves documents published
> between the presumptive Effective Date of the procedures in
> effect today and that date in a strange sort of never-never
> land, since 2.b doesn't mention 5378.

The Feb. 15 version of the TLP is currently in effect.  Documents
published between Feb. 15 and the effectiveness of the revised TLP will
continue to be governed by the Feb. 15 TLP.  There should be no gap in
coverage.

> I can only infer from this that the Trustees did not do a
> careful review of the proposed new procedures in toto.  

That is not true.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

IETF 75 agenda... Re: Update to the IETF Web Site

[Leslie Daigle]

I do note, with favour, that it at least implies there will still be 
text (and html) agendas in the future.


Leslie.
... still trying to figure out why there is only a PDF version of the 
IETF75 agenda on the current website...


IETF Chair wrote:

For the last 10 months, the IETF Secretariat at the direction of the
IAOC and input form the IESG and the IETF community has been working on
an overhaul of the IETF web site.  The goals for the new site were simple
and included:

1) Make it easier for those who are new to the IETF to get involved;

2) Make it easier for experienced community members to access the  
   tools and information they most need; and
   
3) Ensure that the web site is compliant with W3C standards and  
   accessible to as many people as possible.


The revised web site is currently located at www6.ietf.org.  Please
explore it.  One of the first places you may want to start is at the
very bottom of the left navigation bar, where you will see the
"Customize View" link.  The default view is "Normal" and if you click
on one of the other views you will see slightly different views of the
navigation bar and home page.  As you move through the rest of the site,
the navigation bar will be appear as you selected.

On July 6th, the new web site will go live as www.ietf.org.  The old
site will then be accessible at www4.ietf.org, but the Secretariat will
not be updating it any longer, so it will quickly become stale.

At the end of August, the old web site will be takes offline.  These two
months will be used to ensure that all of the web content is available
on the new web site and allow any tools that extract content to be
updated.

Any web site is a work in progress.  The IAOC and the Secretariat are
committed to continuing to improve the web site.  So, please let us send
email to the IETF Executive Director, Alexa Morris ,
with suggestions for further improvements.  She is looking forward to
receiving your suggestions and constructive criticism.

Russ Housley
IETF Chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


--

---
"Reality:
 Yours to discover."
-- ThinkingCat
Leslie Daigle
les...@thinkingcat.com
---
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 75 agenda... Re: Update to the IETF Web Site

[Alexa Morris]

We are currently experiencing some problems with the agenda tool, and  
until they are addressed we are not able to generate an html or text  
version of the agenda. We hope to have the tool repaired shortly.


Alexa

On Jun 23, 2009, at 2:32 PM, Leslie Daigle wrote:



I do note, with favour, that it at least implies there will still be  
text (and html) agendas in the future.


Leslie.
... still trying to figure out why there is only a PDF version of  
the IETF75 agenda on the current website...


IETF Chair wrote:

For the last 10 months, the IETF Secretariat at the direction of the
IAOC and input form the IESG and the IETF community has been  
working on
an overhaul of the IETF web site.  The goals for the new site were  
simple

and included:
1) Make it easier for those who are new to the IETF to get involved;
2) Make it easier for experienced community members to access  
the tools and information they most need; and
  3) Ensure that the web site is compliant with W3C standards  
and accessible to as many people as possible.

The revised web site is currently located at www6.ietf.org.  Please
explore it.  One of the first places you may want to start is at the
very bottom of the left navigation bar, where you will see the
"Customize View" link.  The default view is "Normal" and if you click
on one of the other views you will see slightly different views of  
the
navigation bar and home page.  As you move through the rest of the  
site,

the navigation bar will be appear as you selected.
On July 6th, the new web site will go live as www.ietf.org.  The old
site will then be accessible at www4.ietf.org, but the Secretariat  
will

not be updating it any longer, so it will quickly become stale.
At the end of August, the old web site will be takes offline.   
These two
months will be used to ensure that all of the web content is  
available

on the new web site and allow any tools that extract content to be
updated.
Any web site is a work in progress.  The IAOC and the Secretariat are
committed to continuing to improve the web site.  So, please let us  
send
email to the IETF Executive Director, Alexa Morris  
,

with suggestions for further improvements.  She is looking forward to
receiving your suggestions and constructive criticism.
Russ Housley
IETF Chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


--

---
"Reality:
Yours to discover."
   -- ThinkingCat
Leslie Daigle
les...@thinkingcat.com
---
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Robert Elz]

In other organisations, when I see (what has been called here), an
"over the wall" list of changes, I usually expect, and usually receive,
in addition to the list of changes (along with what used to be there)
all of which exists here, some kind of explanation why the changes are
being proposed.  That is, the motivation for the change.

For some of the changes here, I can guess what's up, and some of those
guesses might even be right - in others I have no idea at all what would
be motivating the proposed change.

One such is ...

  | 2.e -- the review period for TLP changes has been changed from 30 to 14
  | days, which is consistent with the last-call period for other IETF
  | documents 

which I can't even begin to guess at a rationale for.   What kind of
change in this area is ever going to be so urgent that even a 30 day
waiting period is a problem?   If a change were going to be made here,
I'd be expecting it to be in the other direction, extending the period
for comments, rather than reducing it.

If the only reason for this change is some desire to be consistent with
the rest of the IETF last call timeline, then that's misguided in the
extreme - first because there is no one last call period (there are
several, for different kinds of documents, and circumstances) and second,
because the 14 day LC period for IETF WG docs is set to match the IESG
meeting timetable, it allows the IESG to approve a last call on a doc at
one meeting, after which in the days that follow, the LC announcement is
actually issued.  Two weeks after that, the responsible AD can summarise
the LC results, and have the results available for the IESG at its next
meeting (that being 2 meetings after the LC approval was made).   There's
a reason for that particular period for most docs - it allows things to
move along without undue delay (after they've often been debated for a
year or more already.)

In general, I'm tempted to summarily reject any request for any change
(even fixing a simple spelling mistake) until I've seen an explicit
explanation for why the change is needed - that way I can evaluate whether
the proposal actually meets the stated objective, whether the objective
might perhaps be realised better via a different change, and even whether
the objective is desirable in the first place.

When all that is provided is "here is this list of changes" I have the
opportunity for none of that, so I can't possibly tell whether they're
reasonable or not, nor whether they are effective or not.

For now, make no changes at all.

kre


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf