Subject: Question about the Parole Evidence Rule and how it relates to the documents we have now...

From: "todd glassey" <[email-masked]>
Date: Tue, 15 Aug 2006 16:35:59 -0700

One of the key issues with contracts is when they are spread out across
multiple documents there needs to be some formal reference to the contract
component in the agreement that is executed whether by implication or act.

This means that there is reason to refer to each and every specific IETF
document that are required to make an Informed Consent Decision about
submission of IP to the publishers of the IETF.

What I am proposing is adding a Document Map section to each BCP related to
IP showing which other documents it is tied to or effects...

If this sounds cumbersome - the other option is to reduce these all to a
single document - which is nothing but a contract instead of a contract and
a description of everything around the contract but the contact itself,  as
the current document set is setup as.

Jorge?

Todd Glassey

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

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 Aug 2006 17:00:10 -0700

FYI - we need to add a receipt tacking method to the document publishing
process so that the rights that are being granted back to the submitter are
documented somewhere.

Think about this - how do you know what rights you got back from a
submission? This is important since the IETF's contracts are
ever-changing arrays of documents, so how could reasonably speaking anyone
keep track of the rights they were supposed to get. Which version of RFC
XXXX, RFC YYYY, and RFC ZZZZ were in force at the time of this
submission???.

With regard to RFC's being used to
tune and change IETF process...
--------------------------------
Also there is a problem that the IETF is probably not aware of  - but when
a Contract Component Document is revised it formally needs to say that it
replaces the previous version in its opening statement. The problem is that
IETF RFC's don't really ever expire and without some specific statement that
it was no longer reference and had been formally retired, someone could
easily say "I want rev x of Doc 1 and rev y of doc 2" etc. This may sound
petty but its about clean up...

The problem is that the IETF cannot reasonably refuse to publish under
those terms as well, or it would likely face litigation. Something everyone
wants to avoid here.

That said - seems like it might be a reasonable addition to RFC's
that alter any of the ISOC suborganization's they are setup to provide
governance for, that they formally have statements that they by their
publishing revise and replace the previous version and that those
previous terms are now superseded by this new publication. And
that set of statements is how the ISOC Board and the other
boards below it certify and announce their publication of a new set
of Governance Terms and Conditions for the Entity in question.

Todd