I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments
Arnt Gulbrandsen wrote:
Ted Faber writes:
If an application needs a heartbeat, it almost always needs to be an
application to application (layer 7 to layer 7) heartbeat.
...
My point is that if you need that layer 7 heartbeat, the layer 4 (TCP)
one doesn't help much. I can't think of an
Ted Faber wrote:
Perhaps. I find the end-to-end violation more compelling. YMMV.
Good luck in tcpm.
Thanks for the interesting disucssion!
Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Arnt Gulbrandsen wrote:
IMO, a TCP keepalive API needs contain only three functions. Two to
answer the questions are any acks overdue, and if so, by how long? and
what are the current RTT and bandwidth estimates? and one to provoke
the peer into sending an ack.
I would say that RFC1122
On 30 jun 2010, at 23:55, IETF Chair wrote:
To gain access to the IETF network, you will need to provide a
credential. Your primary credential will be your registration ID. You
can find your registration ID on the registration web page, in the
response email confirmation you received from
On Sun, Jul 18, 2010 at 08:02:52PM -0400, John C Klensin wrote:
Jeff, this works for me, but I don't think you really do the
spec's readers any favors by trying to reiterate the entire
history of terminology in this area (and, incidentally, leaving
things out that some folks might consider
Looking at the numbers, and trying to estimate (because there are not
clear records to make it easy to verify whether person X has ever been a
WG chair, what I found was that typically, about 40% of the pool was
experienced by the conditions we were using. Assuming 100 volunteers
(which has
Fred Baker fred at cisco dot com wrote:
Generally speaking, I think people fall into broad classes - those who
have followed a mailing list, those who have followed a mailing list
and shown up for meetings, those who have written an internet draft,
those who have pushed one through to RFC,
On Sun, Jul 18, 2010 at 02:06:33PM -0700, Dave CROCKER wrote:
Speaking only for myself, I'll say that it's quite easy to go to many
IETF meetings, but never learn anything about IETF process. When someone
has the responsibility for choosing the people who manage the process, we
ought to
Hi Patrik,
--On July 19, 2010 4:42:51 AM +0200 Patrik Fältström p...@cisco.com
wrote:
From my point of view, adding additional RR types with those
properties (to MX, SRV, NAPTR, and arguably CNAME and DNAME)
does increase the security risks -- not by adding risks that
were not there before,
--On Monday, July 19, 2010 04:42 +0200 Patrik Fältström
p...@cisco.com wrote:
...
No luser is going to understand the difference between the two
elements of the validation mechanism. Far more likely, the
weakest link principle will apply and the expectation of
security from DNSSEC will
On 19 jul 2010, at 16.07, Cyrus Daboo wrote:
Let me state that I do not think we should delay the
draft-daboo-srv-caldav IF a work like this is started. If we get some
work like this, I suggest letting draft-daboo-srv-caldav pass, given
people do not think the solution with an http redirect
On 7/18/2010 11:05 AM, Patrik Faltstrom (pfaltstr) wrote:
On 18 jul 2010, at 19:18, Joe Touchto...@isi.edu wrote:
That seems to means you use one of two different RRs, depending on the response.
I don't see that as a step forward.
No, the other way around. You, in a protocol, use either
Andrew Sullivan wrote:
To begin with, I have doubts that people who really haven't learned
_anything_ about IETF process are going to be the ones who volunteer
for Nomcom.
I have no doubts about that. A NomCom position is often considered a
leadership position by one's sponsor or manager --
Being able to verify signatures is of no value.
The system only has value when you can act differently according to
whether the signature verifies or not.
I keep asking, but nobody will tell me how I get the keys for my
domains into the TLD.
This is not a trivial issue. There is a question of
On 18 jul 2010, at 19:18, Joe Touch to...@isi.edu wrote:
That seems to means you use one of two different RRs, depending on the
response.
I don't see that as a step forward.
No, the other way around. You, in a protocol, use either srv or uri depending
on wether you need more than hostname
On 19 jul 2010, at 17.34, Joe Touch wrote:
No, the other way around. You, in a protocol, use either srv or uri
depending on wether you need more than hostname and port or a uri.
The point of SRVs is to provide a single way to find a service.
For me, there should be a single way of finding a
On Mon, Jul 19, 2010 at 11:42:00AM -0400, Barry Leiba wrote:
I have no doubts about that. A NomCom position is often considered a
leadership position by one's sponsor or manager -- it is, after all,
an HR job. To get into other leadership positions in the IETF, one
has to build up
Greetings again,
For those interested in monitoring sessions or participating remotely
at IETF 78 the following information may prove useful next monday.
-Audio Streaming-
All 8 parallel tracks at the IETF 78 meeting will be broadcast starting
with the commencement of working group sessions on
On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote:
At 1:59 PM -0400 7/18/10, Shumon Huque wrote:
Well, one reason would be to reduce the number of verification
steps imposed on a client by a certificate with a more preferred
or more specific identity type.
Is there something more
At 7:16 PM -0400 7/19/10, Shumon Huque wrote:
On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote:
At 1:59 PM -0400 7/18/10, Shumon Huque wrote:
Well, one reason would be to reduce the number of verification
steps imposed on a client by a certificate with a more preferred
or more
Yesterday a roughly 50 people seem to have been unsubscribed from of the
ip...@ietf list - It's possible this is perfectly normal but it struck me as
sort of weird. Are others seems stuff like this on other lists?
___
Ietf mailing list
On Mon, Jul 19, 2010 at 05:50:39PM -0700, Paul Hoffman wrote:
At 7:16 PM -0400 7/19/10, Shumon Huque wrote:
Right, I agree with that.
I'm not clear on whether you're objecting to an ordering rule. Or
saying that the additional text in 4.3 about ordering is unnecessary.
I am objecting to
In message aanlktikni86aoabgkib1_joeqe0ou4swpgrs8h1mb...@mail.gmail.com, Phil
lip Hallam-Baker writes:
Being able to verify signatures is of no value.
The system only has value when you can act differently according to
whether the signature verifies or not.
I keep asking, but nobody will
The IESG has approved the following document:
- 'Additional Master Secret Inputs for TLS '
draft-hoffman-tls-master-secret-input-03.txt as an Experimental RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Sean Turner.
draft-mohali-diversion-history-info-07.txt
The IESG has no problem with the publication of 'Mapping and interworking
of Diversion information Between Diversion and History-Info Headers in the
Session Initiation Protocol (SIP)'
draft-mohali-diversion-history-info-07.txt as an Informational RFC.
The IESG has approved the following document:
- 'HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
Environment '
draft-ietf-hip-bone-07.txt as an Experimental RFC
This document is the product of the Host Identity Protocol Working Group.
The IESG contact persons are Ralph
The IESG has approved the following document:
- 'Host Identity Protocol (HIP) Multi-hop Routing Extension '
draft-ietf-hip-via-03.txt as an Experimental RFC
This document is the product of the Host Identity Protocol Working Group.
The IESG contact persons are Ralph Droms and Jari Arkko.
A
The IESG has no problem with the publication of 'Mapping and interworking
of Diversion information Between Diversion and History-Info Headers in the
Session Initiation Protocol (SIP)'
draft-mohali-diversion-history-info-07.txt as an Informational RFC.
The IESG would also like the RFC-Editor to
The IESG has approved the following document:
- 'IPsec Cluster Problem Statement '
draft-ietf-ipsecme-ipsec-ha-09.txt as an Informational RFC
This document is the product of the IP Security Maintenance and Extensions
Working Group.
The IESG contact persons are Sean Turner and Tim Polk.
A
The IESG has no problem with the publication of 'A Survey on Research on
the Application-Layer Traffic Optimization (ALTO) Problem'
draft-irtf-p2prg-alto-survey-05.txt as an Informational RFC.
The IESG would also like the IRSG to review the comments in the
datatracker
The IESG has approved the following document:
- 'IPv6 Deployment in Internet Exchange Points (IXPs) '
draft-ietf-v6ops-v6inixp-09.txt as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica and Dan Romascanu.
A URL
A new IETF non-working group email list has been created.
List address: arp...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/arp222/
To subscribe: https://www.ietf.org/mailman/listinfo/arp222
Description: This list discusses issues associated with large amount of
virtual machines being
A new IETF non-working group email list has been created.
List address: cga...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/cgasec/
To subscribe: https://www.ietf.org/mailman/listinfo/cgasec
Description: The cgasec list is a non-WG (or pre-WG) mailing list used to
discuss how CGAs can
A new IETF non-working group email list has been created.
List address: iola-iesg-trac...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/iola-iesg-tracker/
To subscribe: https://www.ietf.org/mailman/listinfo/iola-iesg-tracker
Description: Discussion of the IOLA / IESG Tracker Project
A new IETF non-working group email list has been created.
List address: csky-idsub...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/csky-idsubmit/
To subscribe: https://www.ietf.org/mailman/listinfo/csky-idsubmit
Description: Discussion of the Concentric Sky / ID Submission Tool
Project
A new IETF non-working group email list has been created.
List address: yaco-liaison-t...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/yaco-liaison-tool/
To subscribe: https://www.ietf.org/mailman/listinfo/yaco-liaison-tool
Description: Discussion of the Yaco / Liaison Statement
37 matches
Mail list logo
