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

Simon,

I appreciate your thoughtful response.  One overall comment: this  
Last Call
reflects my personal opinion that the document merits publication,  
and no
decision or opinion should be inferred with respect to other members  
of the
IESG.  My further comments/responses are inline...

On Sep 25, 2007, at 21:50, Simon Josefsson wrote:
>
> The IESG <iesg-secretary <at> ietf.org> writes:
>
>> The IESG is considering approving this draft as an experimental track
>> RFC with knowledge of the IPR disclosure from Redphone Security.
>
> There are two other relevant IPR disclosures:
>
> https://datatracker.ietf.org/ipr/808/
>
> https://datatracker.ietf.org/ipr/806/
>
>> The IESG solicits final comments on whether the IETF community has
>> consensus to publish draft-housley-tls-authz-extns as an experimental
>> standard given the IPR claimed. Comments can be sent to ietf <at> ietf.org
>> or exceptionally to iesg <at> ietf.org. Comments should be sent by
>> 2007-10-23.
>
> I was negative to publication during the earlier last calls, and I
> continue to be so.  The primary reason remains the uncertainty of the
> IPR situation.  It is not clear to me that I can implement this  
> protocol
> freely without the burden of patent licenses.  I'm speaking as a free
> software implementer of this document (see GnuTLS, <www.gnutls.org>).

As the sponsoring AD, I would like to explain why I support publication
as an Experimental 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.” Given the technical merits of  
the
document and the existence of independent implementations, I believe
it is in the interest of the community to have an archival record of  
this work.

I am not a lawyer, so any comments I might offer with respect to the
applicability of the various IPR disclosure statements filed on authz  
would
be useless.  However, I do not believe the uncertainty of the IPR  
situation
precludes publication as an Experimental RFC.

>
> Further, as far as I could determine, there was a lack of consensus to
> support this document when it was discussed here and in the TLS WG
> earlier.  I encourage the IESG to review those discussions.

There was consensus *supporting* publication of this document as a  
Proposed
Standards in its first Last Call.  That consensus evaporated once the  
IPR issues
surfaced, but the discussions focused solely on the IPR and the process.

The TLS WG declined to pick up authz as a working group deliverable,
but did not recommend against publication as conflicting work.  The  
wg had
only minor comments on the technical content.  No alternatives were  
proposed
or considered.

>
> RFC 2026 says:
>
>    To ensure that the non-standards track Experimental and  
> Informational
>    designations are not misused to circumvent the Internet Standards
>    Process, the IESG and the RFC Editor have agreed that the RFC  
> Editor
>    will refer to the IESG any document submitted for Experimental or
>    Informational publication which, in the opinion of the RFC Editor,
>    may be related to work being done, or expected to be done,  
> within the
>    IETF community.  The IESG shall review such a referred document
>    within a reasonable period of time, and recommend either that it be
>    published as originally submitted or referred to the IETF as a
>    contribution to the Internet Standards Process.
>
> What was the IESG's recommendation after that review?
>

Given that the TLS wg declined to pursue work in this area, I do not
see any conflict between authz and work being done, or expected to be
done, within the IETF community.

This document was not submitted to the RFC Editor for publication,
so the IESG did not perform that review.

> Given that the initial last call was to put the document on the
> standards track, my impression would be that this last call request  
> for
> the experimental track is indeed intended to circumvent the normal
> process.
>

I am not a expert on process (in the IETF or anywhere else) but I  
believe
that considering the document for publication as Experimental after a  
failed
Last Call for standards track publication is permitted.

In fact, my reading of RFC 2026 indicated 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.”

(2) I could request a third IETF Last Call for consideration as an  
experimental
track document.

Frankly, neither option was ideal.  Going straight to the IESG would  
have been
most efficient, but it didn't feel right to me.   Having a third Last  
Call seems kind
of pointless, since we haven’t identified any technical issues during  
the first two
rounds.

I chose to pursue the second path since it provides an opportunity to  
clearly
determine whether sufficient support for publication in the  
Experimental track
exists even with the IPR situation.

> FYI, RFC 2026 continues:
>
>    If (a) the IESG recommends that the document be brought within the
>    IETF and progressed within the IETF context, but the author  
> declines
>    to do so, or (b) the IESG considers that the document proposes
>    something that conflicts with, or is actually inimical to, an
>    established IETF effort, the document may still be published as an
>    Experimental or Informational RFC.  In these cases, however, the  
> IESG
>    may insert appropriate "disclaimer" text into the RFC either in or
>    immediately following the "Status of this Memo" section in order to
>    make the circumstances of its publication clear to readers.
>
> Will the document have an IESG note?

While this document *is* being processed within the IETF context as  
an AD
sponsored submission, and I do not see any conflict with existing work,
the IESG could choose to insert a note if they desired.  I have not  
proposed
attaching a note at this time.

>
> /Simon

Thanks,

Tim Polk