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]; [EMAIL
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
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
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
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
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
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
--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
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.
rant
This goes to the heart of the current paradigm problem with IETF
decision-making: There is nearly exclusive concern
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
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
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 work.
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 in this
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
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 meritocracy. So
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
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
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
The IESG has approved the following document:
- 'Specifying New Congestion Control Algorithms '
draft-ietf-tsvwg-cc-alt-04.txt as a BCP
This document is the product of the Transport Area Working Group.
The IESG contact persons are Lars Eggert and Magnus Westerlund.
A URL of this
28 matches
Mail list logo
