Adrian,
On Sep 12, 2010, at 6:22 AM, Adrian Farrel wrote:
Bob,
Since you ask...
This looks good.
Thanks.
The only nit I can pick is with 5.1
The BCP calls for rules on expenses to be published.
The rule you are publishing is that the IAOC and/or its chair can determine
the
Glen,
I had zero expectation that Maastricht would be anything like the city
I live in. However, it never crossed my mind to think that the city
would be so deserted when I arrived, nor that I would end up on the
last train. So, you are correct that i did not come prepared with a
list of taxi
I personally am not asking for a fault free venue, however, I am
asking for some very basic things to be considered as part of the
meeting venue selection process:
1) Safety: far more easily achieved when the meeting hotels and venue
are very close to one another in a city center that doesn't
- Original Message
From: Laganier, Julien juli...@qualcomm.com
To: Alexandru Petrescu alexandru.petre...@gmail.com; Hesham Soliman
hes...@elevatemobile.com
Cc: IETF Discussion ietf@ietf.org; mext m...@ietf.org
Sent: Fri, September 10, 2010 11:57:36 AM
Subject: Re: [MEXT] Last
On 9/9/10 12:22 PM, Shumon Huque wrote:
On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote:
On 10-09-08 9:53 PM, Shumon Huque shu...@isc.upenn.edu wrote:
The output of the SRV record lookup contains a target hostname,
not a service name, so it's not applicable to the SRVName
At 10:08 AM -0600 9/13/10, Peter Saint-Andre wrote:
As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities. Do we have evidence that any existing
certification authorities issue certificates
On 9/9/10 1:36 PM, Stefan Santesson wrote:
On 10-09-09 8:38 PM, Shumon Huque shu...@isc.upenn.edu wrote:
Earlier in RFC 4985, it says:
The SRVName, if present, MUST contain a service name and a domain
name in the following form:
_Service.Name
The content of the
Michael,
So, when a venue is not a mainstream hotel with regular airport
shuttle service, it might be good to publish a number that people
can call at any time to arrange an English speaking taxi driver
to pick them up from the train station. And understand that this
service might be called
Several interesting responses, thanks.
I agree that detailed rules would be onerous and unable to cope with the
exceptional circumstances that the condition is intended to cover.
On the other hand BCP101 does seem to require some rules.
Dave said:
There are enough hassles for the IAOC
On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote:
On 9/9/10 12:22 PM, Shumon Huque wrote:
On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote:
The only thing the client need to do is to verify that the domain name
provided in the input to the lookup matches the
On Sep 13, 2010, at 12:18 PM, Peter Saint-Andre wrote:
On 9/9/10 1:36 PM, Stefan Santesson wrote:
On 10-09-09 8:38 PM, Shumon Huque shu...@isc.upenn.edu wrote:
Earlier in RFC 4985, it says:
The SRVName, if present, MUST contain a service name and a domain
name in the following form:
On 9/13/10 10:52 AM, Shumon Huque wrote:
On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote:
On 9/9/10 12:22 PM, Shumon Huque wrote:
On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote:
The only thing the client need to do is to verify that the domain name
provided
On Mon, Sep 13, 2010 at 10:18:00AM -0600, Peter Saint-Andre wrote:
On 9/9/10 1:36 PM, Stefan Santesson wrote:
On 10-09-09 8:38 PM, Shumon Huque shu...@isc.upenn.edu wrote:
Earlier in RFC 4985, it says:
The SRVName, if present, MUST contain a service name and a domain
name in
On Mon Sep 13 17:52:59 2010, Shumon Huque wrote:
Yes, but whether they are actually current best practices is
debatable. I certainly would like them to become best practices.
For example I don't believe any existing commercial CAs issue
certificates with the SRVName or URI SAN name forms.
Adrian,
On Sep 13, 2010, at 9:39 AM, Adrian Farrel wrote:
Several interesting responses, thanks.
I agree that detailed rules would be onerous and unable to cope with the
exceptional circumstances that the condition is intended to cover.
On the other hand BCP101 does seem to require some
On Sep 13, 2010, at 12:39 PM, Adrian Farrel wrote:
Several interesting responses, thanks.
I agree that detailed rules would be onerous and unable to cope with the
exceptional circumstances that the condition is intended to cover.
On the other hand BCP101 does seem to require some rules.
I've generally stayed out of this discussion, but let me offer a word
of support to Bob, et al re maintaining some flexibility. There are
two very strong protections already in place in this system. First,
the operation of the IAOC -- and IASA -- are fully documented and
visible. If the
On 10-09-13 7:03 PM, Shumon Huque shu...@isc.upenn.edu wrote:
Authorized by whom? I *think* that here the DNS domain name is one that
the certified subject has itself authorized (perhaps even established
is better) to provide the desired service. Therefore I suggest an
alternative wording:
There is an interesting discussion thread on the NANOG list na...@nanog.org
under this title that some people on this list might be interested in
following.
Regards
Marshall
___
Ietf mailing list
Ietf@ietf.org
On 9/13/2010 11:19 AM, Marshall Eubanks wrote:
There is an interesting discussion thread on the NANOG list na...@nanog.org
under this title that some people on this list might be interested in
following.
Regards
Marshall
Why not simply ask Len Klienrock the answer to this question.
Peter,
On 10-09-13 6:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Hi Shumon,
As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities. Do we have evidence that any existing
On 9/12/2010 6:22 AM, Adrian Farrel wrote:
I have absolutely no doubt of the integrity of the IAOC and its chair, but this
rule is somewhat vague and open to interpretation. It is like using the word
appropriate in a protocol spec!
Could you look at qualifying this in some way to scope the
On 9/13/10 11:05 AM, Dave Cridland wrote:
On Mon Sep 13 17:52:59 2010, Shumon Huque wrote:
Yes, but whether they are actually current best practices is
debatable. I certainly would like them to become best practices.
For example I don't believe any existing commercial CAs issue
certificates
in another time and place, we invented killfiles because this class of
discussion proves so counter-productive, its better not to see it.
I posit that IETF venue discussions map 1:1 onto godwins law.
I suggest that we separate consensus over standards from IETF process over
venues, and let
It is kind of obvious that if the IETF has taken no opinion on an issue then
the only statement that the IETF chair is going to make in his official
capacity is that the IETF has taken no position.
On Fri, Sep 10, 2010 at 6:54 PM, Richard Bennett rich...@bennett.comwrote:
Fortunately,
On 9/13/10 11:59 AM, Stefan Santesson wrote:
On 10-09-13 7:03 PM, Shumon Huque shu...@isc.upenn.edu wrote:
Authorized by whom? I *think* that here the DNS domain name is one that
the certified subject has itself authorized (perhaps even established
is better) to provide the desired
I don't see any point in having a design conversation based on what might
happen to future iterations of the design.
It is of course possible, likely even that two variants of a syntax would
diverge over time. At some point there will be a decision that future
versions of the format will use only
On 11/09/10 12:34 AM, Alexandru Petrescu alexandru.petre...@gmail.com
wrote:
Le 10/09/2010 14:12, Hesham Soliman a écrit :
When it is away from home it is fully a Host on the egress
interface. When at home fully Router on same. I am happy with it
this way.
= Ok that doesn't
= I thought we were discussing the specific issue of how to solve this
problem in _this_WG_ as I mentioned in my first email. I know what the RFC
says and I wouldn't have done it this way but given this, I don't know how
else you can solve it _here_.
I am open to solve it here and I have
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 the cert. I
mean, an assertion is a positive statement made
ned+i...@mauve.mrochek.com wrote:
On 9/7/2010 5:41 PM, Ross Callon wrote:
It's my sense that it's increasingly difficult to do work in the IETF
without being physically present at meetings, as well...
A significant amount of IETF meeting participants that have their
expenses sponsored
On 9/13/10 12:39 PM, Stefan Santesson wrote:
Peter,
On 10-09-13 6:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Hi Shumon,
As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server
On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote:
On 9/13/10 11:05 AM, Dave Cridland wrote:
Looking at the draft, it seems to read that I should check dNSName
first, and then, only if this matches, check xmppAddr or sRVName.
This
seems odd - sRVName and xmppAddr (and URI) all contain a
On 9/13/10 1:18 PM, Dave Cridland wrote:
On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote:
On 9/13/10 11:05 AM, Dave Cridland wrote:
Looking at the draft, it seems to read that I should check dNSName
first, and then, only if this matches, check xmppAddr or sRVName. This
seems odd -
On Mon Sep 13 20:21:59 2010, Peter Saint-Andre wrote:
On 9/13/10 1:18 PM, Dave Cridland wrote:
Up to you whether you think other people will be as silly as me,
and
what to do about it if so.
A forward reference seem appropriate:
The client MUST match the source domain of a reference
From: todd glassey tglas...@earthlink.net
Why not simply ask Len Klienrock the answer to this question.
Umm, OK idea, wrong person: Len wasn't around the early Internet development.
I actually vaguely recall discussions about the TOS field (including how many
bits to give to each
The story I've heard from Vint Cerf about the TOS field is that it
was put in for AUTODIN-II, a defense network that had multiple
service levels to accommodate the requirements of interactive apps
vs. bulk data apps. Jon Postel wrote RFC 795 - Service mappings on
the
Heh...
The TOS field was designed to mimic the DOD's message preemption scheme - lower
priority messages were only sent if there were no higher priority messages
waiting (a message in this case being more like an email than a packet).
Routine, Priority, Operational Immediate, Flash and Flash
On 9/13/2010 1:03 PM, Noel Chiappa wrote:
Frankly, I doubt we understood the issues that well back then. Remember, this
I would disagree with that but Vint is still around and obviously with
his partner Al Gore should be able to answer this one, or so one would
think.
Sorry - I grew up at SUAI
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 this and other things... ]
Julien: Alex, myself, possibly others
Arnaud Ebalard and myself made substantial comments to the v6ops WG that have
not been addressed yet because WGLC had concluded and publication was
requested. I still believe these should be addressed before publication. I am
copying the comments that we made below:
Arnaud's comments:
[ietf-types removed to spare those who just want to read type applications.]
We need to distinguish between alternate syntactic forms, versus alternate
semantic environments. Translating between versions of the former do not
need
to lose information. Translating between versions of
I think it is important for the IAOC to know when there are issues that they
need to address, for example the issue with food appropriate to muslims that
came up in Dublin. Personally, when I become aware of such issues, I send a
note to i...@ietf.org or iaoc-m...@isoc.org, inform them of the
On Mon, 13 Sep 2010, Fred Baker wrote:
As to food issues, I think the hosts of recent meetings at least have
done a pretty good job of pointing people to travel and food options in
the host web sites. I find myself wondering, though, if the data should
be organized in a different way. If
Hi David,
There is already a field in the registration form for folks to list
dietary restrictions. And, there's a document discussing various
planning issues associated with accomodating the various diets, which
includes discusssion of Fred's point about the hosts providing the
information as
Peter,
Comments in line;
On 10-09-13 9:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 9/13/10 12:39 PM, Stefan Santesson wrote:
Peter,
On 10-09-13 6:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Hi Shumon,
As I see it, this I-D is attempting to capture best current
I'm also irritated by some of the offensiveness in the discussion.
To me, several issues appear to be accessibility issues,
even if the number of IETF Meeting participants affected
by them might be rather small. I think it is not appropriate
to universally apply a 80/20 good-enough principle
On 9/13/10 6:03 PM, Stefan Santesson wrote:
Peter,
Comments in line;
Ditto.
On 10-09-13 9:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 9/13/10 12:39 PM, Stefan Santesson wrote:
Peter,
On 10-09-13 6:08 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Hi Shumon,
As I see it,
Let me say off the bat that I'm now convinced that there is at least some
marginal utility in having an XML representation of iCalendar. And the
barrier for registration of new types is deliberately low, so I now think
there's enough utility in having such a type.
I still think it would be
The IESG has received a request from an individual submitter to consider
the following document:
- 'The LDAP Don't Use Copy Control'
draft-zeilenga-ldap-dontusecopy-08.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from an individual submitter to consider
the following document:
- 'IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios'
draft-arkko-townsley-coexistence-04.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Recommended Simple Security Capabilities in Customer Premises
Equipment for Providing Residential IPv6 Internet Service'
draft-ietf-v6ops-cpe-simple-security-12.txt as an Informational
The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'Requirements for the graceful shutdown of BGP sessions'
draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt as an
Informational RFC
The IESG plans to make a decision in the
The IESG has received a request from the Cga Send maIntenance WG
(csi) to consider the following document:
- 'SEND Hash Threat Analysis'
draft-ietf-csi-hash-threat-10.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
A new Request for Comments is now available in online RFC libraries.
RFC 5962
Title: Dynamic Extensions to the Presence
Information Data Format Location Object (PIDF-LO)
Author: H. Schulzrinne, V. Singh,
H.
A new Request for Comments is now available in online RFC libraries.
RFC 5991
Title: Teredo Security Updates
Author: D. Thaler, S. Krishnan,
J. Hoagland
Status: Standards Track
Stream: IETF
Date:
The IESG has approved the following document:
- 'Transient Binding for Proxy Mobile IPv6'
draft-ietf-mipshop-transient-bce-pmipv6-07.txt as an Experimental RFC
This document is the product of the Mobility for IP: Performance,
Signaling and Handoff Optimization Working Group.
The IESG contact
The IESG has approved the following document:
- 'A Session Initiation Protocol (SIP) Extension for the Identification
of Services'
draft-drage-sipping-service-identification-05.txt as an Informational
RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'LDP IGP Synchronization for broadcast networks '
draft-ietf-mpls-ldp-igp-sync-bcast-04.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks,
The IESG has approved the following document:
- 'Simple procedures for Detecting Network Attachment in IPv6'
draft-ietf-dna-simple-17.txt as a Proposed Standard
This document is the product of the Detecting Network Attachment Working
Group.
The IESG contact persons are Jari Arkko and Ralph
The IESG has no problem with the publication of 'Open Research Issues in
Internet Congestion Control'
draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt as an
Informational RFC.
The IESG would also like the IRSG to review the comments in
the datatracker
The IESG has approved a request to register application/mathml+xml,
application/mathml-presentation+xml and
application/mathml-content+xml MIME media types in the standards tree.
These media types are a product of the W3C. The IESG contact persons are
Alexey Melnikov and Peter Saint-Andre. The
62 matches
Mail list logo
