Subject: Re: Third Last Call: draft-housley-tls-authz-extns

From: Bernard Aboba <[email-masked]>
Date: Sun, 30 Sep 2007 08:09:32 -0700 (PDT)

I support the publication of this document as an Experimental RFC.
However, this document raises issues relating to disclosure of IPR and 
affiliation that still need to be dealt with. 

Brian Carpenter said:

"I think the IETF already sent a very strong signal that it won't
close its eyes to late disclosures for standards track documents,
by removing this from the standards track."

Making an example of a document does not constitute development
of a consistent and comprehensive policy on the handling of late
IPR disclosure.  

For example, what happens if IPR disclosure occurs after RFC publication?
This is not an abstract question -- there are cases in which IPR 
disclosure has occurred after a document was published as a Proposed 
Standard - RFC 3588 is an example. 

"It seems like double jeopardy to use this as an argument against Experimental 
status too - as Tim has said, there's nothing in our rules to block publication as
Experimental after an IPR disclosure."

I would agree that the IPR issue is not as relevant to publication of a document
with Experimental status.  However, there is another issue that this document
raises -- affiliation disclosure.  

If we define affiliation as the "individual or entity that has been, or will
be, financially or materially supporting that individual's participation in a
particular standards activity" (the IEEE-SA Bylaws definition), then in this
case the document authors disclose their employers, but not necessarily 
their affiliation. 

While an employer is typically the entity that reports an employee for tax
purposes, in the case of a consultant, the employer and affiliation will 
typically be different. 

I would suggest that the IETF needs an affiliation policy covering disclosure
of affiliation within Internet-Drafts & RFCs, as well as disclosure of
affiliation by members of the IESG, IAB and IAOC. 

An example of an affiliation policy is available here:
http://standards.ieee.org/faqs/affiliationFAQ.html

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Sep 2007 17:53:37 -0700

> Standard - RFC 3588 is an example. 

Short of requiring all contributors to sign something contractual prior to 
publication -- and even that would not provide anything close to perfect 
protection -- what could a policy do to mitigate against this kind of threat 
to the process?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Oct 2007 14:54:23 +1300

On 2007-10-01 13:53, Dave Crocker wrote:
> Short of requiring all contributors to sign something contractual prior 
> to publication -- and even that would not provide anything close to 
> perfect protection -- what could a policy do to mitigate against this 
> kind of threat to the process?

IANAL, but it's my understanding that the prominently displayed Note Well
text already serves this purpose. The real sanction can only be having
a patent struck down by the courts due to intentional failure to
disclose it; all the IETF can do is to make its rules clear enough
for the courts to be able to make such a finding.

Also, our rules are written to apply to contributors personally
and not to require expensive patent searches - in other words, we
accept that patents may be discovered, more or less by chance,
after the standards process is complete. Nothing else is realistic.

I don't see what we need to change. As the current case shows,
we know how to rescind a standards action if appropriate. We
also have the ability under RFC 2026 to demote a standards track
RFC to Historic if appropriate. Since the highest reward the IETF
can offer is standards track status, surely our highest punishment
is removing standards track status?

      Brian