Ole,
I noticed the same thing when I was making my booking. As a precaution,
I put a note in the Comments block saying that I expect the terms of
the IETF contract to be followed, with a copy of the terms from Ray's email.
--RB
Ole Jacobsen wrote:
I can confirm that the confirmation
Hi all,
Wanted to let folks know about an experiment that some participants from
the GEOPRIV working group have put together for this IETF. Using the
IETF network infrastructure as a location source, we've set up a
location server [1] that offers location information over the HTTP-based
HELD
As some of you might have noticed, some GEOPRIV participants ran a small
experiment, using the IETF network as a base for location-based
services. We had a few folks try it, and learned a lot, but three main
things:
1. Interworking with the IETF NOC was really pleasant (Thanks, guys!)
2.
$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1
2008/05/24 15:03:19 ekr Exp $
S 4.3.1.
Devices that establish VPN connections for use by other devices
inside a LAN or other closed network could serve as a LIS, that
implements the HELD protocol, for those other
I wanted to let folks know about an experiment that some folks from the
GEOPRIV and ECRIT working groups have been working to set up at IETF 71
to see if we can deliver some basic location-based applications
(including emergency calling), using the IETF network as a platform.
The prinicpal
... and of course, I mean IETF 72 in the first paragraph ...
Richard Barnes wrote:
I wanted to let folks know about an experiment that some folks from the
GEOPRIV and ECRIT working groups have been working to set up at IETF 71
to see if we can deliver some basic location-based applications
Hi Julian,
I'd like to try to answer one of your questions:
As far as I understand, HELD is used to query for location information.
Right now, the details of the query are encoded in a POST body as
defined by the XML Schema in
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 just like
Hi all,
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
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 just like
Chris,
At recent IETFs, I've found it helpful to have a couple of machines in
the terminal room. Having machines that are pre-configured saved me the
time of setting up my machine to work with the printers when I just
wanted to quickly print out a draft during a break.
So it might be
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 just like
Hi all,
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
This debate has nothing to do with the security properties of DNSSEC.
A basic assumption of the DNS is that what the authoritative server for
zone says is, well, authoritative. The structure of DNS itself entitles
JPNIC to point ac.jp wherever they want; by using a name within the .jp
Ben,
Thanks for your review. With respect to the HTTP issue you raise, is
your claim that the HTTP binding prevents the use of Digest or Basic
based on this sentence from Section 6.3?
HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
If so, then I think that's a
Phil,
That's a specious argument. As several others have noted on this list,
it's perfectly feasible for any relying parties (sovereign nations or
otherwise) to not use the IANA root, simply by creating their own root.
This is a little more complicated than just redirecting IP traffic,
but
Martin:
Regarding #2, I would feel more comfortable with your text if it had the
strength of a RECOMMENDATION. Making a specific policy configuration a
MUST NOT doesn't make sense. Also, this discussion is missing the
possibility of client authentication in TLS, which falls under the same
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 just
It would seem in the open spirit if the IETF to make this a standing
order for t-shirt art, wouldn't it?
On Friday, July 31, 2009, Dave CROCKER d...@dcrocker.net wrote:
Gregory M. Lebovitz wrote:
I have been asked about this several times this week, so I'd like to clarify
here for all.
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 just
As a side issue, it appears that Ekr is chairing TLS twice, at least
according to the linked TLS tools page.
--Richard
On Mon, Aug 24, 2009 at 3:55 AM, pasi.ero...@nokia.com wrote:
The tools WG pages used to have diffs between charter versions
(see e.g. http://tools.ietf.org/wg/tls/charters/ --
Being a relatively short-term IETF participant, I lack the history that
many on this list have, but since Jari asked for comments, I'll provide
some.
Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and
others that it makes sense to have IESG notes be mandatory for the ISE
This brings us to the question of the identifiers: it's certainly
true that systems which are anonymous but linkable offer a higher
level of privacy than those which do not. However, it's often
possible to determine which identifier a given person has
(e.g., by observing a specific persons card
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 just
(g) many hurt Chinese engineers participate to the IETF and very
politely do not react: have them been invited to comment?
Everyone on the IETF mailing list has been invited to comment and that
certainly includes Chinese engineers.
Indeed, I wonder if there is something to be learned from
+1
Cullen is not inquiring after social policy, he's asking what the
practical constraints are likely to be if there is a meeting in China.
This is a sensible question, worthy of a thoughtful, well-researched
response.
I suspect you -- and most of the rest of us -- can't give a
definitive
attend IETF meeting, how about U?
Tian
-邮件原件- 发件人: ietf-boun...@ietf.org
[mailto:ietf-boun...@ietf.org] 代表 Richard Barnes 发送时间: 2009年10月10日
8:53 收件人: Ole Jacobsen 抄送: Theodore Tso; Henk Uijterwaal;
IETF-Discussion list 主题: Re: Legality of IETF meetings in PRC. Was:
Re: Request
From the perspective of the world outside the IETF, this is already
the case. An RFC is an RFC is an RFC...
--Richard
On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote:
Who would like to adopt this idea:
http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-
all-01.txt
Stéphane,
In GEOPRIV, where we have a need to specify a specific endpoint in
order to request its geolocation, we were specifically asked by
carriers looking at CGN to add a port field to the identifier space:
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
Circles are not impossible, just a pain:
http://tools.ietf.org/html/rfc5491#section-5.2.7
Likewise for normal distributions:
http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-04
On Mar 16, 2010, at 2:57 PM, JFC Morfin wrote:
I developed tools to convert RFC from/to mediawiki pages.
Hey all,
This message is announcing a bar BoF (lunch BoF) on Location
Coherence -- interoperability between different location protocols and
APIs -- for the lunch break on Wednesday of the IETF week. Location
is still TBD (ironically).
Full announcement here:
+1
On Mar 17, 2010, at 9:03 PM, Tony Hansen wrote:
+1
On 3/17/2010 12:18 PM, John R. Levine wrote:
If we could agree that the final XML was authoritative, and if
necessary let them hire someone to fix xmlrfc so it can produce the
text version without hand editing or postprocessing, that
This meeting will be held at 11:45 today in the Carmel room. Sorry
for the late notice.
--Richard
On Mar 17, 2010, at 4:11 PM, Richard Barnes wrote:
Hey all,
This message is announcing a bar BoF (lunch BoF) on Location
Coherence -- interoperability between different location protocols
[Added IAOC]
Iljitsch: Thanks very much for this information. I was not aware of
this:
The MECC conference center is 2 - 3 kilometers from the city center,
where the restaurants are.
IAOC: I had been getting used to the idea of Maastricht, with it being
historic, nice city center and
I hear they were thinking about making it an IPv6 extension header,
but they were afraid it would never get deployed that way.
--Richard
On Apr 1, 2010, at 2:47 PM, Bob Braden wrote:
Fred Baker wrote:
So - does RFC 5841 update RFC 3514, or obsolete it?
Silly question, Fred. What
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
Friendly reminder from BCP 61: Security is a MUST implement
http://tools.ietf.org/html/bcp61#section-7
On 8/30/11 12:46 PM, Eric Burger wrote:
Can you give an example of where a dangling SHOULD makes sense? Most often I
see something like:
SHOULD implement security
meaning
Hi David,
The penalty for getting a quick response for the first time is that the second
response takes longer :) Inline.
- The additional text in section 3.1 stating that the policy URI is a shared
secret with a forward reference to the security considerations section
removes
that use the http: URI scheme.
END
One of my concerns behind wanting this general SHOULD is that there's no
assurance that an http: URI will stay confined to the local network that is
being relied upon to secure it.
Thanks,
--David
-Original Message-
From: Richard Barnes
The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.
In some practical terms, perhaps, but there are extensibility schemes that
allow the payload (addressing bits, in this case, to go on forever, in
theoretical terms.
I look forward to
Seems like it depends on your definitions of abusive and legitimate. Do
you have an example?
On Feb 21, 2012, at 5:56 PM, Murray S. Kucherawy wrote:
We like to see interoperability reports contain information about features of
a protocol that are used vs. unused, so that if and when the
Reviewer: Richard Barnes
Review Date: 7 September 2012
IETF LC End Date: 29 August 2012
IESG Telechat date: (unknown)
Summary: Ready
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 just like
.
Document: draft-ietf-6man-udpzero-06
Reviewer: Richard Barnes
Review Date: 2012-10-08
IETF LC End Date: 2012-10-02
IESG Telechat date: 2012-10-11
Summary: Ready
Comment:
In general, the document is well-written and seems to cover the relevant
considerations well. I agree with Barry's DISCUSS
would be wrong. The idea here is that applying _punitive_ action (such
as removal from a position) retroactively is not fair,
Oh, for heaven's sake. This is nothing to do with punishment. This
is a straightforward administrative problem. Turning this into an
opportunity to exercise a
On Nov 30, 2012, at 2:10 PM, Wes Hardaker wjh...@hardakers.net wrote:
John C Klensin john-i...@jck.com writes:
I think changing the default is fine. I'd also be reluctant to
see the normal HTML version go away immediately but would be
especially reluctant to see the plain text version go
It gets worse if you head west to the Tampa bay...
http://www.tampabay.com/news/publicsafety/crime/man-shot-at-st-pete-pizza-joint-had-been-complaining-about-slow-service/1266589
On Jan 4, 2013, at 2:55 AM, Ole Jacobsen o...@cisco.com wrote:
You have been warned.
Anecdotal data point number N+1...
As an occasional implementor of IETF specs, I have to say it's much easier to
check my conformance if I can just grep for MUST and SHOULD. It's also
easy for developers to get in the bad habit of ONLY doing those things that are
clearly marked in that way.
: draft-ietf-ccamp-lmp-behavior-negotiation-10
Reviewer: Richard Barnes
Review Date: 2013-02-02
IETF LC End Date: 2012-01-21
IESG Telechat date: 2012-02-07
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
Overall, this document seems very clear and readable. Thanks
Hey Lou,
That text looks fine to me!
--Richard
On Tue, Feb 5, 2013 at 9:24 AM, Lou Berger lber...@labn.net wrote:
Dan/Richard,
On 2/4/2013 10:05 PM, Lidan (Dan) wrote:
Hi Richard,
Thanks for the review of this draft!
Section 2.1. Would be helpful to either include the old
: draft-ietf-mpls-tp-ethernet-addressing-05
Reviewer: Richard Barnes
Review Date: 2013-02-11
IETF LC End Date: 2013-02-18
IESG Telechat date: TBD
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
The document is mostly very clearly written. (Thanks!) It would have
http://www.worldtimebuddy.com/
On Wed, Feb 27, 2013 at 8:37 AM, Victor Kuarsingh
victor.kuarsi...@gmail.com wrote:
On 2013-02-27 4:53 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
On 27/02/2013 09:28, Brian Trammell wrote:
On Feb 27, 2013, at 10:20 AM, Tim Chown
I think you may be over-estimating the filtering power of the
Internet-Draft system.
On Thu, Mar 7, 2013 at 2:08 PM, Sam Crooks sam.a.cro...@gmail.com wrote:
not a Joke, Warren (and IETF).
The petition process is the best I have found to put in unsolicited
suggestions. The RFI process and
IESG, with name/area: http://www.ietf.org/iesg/past-members.html
IAB, with name/affiliation: http://www.iab.org/about/history/
On Wed, Mar 20, 2013 at 10:16 AM, Jorge Contreras cntre...@gmail.comwrote:
On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman
m...@lilacglade.orgwrote:
Hi
I do not really think the legal angle is helpful in resolving this problem.
(Which country's laws do we need to comply with?) Let's treat these legal
ideas as considerations that we should be thinking about, not something
where we should be striving for strict compliance.
--Richard
On Wed,
, Apr 2, 2013 at 9:10 AM, Stewart Bryant stbry...@cisco.com wrote:
Resending due to Richards change of address.
Stewart
On 11/02/2013 23:45, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART
Hi Stewart,
I think this resolves my issues.
Thanks,
--Richard
On Mon, Apr 8, 2013 at 6:53 AM, Stewart Bryant stbry...@cisco.com wrote:
On 02/04/2013 15:28, Richard Barnes wrote:
Thanks for following up, and for the re-send. Just to be clear, I do not
mean these as blocking points
On Fri, May 24, 2013 at 2:03 PM, joel jaeggli joe...@bogus.com wrote:
On 5/24/13 10:43 AM, Doug Barton wrote:
While it's unlikely that I would be able to attend, I think it's an
excellent idea for reasons already better stated by others, and BA is a
very nice city.
The only suggestion I
Indeed, there has already been some coordination between the groups, going
back about a year:
http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf
http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt
So my read of the situation is much less dire than James's. As I
understand it, the
call, which is
non-ideal from a privacy and battery perspective.
At least in the US, many of the WebRTC services would be considered
interconnected VoIP, so they are indeed subject to 911 obligations.
Henning
On May 26, 2013, at 3:57 PM, Richard Barnes r...@ipv.sx wrote:
Indeed, there has
, however: Right now, users only have a binary
choice about location disclosure, even though I suspect many users would be
fine with location disclosure for 911 only, not disclose my fine-grained
location for any purpose you like.
On May 27, 2013, at 1:51 PM, Richard Barnes r...@ipv.sx wrote
I would suggest we not try to sort out on this list which sorts of Internet
services are subject to American regulations.
On Tue, May 28, 2013 at 2:20 PM, James Polk jmp...@cisco.com wrote:
At 11:58 AM 5/28/2013, Ted Hardie wrote:
On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto:
Cf. http://tools.ietf.org/html/rfc5513
On Thu, Jun 13, 2013 at 5:30 AM, t.p. daedu...@btconnect.com wrote:
- Original Message -
From: l.w...@surrey.ac.uk
To: ietf@ietf.org
Sent: Wednesday, June 12, 2013 10:55 PM
Subject: Renaming RFC
RFC should be renamed to Resulted From
Hi Faiz,
Thanks for bringing your idea to the IETF. The best way to propose your
idea is to write down the details in an Internet-draft. That helps make
sure that everyone understands how your system works. There are some tools
for writing drafts here:
http://tools.ietf.org/
Once you've
It also makes it obvious to everyone that Peter is using PGP. Which serves
a pedagogical function, I guess. :)
On Mon, Sep 9, 2013 at 1:12 PM, Peter Saint-Andre stpe...@stpeter.imwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/9/13 11:02 AM, Cyrus Daboo wrote:
Hi Peter,
Indeed, the number Joe was counting was the number who filled out a
registration form. Counting those who actually paid their registration
yields closer numbers.
rbarnes$ for n in $(jot 15 73); do
att=$(curl -s https://www.ietf.org/registration/ietf${n}/attendance.py; |
grep -o Yes | wc -l);
67 matches
Mail list logo
