Ah, very good! Thanks for the pointer, Sam.
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
Sam Hartman wrote:
Christian == Christian Vogt [EMAIL PROTECTED] writes:
Christian unamplified flooding would also be possible
On 2007-01-31 00:35, Ned Freed wrote:
...
More generally, I have a problem with normative cituations to BCP and STD
numbers since the underlying document can change. That's arguably OK for an
informational citation, but IMO normative references may have version
dependencies that need to be taken
On 2007-01-31 00:35, Ned Freed wrote:
...
More generally, I have a problem with normative cituations to BCP and STD
numbers since the underlying document can change. That's arguably OK for an
informational citation, but IMO normative references may have version
dependencies that need to be
On Fri, 26 Jan 2007, Lisa Dusseault wrote:
Hi Philip, thanks for the review. But are we looking at the same version of
this doc? We dealt with this after doing a pseudo-WG-last-call on the SMTP
mailing list and the -07 draft now has:
Dang. I had pulled down the newer revision of
Dear all,
I have substantive comments that were initially raised during the S-MIME WG
last call
(December 1, 2006) and that have not been incorporated into the draft.
The major issue is that the draft is proposing to state:
(...) the successful validation of one signature associated with
I have reviewed this document and support moving it forward on the standards
track.
On procedural nit:
In section 4, the document states:
The service name specified by this protocol's profile of SASL
is pop.
A note in the IANA Considerations section is needed which directs
Ned Freed wrote:
informational citation, but IMO normative references may have version
dependencies that need to be taken into account.
I think that is absolutely correct for technical specs. In the
specific case
of the IPR process documents, which Spencer raised, it may well be that
the
Dave,
Interestingly enough, your observation provides the
strongest argument I've yet seen for assigning a standard
number to any RFC that has becomes a Proposed Standard.
--
Eric
-Original Message-
From: Dave Crocker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 31,
Eric Gray (LO/EUS) wrote:
Dave,
Interestingly enough, your observation provides the
strongest argument I've yet seen for assigning a standard
number to any RFC that has becomes a Proposed Standard.
Well, it's a double-edged capability. All of the concerns about citing the
latest
--On Wednesday, 31 January, 2007 10:17 -0600 Eric Gray
\\(LO/EUS\\) [EMAIL PROTECTED] wrote:
Dave,
Interestingly enough, your observation provides the
strongest argument I've yet seen for assigning a standard
number to any RFC that has becomes a Proposed Standard.
Anyone who wants
--On Wednesday, 31 January, 2007 11:50 +0100 Brian E Carpenter
[EMAIL PROTECTED] wrote:
On 2007-01-31 00:35, Ned Freed wrote:
...
More generally, I have a problem with normative cituations to
BCP and STD numbers since the underlying document can change.
That's arguably OK for an
On Wed, 31 Jan 2007 11:54:26 -0500
John C Klensin [EMAIL PROTECTED] wrote:
Except for the fact that the material being cited contains the
specifics of license and IPR releases, and promises to abide by
certain rules, by the authors. Authors can't reasonably be
asked to agree to something
An ION (IETF Operational Note, see RFC 4693) is open for public comment
on the ietf@ietf.org list. Comments should be sent by 2007-02-12.
Note that some early reviewers have suggested that this document
is not really needed, since IETF minutes are already of a
good enough standard. Opinions on
An ION (IETF Operational Note, see RFC 4693) is open for public comment
on the ietf@ietf.org list. Comments should be sent by 2007-02-12.
Please see
http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html
___
Ietf mailing list
Ietf@ietf.org
Dave Crocker writes:
Eric Gray (LO/EUS) wrote:
Interestingly enough, your observation provides the strongest
argument I've yet seen for assigning a standard number to any
RFC that has becomes a Proposed Standard.
Well, it's a double-edged capability. All of the concerns
--On Wednesday, 31 January, 2007 17:02 + Steven M.
Bellovin [EMAIL PROTECTED] wrote:
On Wed, 31 Jan 2007 11:54:26 -0500
John C Klensin [EMAIL PROTECTED] wrote:
Except for the fact that the material being cited contains the
specifics of license and IPR releases, and promises to abide
Hello Eric,
thank you for taking your time to review draft-ietf-mipshop-cga-cba.
Please see my comments in-line below.
Note I'm also sending a CC to ietf@ietf.org as suggested in the IESG's
Last Call announcement on the Mipshop working group's mailing list.
Summary:
I have a small number
Denis, it sounds like you have two issues:
1) This document goes beyond specifying how to determine if a message
is validly signed by a given signer.
2) There is not enough precision in the description of how to validate
a signature.
I strongly suggest that you try and build consensus for
- 'The syslog Protocol '
draft-ietf-syslog-protocol-19.txt as a Proposed Standard
draft-ietf-syslog-protocol-19.txt recommends using a reliable
protocol. Existing implementations of syslog do this and
deadlock with nameservers which are logging via syslog.
For some reason, in your response, my bulletization of the
list of the new status codes somehow got re-paragraphed -
hopefully my version below does not suffer the same fate.
Typographical resets should be absolutely disallowed in
E-Mail. :-)
To the casual reader, it may otherwise be unclear
Eric -
For some reason, in your response, my bulletization of the
list of the new status codes somehow got re-paragraphed -
hopefully my version below does not suffer the same fate.
Oh, no, this was probably one of my Thunderbird extensions for nicer
quotations. It's now deinstalled.
The main meeting venue for the IETF Meeting is sold out. The cut off date
to secure rooms at the overflow hotels is fast approaching. A list of
overflow hotels be found at: http://www3.ietf.org/meetings/68-hotels.html
Social Event Information:
http://www.ietf.org/meetings/68-social.html
Draft
The IESG has no problem with the publication of 'LSP Preemption Policies
for MPLS Traffic Engineering'
draft-deoliveira-diff-te-preemption-06.txt as an Informational RFC.
The IESG would also like the RFC-Editor to review the comments in the
datatracker
Under the term of RFC 3967, the IESG may approve a normative
reference to a document at a lower level, after an appropriate
Last Call. RFC 1951 is referenced by two documents recently
put to Last Call: draft-ietf-lemonade-compress and
draft-ietf-crisp-iris-lwz . As is common with algorithm
The IESG has approved the following document:
- 'IPv6 Enterprise Network Analysis - IP Layer 3 Focus '
draft-ietf-v6ops-ent-analysis-07.txt as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are David Kessens and Dan
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Wildcard Pseudowire Type '
draft-ietf-pwe3-wildcard-pw-type-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
A new Request for Comments is now available in online RFC libraries.
BCP 127
RFC 4787
Title: Network Address Translation (NAT) Behavioral
Requirements for Unicast UDP
Author: F. Audet, Ed.,
C. Jennings
A new Request for Comments is now available in online RFC libraries.
RFC 4629
Title: RTP Payload Format for ITU-T
Rec. H.263 Video
Author: J. Ott, C. Bormann,
G. Sullivan, S. Wenger,
R. Even,
28 matches
Mail list logo
