Sam,
I'm quite disappointed with the way you chose to handle this.
I do agree with your assessment that we do not, at this time,
have rough consensus to publish this on Standards Track.
However, based on the public comments I have seen (obviously,
I have not seen comments sent only to the IESG), significantly
more people supported publishing this (in some form) than were
totally opposed to publishing. I find it totally plausible that
someone could interprete this as rough consensus for publishing
this as a non-Standards Track RFC.
Since the Standards Action has been initiated, and the document
has gone through IETF last call, I think the decisions about the
Standards Action (whether to publish this or not, at what
status, with what changes) should be made by the IESG as a
whole, not solely by the sponsoring AD.
While it is at each AD's discretion not to sponsor some document
(and not initiate Standards Action), I don't think this
discretion should extend to having a veto at the IESG table
when the document and community input is considered ("if you
make changes I don't like, I'll withdraw my sponsorship").
It looks like our process rules don't really cover the case of
withdrawing sponsorship, but the existing IESG decision-making
process already allows an AD to object to publishing a document,
and I believe using a "sponsorship-withdrawal-veto" instead is
inappropriate.
I ask you to consider putting this document back on the IESG
table, allowing each AD evaluate the document and community
input received during the IETF Last Call (and determine the
consensus or lack of it), and ballot accordingly.
Whatever the outcome is, I strongly believe this is not a
decision you should make alone, and doing so would violate
the spirit of RFC 2026 and RFC 3710: in Standards Action,
the consensus is judged by all Area Directors, not any
single person alone.
Best regards,
Pasi
-----Original Message-----
From: ext Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: 12 June, 2007 01:57
To: ietf(_at_)ietf(_dot_)org
Cc: mark(_dot_)brown(_at_)redphonesecurity(_dot_)com; iesg(_at_)ietf(_dot_)org
Subject: Withdrawing sponsorship of draft-housley-tls-authz-extns
Folks, after the various IPR disclosures were filed on
draft-housley-tls-authz-extns, I asked for a second IETF last call to
see if we had consensus to publish this document on the standards
track given the IPR claims against it.
That last call did not show the consensus I was looking for. So, we
agreed we were going to send mail to the TLS working group and ask
them for their comments on publishing the draft. We hoped that we'd
see a consensus there. The chairs did ask for comments; see
http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html .
Comments were provided, but there was not a consensus in favor of
publication on the standards track either there or on the ietf list.
I think there is a rough consensus against publication on the
standards track. However it is quite clear that there is not a rough
consensus in favor of publication on the standards track which would
be required to do so.
So, I am withdrawing my sponsorship of the draft and as far as the
IETF process is concerned this draft is no longer under consideration
for publication.
One option that several people suggested is publication as an
informational spec. I personally do not choose to sponsor this
document for informational or experimental. often, it seems that we
use informational as a way to publish things we cannot build a strong
consensus behind. I think that process is generally problematic and
would like to avoid it in this instance. Other ADs may consider
sponsoring this document as an informational document; I would ask
them to carefully consider whether that is the best use of the time
they have to offer the IETF community. My conclusion is that for me
personally, it is not.
Publishing this document via the rfc editor independent submissions
track is basically not an option because the IANA assignments require
IETF consensus or standards action.
That leaves the authors with several options:
* Work with people to build consensus and try again later. Possibly
working on discovering prior art or trying to revise the licensing
terms. There should be a much higher bar for starting the process a
second time, but perhaps that bar can be met.
* Work on an alternative that does not have the IPR constraints.
* Work on finding another AD to sponsor the document. I will not do
so, and I'd advise my fellow ADs to think for a long time before
taking on this draft, but I would not block another AD sponsoring
the draft.
* Rewrite this document as a sketch of what might be done
rather than a protocol and go through the independent
submissions track.
* Drop the proposal.
I'm sad that we have come to this point. I think this technology has
significant value and wish we'd found a way to publish it. However we
follow a consensus process for many valuable reasons and it is clear
that the necessary consensus is not present in this case.
Sam Hartman
Security Area Director
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf