Date: Mon, 27 Aug 2007 12:47:58 -0400
From: Tim Polk <tim.polk@nist.gov>
To: Dean Anderson <dean@av8.com>
Subject: future of tls-authz

    [ The following text is in the "WINDOWS-1252" character set. ]
    [ Your display is set for the "ISO-8859-1" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Dean,

I don^Òt believe we have met, but I joined the IESG as an Area  
Director for Security in March.  As part of my duties as AD, I am  
considering sponsor the tls-authz draft for consideration as an  
Experimental track RFC.  Given the complexity of the situation, I  
would appreciate your input before I proceed.

As a new AD, I would prefer not to pick up tls-authz ^Ö this job is  
hard enough without seeking controversy!  However, I am convinced of  
the technical merits of the document, and believe it should be  
published as an RFC.  As the AD for TLS, the responsibility to  
progress the document falls squarely on my shoulders.

In addition to the technical contents of the document, I factored the  
existence of independent implementations and the murky IPR situation  
into my deliberations.  Given all of the inputs, I have come to the  
conclusion that tls-authz is appropriate for publication as an  
experimental track RFC.  To quote RFC 2026, ^ÓSuch a specification is  
published for the general information of the Internet technical  
community and as an archival record of the work.^Ô   I believe that  
the TLS working group^Òs review of the document satisfies the  
requirement for ^Óadequate coordination with the standards process.^Ô   
While some have advocated standards track for this specification, I  
do not believe that all the properties of a proposed standard are  
satisfied by the document.  Specifically, it is not clear if the  
document ^Óappears to enjoy enough community interest to be considered  
valuable^Ô in light of the IPR issues.

I am having a little trouble sorting out the applicable procedures  
from this starting point, though.  My reading of RFC 2026 indicates  
two possibilities:

(1) Under section 6.1.2, I could request IESG approval as an  
Experimental RFC based on the results of the second IETF Last Call  
for progression on standards track.  ^ÓThe IESG could also decide to  
change the publication category based on the response to a Last- 
Call.^Ô  This process would be most efficient, but the optics are not  
optimal.

(2) I could request a third IETF Last Call for consideration as an  
experimental track document.  I simply hate the idea of a third Last  
Call for this document, since we haven^Òt identified any technical  
issues during the first two rounds, but this would provide an  
opportunity to clearly demonstrate that sufficient support for  
publication in the Experimental track exists even with the IPR  
situation.

Given that alternative technical proposals have not been submitted,  
and the TLS working group is not interested in taking this document  
on, I don^Òt see any other mechanism to complete this work.

I would greatly value your input on the two processes I outlined  
above.  Which of these processes would be most appropriate in your  
opinion, given this starting point?  Does an alternative process  
exist that I have overlooked?   I would be happy to have this  
dialogue by email, or we could chat on the phone if you prefer.  (My  
office number is 301-975-3348.)  If you prefer a phone conversation,  
we should probably schedule a time and avoid playing phone tag.  I am  
currently available before 11:30 AM on Thursday the 30th, or anytime  
on Friday the 31st.

There is one additional issue I would like to highlight in this  
email. Russ Housley and I are good friends and our families get  
together socially a couple of times each year.  We have co-authored a  
number of IETF documents during the past decade, as well as the book  
^ÓPlanning For PKI^Ô.   While this was not a factor in my consideration  
of tls-authz, I would not want you to think I was hiding our friendship!

Thanks,

Tim Polk