Alexey Melnikov said:
This statement taken in isolation is certainly correct. However if the
original LC didn't ask the right question, don't you think this makes
answers meaningless?
The reviews are not meaningless. They represent the feedback of the IETF
community. Rather than asking a
Bernard,
I agree with EKR here. Failed consensus is failed consensus. RFC 2026
does not support the process that has been recommended here.
Perhaps Sam and Lisa can explain a bit more as to what process they
intend to use. It seems that Alexey is providing a forum for discussion
to
Hi Bernard,
Bernard Aboba wrote:
Alexey Melnikov said:
This statement taken in isolation is certainly correct. However if the
original LC didn't ask the right question, don't you think this makes
answers meaningless?
The reviews are not meaningless.
I didn't say that reviews were
Eliot Lear wrote:
Bernard,
I agree with EKR here. Failed consensus is failed consensus. RFC
2026 does not support the process that has been recommended here.
Perhaps Sam and Lisa can explain a bit more as to what process they
intend to use. It seems that Alexey is providing a forum
I'm a bit wary to step in this discussion, but anyway. Here's a little
input from an operator who has been using various variants of Netflow
over the years. Netflow is rather like IPFIX over UDP as far as
congestion (non-)handling is concerned.
Lars Eggert writes:
On 2007-9-6, at 14:51, ext
...
[gwz]
(I wonder how much the costs would go down if the meeting ended at 4PM
Thursday
instead of noon on Friday, and there was only one plenary night on
Wednesday.)
[gwz]
[gwz] Probably not at all. I only have experience with sponsoring one IETF,
but in that case ( I believe generally) the
[mailto:[EMAIL PROTECTED] On Behalf
Of Eliot Lear
Perhaps Sam and Lisa can explain a bit more as to what
process they intend to use. It seems that Alexey is
providing a forum for discussion to improve the document, and
I see nothing wrong with that. I would imagine that both the
At Mon, 10 Sep 2007 08:59:57 +0200,
Eliot Lear wrote:
Bernard,
I agree with EKR here. Failed consensus is failed consensus. RFC 2026
does not support the process that has been recommended here.
Perhaps Sam and Lisa can explain a bit more as to what process they
intend to
I agree with Phillips comments and the FSTC stands ready to help
-Original Message-
From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
Sent: Monday, September 10, 2007 9:21 AM
To: Eliot Lear; IETF Discussion; [EMAIL PROTECTED]
Subject: RE: [Ietf-http-auth] Re: Next step on web
Eric,
Eric Rescorla wrote:
At Mon, 10 Sep 2007 08:59:57 +0200,
Eliot Lear wrote:
Bernard,
I agree with EKR here. Failed consensus is failed consensus. RFC 2026
does not support the process that has been recommended here.
Perhaps Sam and Lisa can explain a bit more as to
Alexey Melnikov wrote:
IMHO, it also might be appropriate to find a better forum and process
for discussing and moving forward on this document. The topic is
important, and one that the IETF has an opportunity to make a
contribution to, over time. I think this may be a case where the
At Mon, 10 Sep 2007 18:21:36 +0100,
Alexey Melnikov wrote:
Subsequent discussions and consensus calls on the document
would happen on [EMAIL PROTECTED].
...
Alexey,
in my capacity of shepherd for draft-hartman-webauth-phishing
On rereading my message, it
Eric Rescorla wrote:
Hmm... I'm still not sure what you're trying to say. My point is
that there shouldn't be any consensus calls by anyone on the
ietf-http-auth mailing list. It's not a WG.
Eric:
It sounds to me as if you are attempting to claim that only official
IETF activities are
On Mon, Sep 10, 2007 at 11:29:46AM -0700, Eric Rescorla wrote:
At Mon, 10 Sep 2007 18:21:36 +0100,
Alexey Melnikov wrote:
On rereading my message, it probably came out stronger than I intended.
But according to my English-Russian dictionary the verb would can
convey polite request, which
At Mon, 10 Sep 2007 14:45:26 -0400,
Jeffrey Altman wrote:
Eric Rescorla wrote:
Hmm... I'm still not sure what you're trying to say. My point is
that there shouldn't be any consensus calls by anyone on the
ietf-http-auth mailing list. It's not a WG.
Eric:
It sounds to me as if you
Hi,
I'm going to be mostly on vacation from August 27th to 30th, and fully on
vacation
from August 31st to September 10th. During this period, email responses will be
sporadic and random ;-)
I'll be sure to read your mail concerning Posting of
draft-ietf-mip4-nemo-v4-base-01.txt when I'm
On Mon, Sep 10, 2007 at 01:52:00PM -0500, Nicolas Williams wrote:
But this draft does have a formal _state_: IESG Evaluation :: Revised
ID Needed.
It's state seems to be that it has not exactly failed IETF LC (e.g., one
IESG member commented that [i]t is my educated guess there is rough
On Mon Sep 10 19:51:07 2007, Eric Rescorla wrote:
At Mon, 10 Sep 2007 14:45:26 -0400,
Jeffrey Altman wrote:
Eric Rescorla wrote:
Hmm... I'm still not sure what you're trying to say. My point
is
that there shouldn't be any consensus calls by anyone on the
ietf-http-auth mailing list.
At Mon, 10 Sep 2007 13:52:00 -0500,
Nicolas Williams wrote:
On Mon, Sep 10, 2007 at 11:29:46AM -0700, Eric Rescorla wrote:
At Mon, 10 Sep 2007 18:21:36 +0100,
Alexey Melnikov wrote:
On rereading my message, it probably came out stronger than I intended.
But according to my
On Mon, Sep 10, 2007 at 11:56:15AM -0700, Eric Rescorla wrote:
At Mon, 10 Sep 2007 13:52:00 -0500,
Nicolas Williams wrote:
Are you saying that a design team can't have consensus or consensus
calls? Surely they can, though consensus internal to design teams
cannot, and, indeed, must not be
Not at all. There is a huge difference between ask participants
in a discussion what they think and a consensus call.
I've frequently seen postings that talk about the consensus
of a Bar BoF, and never seen any objection to that terminology.
Consensus is always qualified by the scope of the
On rereading my message, it probably came out stronger than I intended.
But according to my English-Russian dictionary the verb would can
convey polite request, which was my intent.
Hmm... I'm still not sure what you're trying to say. My point is
that there shouldn't be any consensus
At Mon, 10 Sep 2007 20:27:54 +0100,
Dave Cridland wrote:
So you also want a different word to shepherding?
No. I want there not to be an implication that the development
of this document is a formal activity of the IETF.
If you're saying you think there ought to be a BOF, that's a
On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla
[EMAIL PROTECTED] wrote:
Alexey wrote:
This message is trying to summarize recent discussions on
draft-hartman-webauth-phishing-05.txt.
Several people voiced their support for the document (on IETF mailing
list and in various
Not at all. There is a huge difference between ask participants
in a discussion what they think and a consensus call.
I've frequently seen postings that talk about the consensus
of a Bar BoF, and never seen any objection to that terminology.
Consensus is always qualified by the scope of
I have a few questions about this proposal:
- to what extent is a SG allowed to frame the problem to be solved in a
way that would constrain a later WG if one were chartered? it's clear
that they're not supposed to develop protocol specs, but what about
requirements? goals? models of
Bernard,
I quickly looked through your draft. I don't think it applies for a case when
there is no intention to form a WG. Is my understanding correct?
Section 2 says:
The Charter for a Study Group SHOULD include at least the following
milestones:
o Development of a Working Group
Hmm... I'm still not sure what you're trying to say. My point
is that there shouldn't be any consensus calls by anyone on
the ietf-http-auth mailing list.
Why not? Does the IETF have a patent on IETF processes?
It's not a WG.
Why not?
Of course, you probably mean that any consensus
So you also want a different word to shepherding?
No. I want there not to be an implication that the
development of this document is a formal activity of the IETF.
Let me give you a short lesson from IETF 101.
If the name of a draft contains ietf as the second component, or the
name of an
Wearing my co-author of the Tao of the IETF hat...
At 11:53 PM +0100 9/10/07, [EMAIL PROTECTED] wrote:
Let me give you a short lesson from IETF 101.
Erm, no such document exists.
If the name of a draft contains ietf as the second component, or the
name of an IETF WG or the name of one of
Chris == Chris Drake [EMAIL PROTECTED] writes:
Chris Hi Alexey,
And if you would like to suggest a better process for moving
things forward, please share your opinion.
Chris Suggest: Properly document comments and reviews somewhere.
Chris Question: what's the best way to
Michael Dillon said:
Personally, I would like to see some more criticism of the fact that
this draft is about Phishing, a symptom of security problems, rather
than about strengthening a weakness in Internet security. It is entirely
possible to solve the phishing problem without strengthening the
FWIW
Wearing my co-author of the Tao of the IETF hat...
At 11:53 PM +0100 9/10/07, [EMAIL PROTECTED] wrote:
If the name of a draft contains ietf as the second component, or the
name of an IETF WG or the name of one of the IETF bodies (iab, irtf,
etc...) then it is a formal activity of the
Keith,
I have a few questions about this proposal:
- to what extent is a SG allowed to frame the problem to be solved in a
way that would constrain a later WG if one were chartered? it's clear
that they're not supposed to develop protocol specs, but what about
requirements? goals? models
okay, just to be clear - I'm not sure it should be assumed that SGs
follow the same rules as for WGs - especially if SGs can be closed or
invitation only like design teams can.
I like openness, but I also recognize that the IETF culture tends to
interpret openness broadly enough to mean that
The Ethernet Interfaces and Hub MIB (hubmib) in the Operations and
Management Area has concluded.
The IESG contact persons are Ronald Bonica and Dan Romascanu.
The mailing list will remain active for the time being in order to
accommodate discussions related to the publication of the efm-cu-mib
The Internet Emergency Preparedness (ieprep) in the Real-time
Applications and Infrastructure Area has concluded.
The IESG contact persons are Cullen Jennings and Jon Peterson.
Following the publication of RFC4958 this summer, the IEPREP working
group has completed all of its chartered
The IESG has received a request from an individual submitter to consider
the following document:
- 'Experiment in Study Group Formation within the Internet Engineering
Task Force (IETF) '
draft-aboba-sg-experiment-02.txt as an Experimental RFC
The IESG plans to make a decision in the next
The IESG has received a request from the IP over Cable Data Network WG
(ipcdn) to consider the following document:
- 'Signaling MIB for PacketCable and IPCablecom Multimedia Terminal
Adapters (MTAs) '
draft-ietf-ipcdn-pktc-signaling-15.txt as a Proposed Standard
The IESG plans to make a
The IESG has received a request from the IP Version 6 Working Group WG
(ipv6) to consider the following document:
- 'Deprecation of Type 0 Routing Headers in IPv6 '
draft-ietf-ipv6-deprecate-rh0-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Overview of the Internet Multicast Routing Architecture '
draft-ietf-mboned-routingarch-09.txt as a BCP
If approved, this memo obsoletes the following RFCs:
3913,2189,2201,1584,1585
41 matches
Mail list logo
