![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Simon,
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>).
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.
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.
In fact, my reading of RFC 2026 indicated two possibilities:
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?
/Simon
Thanks,
Tim Polk _______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.