Thomas,
Sorry for the delay in responding to this. I think you have
misunderstood my position (although maybe not the position of
others). See below.
--On Tuesday, 12 June, 2007 12:25 -0700 Thomas Narten
[EMAIL PROTECTED] wrote:
...
And that last clause -- i.e., the fact that document has
Thomas Narten wrote:
If the above text were in effect today, would it be sufficient to
cover the situation at issue here? (Now would be an excellent time
to consider updates/clarifications to the above text.)
I don't think so. The text allows IESG to override the allocation
procedures when
Date:Thu, 14 Jun 2007 17:08:13 -0700
From:Thomas Narten [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| (Now would be an excellent time to
| consider updates/clarifications to the above text.)
Aside from the minor problem that the paragraph you quoted is way
.
Donald
-Original Message-
From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 13, 2007 4:54 PM
To: Russ Housley; John C Klensin; ietf@ietf.org
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Withdrawing sponsorship of draft-housley-tls-authz-extns
One
Nothing prevents the document from being submitted directly to
the RFC Editor, for publication as a non-IETF document.
That is the avenue I would prefer, but it raises another issue
(which I think would fall into the category Eliot referred to as
a corner in the process). As Sam points
One possibility, if one wants to get things through without modifying
current process, is to:
a) publish the specification as an independent submission
b) publish an one-line document, with IETF consensus, saying that the
codepoint x is for use with protocol Y, which is not an IETF protocol.
: 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 seems to me that this draft has hit some corners in the process, but
I would point out that Sam is not the only one who can sponsor the
thing, and if nobody else stands up and sponsors it, that would be a
good indication that perhaps more work is needed prior to IESG approval.
Eliot Lear wrote:
It seems to me that this draft has hit some corners in the process, but
I would point out that Sam is not the only one who can sponsor the
thing, and if nobody else stands up and sponsors it, that would be a
good indication that perhaps more work is needed prior to IESG
On Tue, 12 Jun 2007, Dave Crocker wrote:
Nothing prevents the document from being submitted directly to the RFC Editor,
for publication as a non-IETF document.
... except that TLS extensions require IETF consensus ...
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
FORTIES CROMARTY
Tony Finch wrote:
On Tue, 12 Jun 2007, Dave Crocker wrote:
Nothing prevents the document from being submitted directly to the RFC Editor,
for publication as a non-IETF document.
... except that TLS extensions require IETF consensus ...
mumble... grrr... yeah... mumble...
waffle: I
--On Tuesday, June 12, 2007 07:11 -0700 Dave Crocker
[EMAIL PROTECTED] wrote:
To obtain IETF approval, there needs to be a sponsoring AD.
Sam explained why he feels he cannot fill that role any
longer. Whether some other AD feels can can serve in his
stead is their individual decision. We
John,
I'm not sure whether I agree with your proposal or not, but I think
the most concrete way forward would be a proposal for specific
wording for draft-narten-iana-considerations-rfc2434bis, which
Harald left on my plate and I left for Russ.
Brian
On 2007-06-12 17:11, John C Klensin
--On Tuesday, June 12, 2007 17:22 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
John,
I'm not sure whether I agree with your proposal or not, but I
think
the most concrete way forward would be a proposal for specific
wording for draft-narten-iana-considerations-rfc2434bis, which
Harald
I'm not sure whether I agree with your proposal or not, but I
think
the most concrete way forward would be a proposal for specific
wording for draft-narten-iana-considerations-rfc2434bis, which
Harald left on my plate and I left for Russ.
That document is pretty much done. Indeed, it
p == [EMAIL PROTECTED] writes:
p Sam,
p While it is at each AD's discretion not to sponsor some
p document (and not initiate Standards Action), I don't think
p this discretion should extend to having a veto at the IESG
p table when the document and community input is
There is one thing that needs to be highlighted at this
point. John's message come close to saying it, but it falls short.
There are at least two implementations of this TLS authorization
extension. These implementations use the code point that was
assigned by IANA while this document was
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,
18 matches
Mail list logo
