Frank,
Not publishing it at all is an alternative.
And this is what we should do, if the community feels that
way. However ...
It would send an
unmistakable message to wannabe-authors, that they should use the
independent path, unless they're a friend of a friend of an AD.
I personally
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are more or less in sync but the
remaining input should come from the community.
As for the
On 2007-02-08 01:25, Frank Ellermann wrote:
John C Klensin wrote:
If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION
John,
On 2007-02-08 00:02, John C Klensin wrote:
Hi.
I will get to substance in a separate note, and hope others will
also. In the interim, two procedural remarks...
(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the how a document that does not
originate
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
[EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are
John,
Sure. But my point in that area was obviously not clear. Prior
to the announcement of the Last Call, there was no indication to
the community that this document should be considered and
discussed, much less where.
Right. We weren't ready for a very wide discussion with
the earlier
John,
On 2007-02-08 13:16, John C Klensin wrote:
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
[EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an
Scott,
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an informational RFC
- note that RFC 2026 does not require any last call for informationals
On 2007-02-08 14:05, Scott O. Bradner wrote:
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no
I agree with Tom that the draft - at least IMHO - does not promote or
strongly encourage reliable logging.
I also agree with the observation that reliable - and blocking -
logging can cause harm to a system. However, I do not think that this
is anything that the protocol can do something
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
John [EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg at
this
I've reviewed this document as part of the transport directorate's
ongoing effort to review key IETF documents. These comments were
written primarily for the transport area directors. Document
editors and WG chairs should treat these comments just like any other
last call comments. Feel free to
Jari Arkko wrote:
please complain!
That was the complaint, the draft is from an IESG POV, and it
explains how to deal with confused authors claiming that a
single bit is enough to count to three or similar cases.
But it doesn't address the POV of authors who want to get an
evaluation of their
--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman
[EMAIL PROTECTED] wrote:
John Sure. But my point in that area was obviously not
clear. John Prior to the announcement of the Last Call,
there was no
That sort of depends on what's going on here.
Is Jari's draft an
Hi, Sam,
I agree with your note.
FWIW, and speaking only for the confused on the list,
- I understand why something should be a BCP (community consensus for a
process that doesn't change every year or so),
- I understand why something should be an ION (IESG consensus with
appropriate input
On Thu, Feb 08, 2007 at 02:32:00PM +0100, Rainer Gerhards wrote:
I also agree with the observation that reliable - and blocking -
logging can cause harm to a system. However, I do not think that this
is anything that the protocol can do something against. It is not the
protocol that causes
Hi Frank,
That was the complaint, the draft is from an IESG POV, and it
explains how to deal with confused authors claiming that a
single bit is enough to count to three or similar cases.
I would be happy to sponsor a ternary bit draft, but
only on April 1 :-)
But it doesn't address the
Hello folks,
we updated draft-ietf-mipshop-cga-cba according to the comments and
suggestions that Eric Gray posted on the IETF Discussion mailing list
during IETF Last Call. Here is a change log (not including purely
editorial items):
o Reference to RFC 3972 (Cryptographically Generated
Hi,
With the submission deadlines before the Prague meeting coming up,
please remember that all drafts need to use the latest boilerplate
text (see below for details).
February 26, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (14:00 UTC/GMT)
March 5, Monday
The IESG has received a request from an individual submitter to consider
the following document:
- 'Language Tag MIB '
draft-mcwalter-langtag-mib-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send
The IESG has received a request from an individual submitter to consider
the following document:
- 'Uniform Resource Identifier (URI) MIB '
draft-mcwalter-uri-mib-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
A new Request for Comments is now available in online RFC libraries.
RFC 4793
Title: The EAP Protected One-Time Password
Protocol (EAP-POTP)
Author: M. Nystroem
Status: Informational
Date: February 2007
23 matches
Mail list logo
