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 ha
point.
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
<[EMAIL PROTECTED]> writes:
> 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 o
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
On 2007-06-15 10:25, [EMAIL PROTECTED] wrote:
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
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
> > 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
> ). As Sam points out, the actual
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".
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 in
> "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 i
> > 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. Inde
--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
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 wrot
--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.
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 didn
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 CROM
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 appr
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.
_
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 IES
19 matches
Mail list logo
