Subject: RE: Last Call: draft-ietf-inch-iodef (The Incident Object Description Exchange Format) to Proposed Standard

From: "patrick cain" <[email-masked]>
Date: Wed, 25 Apr 2007 00:48:53 -0400

ou do not
> require that the comment is placed in all "advertising material", or
> similar, or you will run into the problem that the original BSD
> license had with GPL-compatibility.)
> 

Making the GUL promise costs no money (that part is free); I hope it doesn't
cost anybody any time to _not_ implement the PAS Functions; and I don't want
to make the mechanics of making the request / promise cost a lot of time
either.  But the GUL promise as "valuable consideration" is the cost of the
GUL to Manufacturers.  As far as I can see, it's not ok to omit this.  

I hope many people find the offer attractive.  As I mentioned, I'm open to
suggestions and feedback on the mechanics of making the "request".

> Another basic problem is that free software projects may not be able
> to agree to your field-of-use limitation in (2) and at the same time
> be compatible with license such as the GNU General Public License.
> Thus they would never be able to implement tls-authz even without any
> support for PAS under your license.  I am not certain of this, but I
> could ask the Free Software Foundation's lawyers about this -- they
> are the copyright holder of GnuTLS which implements tls-authz without
> PAS today, and can speak authoritatively about this.

I would appreciate if you would follow up with your lawyer(s) on this
question.  As I've said before, I believe that even if GNUTLS/FSF (for
example) made the GUL promise, its software would continue to be "free to
use" because only GNUTLS (or whatever parent organization) would be bound to
honor that promise.  I hope your lawyers will find this to be true.

Best regards,

mark

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

---

From: "patrick cain" <[email-masked]>
Date: Wed, 25 Apr 2007 00:48:53 -0400

Hi,
I am sorry for the lateness of this message. [According to the tracker I
haven't totally missed my opportunity yet.]
 
I believe that publishing draft-ietf-inch-iodef would greatly benefit the
Internet community. This document defines an XML schema to exchange
information about network incidents (e.g., attacks, disruptions, etc). For a
good chunk of years many people have discussed sharing such information
amongst trusted (or even trustable) peers; many groups have given up
defining an acceptable means as the task is thought of as too hard. Although
multi-year in length, the INCH WG crafted an exchange format that many
organizations find attractive -- it's very flexible, one doesn't need
special tools to code/decode, and it's nearly out the door complete.
Although purists find fault with everything, and I'm by no means unbiased in
this area, I have been surprised by the likely implementers easy acceptance
of the latest version of the doc (nobody seems to raise the worrisome
'technical issues').

Some consortia have even started using it to share incident data which could
imply that the details of the document may actually work. [I'm in a
consortia that is using this document to share network incident data.]

I hope the IESG approves the document for publication as an RFC.

Pat Cain

Subject: RE: Last Call: draft-ietf-inch-iodef (The Incident Object
	Description Exchange Format) to Proposed Standard 
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi,
I am sorry for the lateness of this message. [According to the tracker I
haven't totally missed my opportunity yet.]
 
I believe that publishing draft-ietf-inch-iodef would greatly benefit the
Internet community. This document defines an XML schema to exchange
information about network incidents (e.g., attacks, disruptions, etc). For a
good chunk of years many people have discussed sharing such information
amongst trusted (or even trustable) peers; many groups have given up
defining an acceptable means as the task is thought of as too hard. Although
multi-year in length, the INCH WG crafted an exchange format that many
organizations find attractive -- it's very flexible, one doesn't need
special tools to code/decode, and it's nearly out the door complete.
Although purists find fault with everything, and I'm by no means unbiased in
this area, I have been surprised by the likely implementers easy acceptance
of the latest version of the doc (nobody seems to raise the worrisome
'technical issues').

Some consortia have even started using it to share incident data which could
imply that the details of the document may actually work. [I'm in a
consortia that is using this document to share network incident data.]

I hope the IESG approves the document for publication as an RFC.

Pat Cain