I also noticed providessuggestions as a typo, which does make me
wonder - we rely on the RFC Editor for proof-reading, but we're not
sending IONs to the RFC Editor. Is there a plan?
IONs are less formal, so I think the honest answer is no. And
we are certainly not going to apply any style
On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both
originally and in ION format.
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
Again, thanks for doing this work...
Spencer
On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both
originally and in ION format.
I'm having a hard time understanding what lookup mechanisms are less
convenient for BCPs than for RFCs
I received this as a private e-mail to myself and Brian, and wanted to thank
Francis AND pass along the information, which I didn't remember, either...
In your previous mail you wrote:
My assumption, maybe false, is that a lot of people have RFC mirrors and
relatively few have BCP
On 2007-01-30 13:59, Spencer Dawkins wrote:
snip
What I'm talking about is that if you type in BCP 9 in the RFC Editor
search engine, the only RFC that pops up as part of BCP 9 is 2026, but
the RFC Index says Updated by RFC3667, RFC3668, RFC3932, RFC3979,
RFC3978.
This is a special case,
http://www.cnn.com/2007/TRAVEL/DESTINATIONS/01/29/prague/index.html
--Steve Bellovin, http://www.cs.columbia.edu/~smb
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Sorry for the spam folks, I responded to the wrong thread.
Mark Townsley wrote...
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On second look, this is rather small. Vipin, I can do either. If you
wish to provide me text in OLD NEW format, or a new document.
- Mark
Suresh Krishnan wrote:
I am the assigned Gen-ART reviewer for
draft-ietf-l2tpext-failover-11.txt
For background on Gen-ART, please see the FAQ at
--On 30. januar 2007 15:21 +0100 Brian E Carpenter [EMAIL PROTECTED]
wrote:
What I'm talking about is that if you type in BCP 9 in the RFC Editor
search engine, the only RFC that pops up as part of BCP 9 is 2026, but
the RFC Index says Updated by RFC3667, RFC3668, RFC3932, RFC3979,
Hi Jeffrey,
thank you for reviewing this document.
I am responding to your comments because I have worked on the parts of the
document that address Credit-Based Authorization and the related security
considerations, which you are referring to in your review.
Section 3.1.2: Mobility Overview
On Tuesday, January 30, 2007 08:26:01 PM +0100 Christian Vogt
[EMAIL PROTECTED] wrote:
This should probably be rephrased to:
This UPDATE packet is acknowledged by the peer. For reliability in
the presence of packet loss, the UPDATE packet is retransmitted in
case
no
Jeffrey,
my replies in-line below, removing the parts that we agreed upon...
Section 3.3.2: Credit-Based Authorization
2. An attacker can always cause unamplified flooding by sending
packets to its victim directly.
This is frequently untrue. The network may be configured such that
On Tuesday, January 30, 2007 11:04:37 PM +0100 Christian Vogt
[EMAIL PROTECTED] wrote:
Given that the protocol right now only allows type-1 locators, do you
think that the handling of different locator types could be left to
those protocol extensions that specify them?
I think you need to
Jeffrey,
I see your point and agree. The draft should be precise with respect to
handling locator types other than 1.
Thanks,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
___
Christian == Christian Vogt [EMAIL PROTECTED] writes:
Christian unamplified flooding would also be possible for the
Christian attacker without HIP because the attacker could send
Christian flooding packets with an IPv6 Routing header, directing
Christian the packets to the
On 2007-01-29 18:08, Spencer Dawkins wrote:
I should begin by thanking Brian for producing this document, both
originally and in ION format.
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
The IESG has approved the following document:
- 'IPv6 Deployment Scenarios in 802.16(e) Networks '
draft-ietf-radext-filter-08.txt as a Proposed Standard
This document is the product of the RADIUS EXTensions Working Group.
The IESG contact persons are David Kessens and Dan Romascanu.
A URL
The IESG has approved the following document:
- 'IPv6 Transition/Co-existence Security Considerations '
draft-ietf-v6ops-security-overview-06.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 approved the following document:
- 'RADIUS Filter Rule Attribute '
draft-ietf-radext-filter-08.txt as a Proposed Standard
This document is the product of the RADIUS EXTensions Working Group.
The IESG contact persons are David Kessens and Dan Romascanu.
A URL of this
A new IETF working group has been formed in the Security Area.
For additional information, please contact the Area Directors
or the WG Chairs.
+++
Provisioning of Symmetric Keys (keyprov)
=
Current Status: Active Working Group
Chair(s):
Phillip
21 matches
Mail list logo
