Thanks Rajeev for the quick rsponse. The modifications look good to me.
Ciao
Hannes
> -Ursprüngliche Nachricht-
> Von: Rajeev Koodli [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 11. Juni 2007 22:53
> An: ext Jari Arkko
> Cc: Perkins, Charles (NSN, US/Palo Alto);
> [EMAIL PROTECTED]; [
Thanks -- I added the relevant RFC Editor notes for
this.
(I'm still awaiting IANA's OK to proceed with the
approval of the document. We've answered their
questions but I want to make sure that the
answers were satisfactory from their point of
view.)
Jari
Tschofenig, Hannes kirjoitti:
> Thanks R
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
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 appr
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
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 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.
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
John C Klensin wrote:
> There may be things that make this particular case special, but, for the
general case, I have gradually come to think that model is broken. The
problem is that the IETF cannot _prevent_ someone from making up a
parameter and using it, registered or not, nor can we pun
At 5:22 PM +0200 6/12/07, Brian E Carpenter wrote:
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.
This
--On Tuesday, June 12, 2007 08:26 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
I think the incremental suggestion, here, translates into
permitting the IESG to attach a comment to an IANA
registration entry, much as it can for an Independent RFC
document submission?
I think that's a pretty
John C Klensin wrote:
Again, there may be exceptions, but I think denial cases should require
fairly strong (and public) justification. In the general case, I
believe the Internet is better off if even the most terrible of ideas is
well-documents and registered --with appropriate warnings an
--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. Inde
Thomas Narten wrote:
... I do believe
that withholding code points does prevent (in some, but not all cases)
use of extensions that are potentially problematical.
This goes to the heart of the current paradigm problem with IETF
decision-making: There is nearly exclusive concern about pr
> "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
At 12:25 PM -0700 6/12/07, Thomas Narten wrote:
Some general comments on this thread. I understand the argument that
some make that we should just give out code points in all cases,
because otherwise we invite squatting.
That is one reason to give out code points liberally, but not the
only on
Folks,
If you want the history of this thread, please see the SAAG mailing list
archive.
Thomas,
Your ideas that the "IETF is a meritocracy" and that "I* opinions are
afforded special status" are to say the least worry me. How do those, I
wonder, fit with what's written in the IETF mission
On 6/12/07 3:17 PM, "Lakshminath Dondeti" <[EMAIL PROTECTED]> wrote:
> They are judges of consensus when
> appropriate and the consensus better be independently verifiable. In
> the end, the entire process works with the IETF Community's consensus
> where the IAB and the IESG get to prioritize the
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
Lakshminath> Folks, If you want the history of this thread, please
Lakshminath> see the SAAG mailing list archive.
Lakshminath> Thomas,
To be clear I'm not sure that I* opinions have been given special
treatment i
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
I don't disagree. I do not claim that this is necessarily binding to
any specific incident in the IETF. I removed the ifare tag line from
the subject. I want the issue discussed at a much higher level than any
one decision. Individual decisions have state associated with them, and
we don't
>>
>>Yes, I* opinions are afforded special status. They are our chosen
>>leadership, and with leadership comes responsibility. Responsibility
>>to be sure that if the work goes forward, it is well scoped, has a
>>reasonable likelyhood of success, etc. And please remember, the IETF
>>is a meritocrac
I may well be misreading Lakshminath below.
But the note as written seems to say that ADs are only supposed to
judge consensus.
That misses important parts of the point.
They are also selected for technical judgement, and expected to use
that judgement.
So, for example, an AD is NOT required to
We trust the IESG not only to judge consensus but also to provide
technical mentoring and leadership. We trust the IAB not only to
arbitrate in case of disagreement about consensus but also to
provide architectural insight and leadership.
Yes, that gives them a special status. It's called 'primus
I understand the technical judgment argument, but I see a lot of
practical issues with it. First, an AD (or an IAB member) may not be an
expert in all the topics under review; in fact it is probably unfair to
assume that they are. Some of them seek help from the community (hear
both sides of
My education did not include Latin, but Wikipedia says there are several
kinds of "Firsts among equals." One example is a 'president' and
another is a 'chair of an organization.' Surely the first is not inline
with our famous saying
"We do not believe in kings, presidents, or voting.
We beli
28 matches
Mail list logo