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@xxxxxxx]
> Sent: 12 June, 2007 01:57
> To: ietf@xxxxxxxx
> Cc: mark.brown@xxxxxxxxxxxxxxxxxxxx; iesg@xxxxxxxx
> 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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf