At 10:54 AM +0900 7/10/07, Masataka Ohta wrote:
...
Stephen Kent wrote:
The notion of CA compromise and ISP comprise are not completely
comparable, which makes your comparison suspect.
As I already mentioned, social attacks on employees of CAs and
ISPs are equally easy and readily
Stephen Kent wrote:
At 10:54 AM +0900 7/10/07, Masataka Ohta wrote:
It hard for you to recognize that most, if not all, of the effort
of IETF security area has been_ wasted in vain_.
As opposed to wasting efforts constructively?
But that's the
reality.
I am out (on vacation :) ) until next 16 July. See you then.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I am out (on vacation :) ) until next 16 July. See you then.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Is there a way we could have these things filtered at the source?
Date: Tue, 10 Jul 2007 19:48:04 +0200
From: [EMAIL PROTECTED]
To: ietf@ietf.org
Subject: Autoreply: Last Call: draft-hunt-avt-rtcpxnq (BT's eXtended
Network Quality RTP Control Protocol Extended
Reports (RTCP XR XNQ)) to
Security is a property of systems and not of technologies.
In particular security is risk management and not the elimination of all risk.
Even the best PKI will not provde you with the slightest protection against a
meteor strike.
PKI provides opportunities for technical risk mitigation which
Howdy,
A couple of things about this specification confuse me, and
I'd appreciate enlightenment from the authors. The first is that the
document spends a fair amount of time setting up the context in
which GETS or other services might use resource priority and how
this mechanism relates
Ole Jacobsen writes:
Is there a way we could have these things filtered at the source?
Do you mean broken autoresponders or acronyms like RTCPXNQ? If the
former, the esteemed volunteer or secretariat who runs this list can
add a couple of lines like 'subject:.*out of office' and 'subject:
On 10-jul-2007, at 21:15, Arnt Gulbrandsen wrote:
Ole Jacobsen writes:
Is there a way we could have these things filtered at the source?
Do you mean broken autoresponders or acronyms like RTCPXNQ?
Please let's not have a philosophical discussion, but unsubscribe
that cipf.es address
There are several reasons that application designers might not use DCCP and
SCTP, one is that they are not aware of them, others are that they may not
understand the deployment consequences of doing so or may lack the necessary
support infrastructure to do so.
Attitudes may also be somewhat
The IETF rules met the objective that the IESG had when they proposed them - to
make sure that at least we did not continue to invent yet more protocols that
only support password authentication in the clear.
In the case of HTTP, the DIGEST proposal came within a week of BASIC. If the
IESG
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well
managed.
In all but a single instance I have no evidence to the contrary.
The one case of an exploit was extremely
At 1:13 PM -0700 7/10/07, Douglas Otis wrote:
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well managed.
In all but a single instance I have no evidence to the contrary.
I am out (on vacation :) ) until next 16 July. See you then.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Jul 10, 2007, at 1:51 PM, Stephen Kent wrote:
At 1:13 PM -0700 7/10/07, Douglas Otis wrote:
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well
managed.
In all but a
Hallam-Baker, Phillip wrote:
Security is a property of systems and not of technologies.
Yes, of course. Though some often claims PKI were cryptographically
secure, it does not mean PKI is strongly secure. Cookies, too, are
cryptographically secure.
In particular security is risk management
69th IETF Meeting
Chicago, IL, USA
July 22-27, 2007
Host: Motorola
REMINDER: Early bird registration cutoff is Friday, July 13 at 12:00 noon
ET (16:00 UTC/GMT). If you register and pay prior to this time, the
registration fee is $600.00. After this time the fee will be $750.00.
The IESG has received a request from an individual submitter to consider
the following document:
- 'TRIP Attribute for Resource Priority '
draft-carlberg-trip-attribute-rp-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from an individual submitter to consider
the following document:
- 'BT's eXtended Network Quality RTP Control Protocol Extended Reports
(RTCP XR XNQ) '
draft-hunt-avt-rtcpxnq-00.txt as an Informational RFC
The IESG plans to make a decision in the next few
The IESG has approved the following document:
- 'The Generalized TTL Security Mechanism (GTSM) '
draft-ietf-rtgwg-rfc3682bis-10.txt as a Proposed Standard
This document is the product of the Routing Area Working Group.
The IESG contact persons are Ross Callon and David Ward.
A URL of this
The IESG has no problem with the publication of 'Explicit Multicast
(Xcast) Concepts and Options' draft-ooms-xcast-basic-spec-13.txt as an
Experimental RFC.
The IESG would also like the RFC-Editor to review the comments in the
datatracker
The IESG has received a request from the Session Initiation Protocol WG
(sip) to consider the following document:
- 'Requesting Answering Modes for the Session Initiation Protocol
(SIP) '
draft-ietf-sip-answermode-04.txt as a Proposed Standard
The IESG plans to make a decision in the
A new Request for Comments is now available in online RFC libraries.
RFC 4926
Title: A URN Namespace for GEANT
Author: T. Kalin, M. Molina
Status: Informational
Date: July 2007
Mailbox:[EMAIL PROTECTED],
A new Request for Comments is now available in online RFC libraries.
RFC 4837
Title: Managed Objects of Ethernet Passive
Optical Networks (EPON)
Author: L. Khermosh
Status: Standards Track
Date:
24 matches
Mail list logo
