Peter,
I'm not driven by any desire to mandate more complex name comparison than is
called for. I just tend to think that it is better leave name comparison
requirement up to local policy.
However I think your argumentation is reasonable here and you convinced me.
I agree that in the general
Peter,
After the past discussions, the remaining things on my review list are:
General:
consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI
systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively
include [PKIX] brackets to clarify that it references RFC
On Tue Sep 14 01:03:39 2010, Stefan Santesson wrote:
Under the current rules, using this example I read it that the
following
apply:
- If you are just checking the SRVName you will not learn the
legitimate
host DNS name. So a certificate issued to host2.example.com will be
accepted
even
We have received ten proposals for BOFs in for the upcoming meeting (on
cloud computing, distributed mobility management, ARP improvements,
light-weight IP stack, name-based sockets, home networking, datatracker
spec review, network stratum query, DNS-based cryptographic security,
secure content
Thanks for your review, you've identified at least one error on my
part for certain, and raised an issue of clarity I'd like to address.
On Tue Aug 17 20:37:16 2010, John C Klensin wrote:
This is very interesting. In the applications area during the
last 15 years, I consider ACAP to be one
On Tue Sep 14 12:21:04 2010, Dave Cridland wrote:
On Tue Aug 17 20:37:16 2010, John C Klensin wrote:
(1) Why not go all the way: rename the registry to something
more neutral that avoids ACAP, update the two newer protocol
specifications to point to the new registry, and advise IANA to
include
* Noel Chiappa:
I actually vaguely recall discussions about the TOS field (including
how many bits to give to each sub-field), but I can't recall very
much of the content of the discussions. If anyone cares, some of the
IENs which document the early meetings might say more.
See RFC 760,
On 9/13/2010 2:52 PM, Fred Baker wrote:
What I find irritating with these discussions
What I find irritating with these discussions is the tendency to get irritated.
The other thing that is irritating is the tendency to dismiss or attack serious
efforts to make serious comments.
The
I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
document and support it's forward progress. I do have a few comments
though:
(*):
Applies to many of the comments below: some parts of the document
read like a BCP in the way it tries to rationalize things. A number
Who cares?
William Shockley is considered by some to have 'founded' the modern field of
electronics. Are we thus obliged to accept his bigoted and racist views on
social issues?
I am pretty sure that my ancestors did not anticipate parliamentary
democracy as they raped and pillaged their way
Please be aware of the status of this document that passed through IETF last
call some time back.
Adrian
- Original Message -
From: Adrian Farrel adrian.far...@huawei.com
To: ops...@ietf.org
Cc: Scott Bradner s...@harvard.edu;
draft-ietf-opsawg-mpls-tp-oam-...@tools.ietf.org;
On Mon, Sep 13, 2010 at 08:12:47PM +0100, Dave Cridland wrote:
On Mon Sep 13 18:59:03 2010, Stefan Santesson wrote:
I agree here. Both to this and to former speakers stating that the
assertion
is made by the CA and no the subject.
Well, I'd say the assertion is the presence of the SAN in
- Original Message
From: Laganier, Julien juli...@qualcomm.com
To: Behcet Sarikaya sarik...@ieee.org; Alexandru Petrescu
alexandru.petre...@gmail.com
Cc: IETF Discussion ietf@ietf.org; mext m...@ietf.org
Sent: Mon, September 13, 2010 3:38:54 PM
Subject: RE: [MEXT] Last Call:
On Mon, 13 Sep 2010, Dave CROCKER wrote:
Maastricht suffered an impressive variety of problems. Worse, some of those
problems have become a recurring pattern. As examples, we have had a
significant number of venues in recent years that were distant from major
transportation hubs and/or
On 9/14/10 10:07 AM, Sean Turner wrote:
I'd offered to review this version during the TLS session at IETF 78,
but I think I'm going to wait for the next version ;)
Yes, the authors will work to submit a revised I-D soon, based on all
the feedback received so far.
Peter
--
Peter Saint-Andre
I'd offered to review this version during the TLS session at IETF 78,
but I think I'm going to wait for the next version ;)
spt
Wes Hardaker wrote:
I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
document and support it's forward progress. I do have a few comments
I think San Diego was worse than Dublin in that respect. At least in
Dublin there were free busses to the city center.
Janet
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE:
...
Curious; RFC2402 says
Flags -- This field is excluded since an intermediate router might
set the DF bit, even if the source did not select it.
which is a licence to set the bit but I had not thought to reset the bit.
RFC791, RFC1122 and RFC1812 would appear to be
On 9/14/2010 8:11 AM, Florian Weimer wrote:
* Noel Chiappa:
I actually vaguely recall discussions about the TOS field (including
how many bits to give to each sub-field), but I can't recall very
much of the content of the discussions. If anyone cares, some of the
IENs which document the
As examples, we have had a
significant number of venues in recent years that were distant from major
transportation hubs and/or were distant from local resources such as the
usual array of hotels, restaurants, markets and the like.
Of these I can name only Dublin as falling into the
On Tue, 14 Sep 2010, Michael Dillon wrote:
Even if you are unwilling to accept these criticisms when CHOOSING venues,
I am not at all unwilling to accept the criticisms, I was responding
to the claim of a pattern. Maastricht clearly had problems, I think
that has been stated more than once.
Even in Dublin and Maastricht there were
restaurant districts nearby for those with vehicles.
Virtually no attendee had a vehicle ateither of those venues (or many
others.)
People willing to ride on a bus or pay for a taxi are those
with vehicles. The point is that something which is too far
Dave,
I did not say there were not problems with Dublin, I said (and Michael
concurred) that the steps taken to mitigate the issues helped
significantly. I am not signalling out CityWest as some kind of ideal
location for an IETF meeting, far from it.
Ole
Ole J. Jacobsen
Editor and
On Tue Sep 14 16:45:12 2010, Shumon Huque wrote:
On Mon, Sep 13, 2010 at 08:12:47PM +0100, Dave Cridland wrote:
The requested DNS domain name for the specified service. That is,
the domain name which would be found in the URI for the service,
and
other protocol identifiers of a similar
Behcet Sarikaya wrote:
Laganier, Julien wrote:
Behcet Sarikaya wrote:
Laganier, Julien wrote:
[...]
[ I also note that this draft has been more than 2 years in the
MEXT working group in which you are participating, which gave you
ample time to comment on
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tcpm-urgent-data-06
On 2010-09-14 13:46, Phillip Hallam-Baker wrote:
I am not finding the net neutrality debate according to K-Street to be very
useful or stimulating.
+1. No, +100.
At the end of the day we have a limited amount of bandwidth available and we
can help matters if people co-operate where it is
On 2010-09-15 04:36, Bob Braden wrote:
On 9/14/2010 8:11 AM, Florian Weimer wrote:
* Noel Chiappa:
I actually vaguely recall discussions about the TOS field (including
how many bits to give to each sub-field), but I can't recall very
much of the content of the discussions. If anyone
On 9/14/10 1:58 AM, Dave Cridland wrote:
On Tue Sep 14 01:03:39 2010, Stefan Santesson wrote:
- If you just check the dNSName, you will miss the fact that you talk
to the
desiganted ldap server and not the xmpp server (even if that
information is
in the cert).
Kind of. The rules
I wonder how many people realize that X.25 was a direct descendant of
ARPANET, and that BBN became a leading supplier of X.25 hardware simply
by continuing the IMP down its evolutionary path.
The dialog on Internet regulation is world-wide. The EC has an open
inquiry on it, and nations
Indeed, K St. think tanks were heavily involved in the Kennedy
assassination, Watergate, and 9/11. Like IPv6, it's all about the address.
RB
On 9/14/2010 6:25 PM, Phillip Hallam-Baker wrote:
If you have such a poor opinion of engineers, then why post here?
In my experience, K-street think
Isn't this also basically the point of LEDBAT and CONEX? For
applications to sense congestion and back off aggressively -- i.e., to
time-shift themselves into the future?
On Sep 14, 2010, at 5:48 PM, Brian E Carpenter wrote:
On 2010-09-14 13:46, Phillip Hallam-Baker wrote:
I am not
There's future and then there's future. LEDBAT wants to sense
congestion and back off to allow other apps with more pressing needs to
use particular pipes, not so much to defer as to find less congested
paths. The LEDBAT assumption is that there are many paths to the
content, and in fact many
The IESG has approved the following document:
- 'Traversal Using Relays around NAT (TURN) Extensions for TCP
Allocations'
draft-ietf-behave-turn-tcp-07.txt as a Proposed Standard
This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.
The IESG contact
The IESG has approved the following document:
- 'Datagram Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)'
draft-ietf-tsvwg-dtls-for-sctp-06.txt as a Proposed Standard
This document is the product of the Transport Area Working Group.
The IESG contact persons
The IESG has approved the following document:
- 'Dynamic Symmetric Key Provisioning Protocol (DSKPP)'
draft-ietf-keyprov-dskpp-14.txt as a Proposed Standard
This document is the product of the Provisioning of Symmetric Keys
Working Group.
The IESG contact persons are Tim Polk and Sean Turner.
Topic: IETF PCP Interim
Date: Thursday, October 7, 2010
Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 207 635 511
Password: ietf
---
To join the meeting online(Now from the Apple iPhone (R) and other
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'Unicast-Based Rapid Acquisition of Multicast RTP Sessions'
draft-ietf-avt-rapid-acquisition-for-rtp-15.txt as a Proposed
Standard
The IESG plans to make a decision in the next few
The IESG has approved the following document:
- 'Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)'
draft-ietf-tcpm-tcp-lcd-03.txt as an Experimental RFC
This document is the product of the TCP Maintenance and Minor Extensions
Working Group.
The IESG contact person is Lars
A new Request for Comments is now available in online RFC libraries.
RFC 5939
Title: Session Description Protocol (SDP) Capability
Negotiation
Author: F. Andreasen
Status: Standards Track
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
RFC 5947
Title: Requirements for Multiple Address of
Record (AOR) Reachability Information in the
Session Initiation Protocol (SIP)
Author:
A new Request for Comments is now available in online RFC libraries.
RFC 5970
Title: DHCPv6 Options for Network Boot
Author: T. Huth, J. Freimann,
V. Zimmer, D. Thaler
Status: Standards Track
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
RFC 5895
Title: Mapping Characters for Internationalized Domain
Names in Applications (IDNA) 2008
Author: P. Resnick, P. Hoffman
Status: Informational
A new Request for Comments is now available in online RFC libraries.
RFC 5950
Title: Network Management Framework for MPLS-based
Transport Networks
Author: S. Mansfield, Ed.,
E. Gray, Ed.,
K.
A new IETF non-working group email list has been created.
List address: scap_inter...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/scap_interest/
To subscribe: https://www.ietf.org/mailman/listinfo/scap_interest
Description: This list is for discussions relating to the applicability
of
A new IETF non-working group email list has been created.
List address: n...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/nscp/
To subscribe: https://www.ietf.org/mailman/listinfo/nscp
Description: This list is intended for initial discussion relating to the
development and
The MARTINI WG will be holding a virtual Interim meeting on Monday,
September 27, 2010 from 10 AM - 12 noon Pacific Time.
Details on the meeting parameters will be posted to the MARTINI WG list:
http://www.ietf.org/mail-archive/web/martini/current/maillist.html
A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination as yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
(i...@ietf.org) by
A modified charter has been submitted for the Hypertext Transfer Protocol
Bis (httpbis) working group in the Applications Area of the IETF. The
IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your comments
to the
49 matches
Mail list logo
