Re: RFC 5378 "contributions"

Theodore Tso writes: > However, that presumably wouldn't be tree for allowing text or code to > be used in implementations, open source or otherwise --- I assume > that wouldn't require prior permission first, right? Right, but only for code. See section 4 of

Re: Fourth Last Call: draft-housley-tls-authz-extns

Russ Housley writes: > Simon: > >> >>For the people who want this draft published (and perhaps have a pending >> >>implementation), would you please humour me by offering some usage >> >>scenarios, other than debugging or toys, which would meet security >> >>review and which are not covered by th

Re: RFC 5378 "contributions"

- Original Message - From: "Theodore Tso" Sent: Friday, January 16, 2009 1:23 AM > On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: > > > > Consider the threat model here. > > > > This threat applies ONLY to material that the Trust licenses to > > third parties (such as,

Re: RFC 5378 "contributions"

On Jan 16, 2009, at 4:54 AM, Tom.Petch wrote: - Original Message - From: "Theodore Tso" Sent: Friday, January 16, 2009 1:23 AM On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: Consider the threat model here. This threat applies ONLY to material that the Trust lice

Re: RFC 5378 "contributions"

On Jan 15, 2009, at 7:23 PM, Theodore Tso wrote: On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their st

Re: RFC 5378 "contributions"

On Fri, Jan 16, 2009 at 07:04:13AM -0500, Marshall Eubanks wrote: > This raises a question. The IETF publishes relatively little code > compared to the millions of lines of open source code out there. How > do the large open source projects protect and indemnify themselves > and their participants

Re: Fourth Last Call: draft-housley-tls-authz-extns

Simon: >> >>For the people who want this draft published (and perhaps have a pending >> >>implementation), would you please humour me by offering some usage >> >>scenarios, other than debugging or toys, which would meet security >> >>review and which are not covered by the four points which the

Re: RFC 5378 "contributions"

At 16:23 15-01-2009, Theodore Tso wrote: That I think is the key; each person can only warrant what they themselves have authored. Something that might be worth looking at is the Developer's Certification of Origin, which is how Linux Kernel developers deal with contributions for the Linux Kerne

Re: RFC 5378 "contributions"

SM writes: >>which gets incoproated into the kernel must have a Signed-off-by, like >>this: > > The IETF does not use version control to keep track of changes to a > document. Version control is not needed to track changes. > Document changes cannot be compared to code contributions as the > pr

Looking ahead to IETF 76

As promised, I have put together some web pages about Hiroshima. Intended to augment rather than replace any official IETF or local host pages, my pages cover "how to get there" as well as other bits of (hopefully) useful information. I am sure the local host will provide more detailed city info

comments last call IDR draft-ietf-idr-flow-spec-03.txt

I have a few textual nits which I will forward to the authors, however I have an areas of concern in from an implementation perspective. section-3 page 10 paragraph states If a given component type within a prefix in unknown, the prefix in question cannot be used for traffic filtering purp

Re: Fourth Last Call: draft-housley-tls-authz-extns

Russ Housley writes: > EXAMPLE > > Clearance may be the easiest one. For simplicity, let's assume that > the client are server already have X.509 identity certificates. > Assume the server is operated by the military, and it includes some > information that its wants to share with the public, pe