On 10/25/2012 11:47 AM, IESG Secretary wrote:
Internet-Drafts (I-Ds) are working documents of the IETF. RFC 2026,
BCP 9, describes the purpose of I-Ds, and it also provides some policies
that govern the I-D Repository. RFC 2026 says:
During the development of a specification, draft versions of the
document are made available for informal review and comment by
placing them in the IETF's "Internet-Drafts" directory, which is
replicated on a number of Internet hosts.
OK - we acknowledge that we replicate this for wide distribution... why?
what specifically is the goal in that? If the goal is to say "This is
deployed across a large number of sites to enable wide-community
exposure to in-process works" then perhaps we should revise the BCP's to
include that idea as well.
This makes an evolving
working document readily available to a wide audience, facilitating
the process of review and revision.
I.e. its supposed to be a snapshot, a signpost along the path so to
speak...
An Internet-Draft that is published as an RFC, or that has remained
unchanged in the Internet-Drafts directory for more than six months
without being recommended by the IESG for publication as an RFC, is
simply removed from the Internet-Drafts directory.
An interesting question is how this affects the people hosting images of
the IETF media and what their legal obligations under CFAA and
associated legal precedents is. Hosting the IETF file-store could be
very financially dangerous for publication partners in that they dont
get the IETF research exemption and are at risk for litigation no matter
what the "hey the world is flat because we said so" idea which has
existed so long here.
-------------------------
At any time, an
Internet-Draft may be replaced by a more recent version of the same
specification, restarting the six-month timeout period.
Which then raises the issue of whether an I-D provides any 'right to implement the proposed IP it defines' because if it does in any form then it or the trust must address 'rights collisions' or 'rights expiry' and what that means to Relying Parties (as part of the Relying Party License blob) attached to everything IETF.
An Internet-Draft is NOT a means of "publishing" a specification;
Yeah right - an I-D is exactly a means of publishing a specification, just not one which is a IETF Standard... The problem is the improper use of the Term SPECIFICATION to imply "approved IETF Standard" instead of just a technical discourse on how some protocol works.
specifications are published through the RFC mechanism described in
the previous section. Internet-Drafts have no formal status, and are
subject to change or removal at any time.
Again - All IETF IP seems to be published with an eternal-use license so all documents must be maintained forever under that mindset it would seem...
I-Ds provide important historical records for the open and transparent
operation of the IETF.
Yes very important point and one which ties the issues of the mandatory term of availability to the archival period...
It should be noted that individuals and groups,
including the IAB and IRTF Research Groups, have chosen to distribute
working documents as I-Ds.
-------------------------
Yes but what happens to the legal assignment for the licensing of the IP
in the I-D for its uses as described therein? Does it persist? Is it
superseded and if so what are the responsibilities in the relying
parties to deal with that?
I-Ds are stored in two places on the IETF web site. First, current I-Ds
are stored in the I-D Repository. Second, current and past I-Ds are
stored in a Public I-D Archive.
The policies associated with I-D Repository are discussed in RFC 2026,
and this IESG statement offers no additional policies regarding the
I-D Repository.
That is the problem RFC2026 and BCP78/79 fail (and intentionally too) to
address this issue to try and make an argument that the IETF is not
accountable for these processes because it has no membership - one of
those famous fictions the IETF was based on... wink nod...
So the real issue is now - in today's world where the sponsor is
accountable - what does all this mean?
As RFC 2026 says, the entries in the I-D Repository are subject to
change or removal at any time; however, I-Ds generally remain in the
Public I-D Archive to support easy comparison with previous versions.
This availability facilitates review, comment, and revision.
An I-D will only be removed from the Public I-D Archive under unusual
circumstances with consensus of the IESG. If you are aware of abuse or
misuse that warrants removal of an I-D from the Public I-D Archive,
please write to iesg@xxxxxxxx and explain the situation. At its
discretion, the IESG may consult counsel or the IETF community before
taking any action on such requests. If circumstances permit, a removed
I-D will be replaced with a tombstone file that describes the reason that
the I-D was removed from the Public I-D Archive.
When an I-D is removed from the Public I-D Archive, a copy will be kept
in a location accessible by the IETF Secretariat. This private location
is described in RFC 2026 as follows:
... Internet-Drafts that
have been removed (for any reason) from the Internet-Drafts
directories shall be archived by the IETF Secretariat for the sole
purpose of preserving an historical record of Internet standards
activity and thus are not retrievable except in special
circumstances.
Again - more smoke and mirrors - please simply answer the question as to
what happens to the legal contract for the use and reprinting of that IP
per RFC2026 and all of the subsequent RFC's on the matter?
The IESG, IAB, IAOC, or the Internet Society Board of Trustees can
request the IETF Secretariat to search this private location in
support of responses to appeals, responses to subpoenas, or other
handling of legal matters.
Minimum Storage Period is Seven Years by US Law... sorry... =
=====================================================
OK, in all other areas for every other tax exempt entity there is a
minimum archive requirement for storage of documents. Since much of the
IETF's operations are supported by effort which is tied to either tax
exempt entities or those using the IETF participation as part of
employee development, it would seem that this same minimum legal
mandatory retention period of seven years would apply to any
workproduct done as part of that process.
Since both ISOC and the parties making those contributions do so under
this banner its just simple logic that QED the IETF Standards Process
was impinged by any legal organization requirements for retention of
documents tied to the charter of that org.
Jorge - since many people use the IETF as part of their tax status
clearly this is true right? Since the IETF itself is claiming Tax Exempt
Status all of its operations under the ISOC would also seem to be tied
for seven years as well... and so many not be an issue which is subject
to negotiation here.
The IETF Secretariat is expected to make
the results of searches of the private location available as needed to
appropriately respond to such matters.
--
Regards TSG
"Ex-Cruce-Leo"
//Confidential Mailing - Please destroy this if you are not the intended recipient.