Ralph Droms wrote:
Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:
Secretariat generates a list of eligible volunteers as early as possible
(As far as I know, eligibility data is available well before call for
volunteers is posted)
List is
On Thu, 7 Sep 2006, Stewart Bryant wrote:
The nomcom pool is in my view very much at the low water mark So an
extension to Ralph's idea would be for the Secretatiat to send a direct
mail to all those who are eligable to say that they are eligable for this
important task and invite them to
On Tue, 5 Sep 2006, Sam Hartman wrote:
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka On Fri, 1 Sep 2006, Sam Hartman wrote:
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka I do not agree with the assessment that there is community
Pekka consensus to turn this to BCP
I read this document and in general I believe that it's well and clear
written. I have a couple of technical issues and a few editorial nits
1. The document is sharing allocation space and refers in several places
to [LSP-Ping] which is also listed as a Normative Reference. I could not
however
On Wed, Sep 06, 2006 at 06:29:57PM -0400,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 22 lines which said:
1. The Information Sciences Institute, University of Southern California,
Marina del Ray, California, USA, the incumbent
...
Ray Pelletier
Phil Regnauld reported that
Ned Eliot - why fix the process??? - lets just turn the IETF into a
democracy and every member gets a vote.and that way the process isn't
needed.
ISOC members should probably also get to vote eh?
Todd
- Original Message -
From: Ned Freed [EMAIL PROTECTED]
To: Eliot Lear [EMAIL
1) if i read this right, it is a way for one lsr to ask another
lsr to test the first lsr's data path -- can someone tell
me if i am working ok?. _if_ my interpretation is right
(and it is monday morning and not all the little gray cells
are at 100% efficiency yet), it seems that
On Wed, Sep 06, 2006 at 06:08:08PM +0200, Brian E Carpenter wrote:
Dave Crocker wrote:
Brian E Carpenter wrote:
This isn't a call for bureaucracy, but for precision. As this year's
glitch
shows, extreme precision is needed in the rules.
Interesting. What it showed me is that we
ietf has members? when did that happen Todd?
--bill (checking for his membership card, reviewing tax records for missed
membership dues, etc...)
On Thu, Sep 07, 2006 at 09:10:41AM -0700, todd glassey wrote:
Ned Eliot - why fix the process??? - lets just turn the IETF into a
On Wed, Sep 06, 2006 at 10:43:48AM -0700, Hallam-Baker, Phillip wrote:
Just to clarify here there were two problems:
1) The list was not published on time
2) There was an unqualified person on the list.
er... there might have been a third problem, qualified people were
On Sep 7, 2006, at 11:15 AM, Stephane Bortzmeyer wrote:
On Wed, Sep 06, 2006 at 06:29:57PM -0400,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 22 lines which said:
1. The Information Sciences Institute, University of Southern
California,
Marina del Ray, California, USA, the
--On Wednesday, 06 September, 2006 13:35 +0200 Frank Ellermann
[EMAIL PROTECTED] wrote:
Brian E Carpenter wrote:
3464 is already DS according to the RFC Index.
Good, the process works, unlike my memory: I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so
At 01:36 PM 9/7/2006, John C Klensin wrote:
Actually, that topic opens up one of the fundamental issues with
our standards process ... one where better definition and clear
community consensus is, IMO, needed. Measured by our documented
criteria, 2195 exists in multiple independent
John C Klensin wrote:
that topic opens up one of the fundamental issues with our
standards process ... one where better definition and clear
community consensus is, IMO, needed.
Fundamental and consensus sounds dangerous, see subject.
2195 exists in multiple independent implementations,
--On Thursday, 07 September, 2006 14:31 -0700 Kurt D. Zeilenga
[EMAIL PROTECTED] wrote:
At 01:36 PM 9/7/2006, John C Klensin wrote:
Actually, that topic opens up one of the fundamental issues
with our standards process ... one where better definition
and clear community consensus is, IMO,
Kurt D. Zeilenga wrote:
implementations of RFC 2195 suffer from interoperability
problems due to its failure to specify a character
set/encoding
The challenge has the syntactical form of an RFC 822 msg-id.
The concepts of userid and password are the business of the
application. All CRAM-D5
On Thursday, September 07, 2006 07:07:51 PM -0400 John C Klensin
[EMAIL PROTECTED] wrote:
However, 2195 is not, itself, a SASL method and there is nothing
in the procedural rules as I understand them that permits the
SASL WG to de-standardize it (you could write any of several
styles of
John == John C Klensin [EMAIL PROTECTED] writes:
John Actually, that topic opens up one of the fundamental issues
John with our standards process ... one where better definition
John and clear community consensus is, IMO, needed. Measured by
John our documented criteria, 2195
On Thursday, September 07, 2006 07:48:45 PM -0400 Jeffrey Hutzelman
[EMAIL PROTECTED] wrote:
Well, he could ask that 2195 be advanced as-is, but I would expect such
an effort to fail, as that version has turned out to be somewhat
underspecified. Multiple interoperable implementations is
At 04:07 PM 9/7/2006, John C Klensin wrote:
I think we have a small misunderstanding here. Let me say more
clearly and briefly
My message was intended to clarify why the SASL WG is
pursuing an Informational recommendation for its RFC2195bis
work and to redirect any comments specific to this
From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED]
At 04:07 PM 9/7/2006, John C Klensin wrote:
I think we have a small misunderstanding here. Let me say more
clearly and briefly
My message was intended to clarify why the SASL WG is
pursuing an Informational recommendation for its RFC2195bis
Jeffrey Hutzelman wrote:
Multiple interoperable implementations is not the
[only]
criteria for advancement; it is necessary but not
sufficient
2026 says mature, useful, well-understood, stable.
A downref to SASLprep for a 2195bis DS would be odd,
in that case better publish 2195bis as PS.
Christian Huitema wrote:
both Steve Bellovin and I presented the issues with such
techniques.
Is that presentation online available somewhere ? I find the
way to http://www3.ietf.org/proceedings/05aug/index.html but
then I'm lost.
Basic challenge response mechanisms like CRAM-MD5 are simply
From: Christian Huitema [mailto:[EMAIL PROTECTED]
From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] At 04:07 PM
9/7/2006, John C Klensin wrote:
I think we have a small misunderstanding here. Let me say more
clearly and briefly
My message was intended to clarify why the SASL WG is
On Friday, September 08, 2006 04:49:11 AM +0200 Frank Ellermann
[EMAIL PROTECTED] wrote:
That's my real problem: If users or worse implementors don't
know how stuff works it's bad. What you end up with are some
hypothetical situations like this:
A hypothetical situation is one that
On Thursday, September 07, 2006 08:12:44 PM -0700 Hallam-Baker, Phillip
[EMAIL PROTECTED] wrote:
The solution to this particular problem is to use SSL as the transport.
IMAP and POP both support this use. It is a trivial matter to discover
that IMAPS is supported using an SRV record.
Of
Total of 194 messages in the last 7 days.
script run at: Fri Sep 8 00:03:02 EDT 2006
Messages | Bytes| Who
+--++--+
8.76% | 17 | 11.29% | 135589 | [EMAIL PROTECTED]
8.25% | 16 | 8.89% | 106786 | [EMAIL
-Original Message-
From: Frank Ellermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 7:49 PM
To: ietf@ietf.org
Subject: Re: RFC 2195 (Was: what happened to newtrk?)
Christian Huitema wrote:
both Steve Bellovin and I presented the issues with such
The IESG has received a request from the Transport Area Working Group WG
to consider the following document:
- 'QoS Signaling in a Nested Virtual Private Network '
draft-ietf-tsvwg-vpn-signaled-preemption-00.txt as an Informational
RFC
The IESG plans to make a decision in the next few weeks,
The IESG has approved the following document:
- 'Transport of Ethernet Frames over L2TPv3 '
draft-ietf-l2tpext-pwe3-ethernet-09.txt as a Proposed Standard
This document is the product of the Layer Two Tunneling Protocol
Extensions Working Group.
The IESG contact persons are Jari Arkko and
30 matches
Mail list logo
