The assumption that simply posting a notice constitutes sufficient
permission to disclose data is one more example of the challenges
we face in producing reasonable policies and following them.
i think you had better have a cite for where a message was posted and
ietf network data were
On 7/14/2010 11:02 PM, Randy Bush wrote:
The assumption that simply posting a notice constitutes sufficient
permission to disclose data is one more example of the challenges
we face in producing reasonable policies and following them.
i think you had better have a cite for where a message
Since your goal in an exchange like this is to keep things unproductive, to
distract from the original goal
you have no concept of what my goal is and have no prerogative to say
so. it is mostly to try and cut through the bs, hyperbole, innuendo
about network experiments which have never
On Jul 13, 2010, at 22:26 , Iljitsch van Beijnum wrote:
On 13 jul 2010, at 18:49, Peter Saint-Andre wrote:
fun technologies like AJAX but also opens up the possibility for
new attacks (cross-site scripting, cross-site request forgery,
malvertising, clickjacking, and all the rest).
Isn't
On 7/15/2010 12:51 AM, Randy Bush wrote:
what my goal is ... mostly to try and cut through the bs, hyperbole, innuendo
...
you go back in my procmailrc. bummer that i will miss your
well known wide-ranging contributions to the internet.
If that's what it take to get you to refrain
I don't think this resolves the issue. The issue is if this information is used
for a call control. Basically do proxies need to be able to look at this to
make decision about what they are going to do. We at least need a Yes/No answer
to this question from the proponents of this work and the
Hi Cullen,
the charter already says that the information may be end-to-end
encrypted by the application. Therefore, proxies will not make any
decision (related or unrelated to call control) based on its contents
because the contents may simply not be available to the proxy.
Do you want the
Hi Stephan,
On Jul 6, 2010, at 3:53 PM, Stephan Wenger wrote:
Hi,
I think this is an excellent straw man for an IETF privacy policy.
I have,
however, two issues with its adoption that makes me question the
wisdom of
an unqualified +1.
Thanks.
First, I'm not quite sure whether the
Ben,
Looks like Gorry I are agreeing on a way forward. Are you happy too?
And with my responses to all your other points?
Cheers
Bob
At 16:09 14/07/2010, Gorry Fairhurst wrote:
I'd be happy with this.
I'm not too worried about the should in lower case, this reads
fine to me the way it
Thanks for the response. Further comments inline. (If I don't comment on a
point, please take that to mean okay :-) )
On Jul 13, 2010, at 6:13 AM, Bob Briscoe wrote:
Ben,
Thank you for your review comments from the GEN-ART perspective.
I think I have dealt with all your points in my
On Jul 14, 2010, at 11:24 AM, Bob Briscoe wrote:
Ben,
Looks like Gorry I are agreeing on a way forward. Are you happy too?
Yes, it looks reasonable to me.
And with my responses to all your other points?
I just responded to the other points in a separate email.
Thanks!
Ben.
Cullen the answer to your question is No.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Cullen Jennings
Sent: Thursday, July 15, 2010 10:06 AM
To: Gonzalo Camarillo
Cc: DISPATCH list; IESG IESG; IETF-Discussion list
Subject: Re: WG Review: Call
At 3:36 PM +0100 7/15/10, Alissa Cooper wrote:
If you have specific ideas of other spots where the document over-promises, a
list would be appreciated. I can take further clarifications back to the
secretariat or whoever the responsible party is.
For me, the biggest over-promise is that someone
Hi Bob,
Thanks for your comments. Responses inline.
On Jul 8, 2010, at 11:05 PM, Bob Hinden wrote:
Alissa,
No hats on, these are my personal views.
I have now read the draft. My overall comment is that I am not
convinced if this is needed and am sympathetic to the views
expressed on
--On Wednesday, July 14, 2010 15:55 -0700 Dave CROCKER
dcroc...@bbiw.net wrote:
...
If no one had suggested either that someone might be capturing
private data or tracking the contents of IETF network traffic
for either evil purposes or unauthorized/ undocumented
research on human subjects,
--On Thursday, July 15, 2010 16:37 +0100 Alissa Cooper
acoo...@cdt.org wrote:
...
I tend to think that privacy risk isn't so much about the
percentage of sensitive data collected as about the
sensitivity of any data collected. The IETF interacts with
credit card numbers, passport numbers,
OK - that removes a large part of the issues I raised. Let me see if I can
propose some text that we could all agree on.
Cullen
PS - Just to be clear these emails are all in my individual contributor role.
That was clear when it was IETF LC comment but given this is all cross posted
to
Greetings again. The IAOC has asked me to prepare a document that describes
extending the IETF Data Tracker to capture and display the progression of
Internet Drafts that are intended to be published as RFCs by the IAB, IRTF, or
Independent Submissions Editor. That document, currently at -02,
Hi Sam,
Thanks for your review.
On Jul 14, 2010, at 4:55 AM, Sam Hartman wrote:
This is a secdir review of the above draft.
The text looks fine. However, I'm concerned that this specification
does
not provide sufficient detail for interoperable implementation. It
makes it clear that a
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Cullen
Jennings [flu...@cisco.com]
I don't think this resolves the issue. The issue is if this information is used
for a call control. Basically do proxies need to be able to look at this
Brian == Brian Weis b...@cisco.com writes:
Brian There is an I-D for one GKMS (draft-ietf-msec-gdoi-update-06)
Brian that includes support for SIDs which could be referenced. It
Brian is expected to head to WGLC soon. Would citing that document
Brian address your concern?
A
At 3:36 PM +0100 7/15/10, Alissa Cooper wrote:
If you have specific ideas of other spots where the document over-promises,
a list would be appreciated. I can take further clarifications back to the
secretariat or whoever the responsible party is.
For me, the biggest over-promise is that
Greetings again. The IAOC has asked me to prepare a document that describes
extending the IETF Data Tracker to capture and display the progression of
Internet Drafts that are intended to be published as RFCs by the IAB, IRTF,
or Independent Submissions Editor. That document, currently at
At 12:12 PM -0700 7/15/10, todd glassey wrote:
Paul - the document looks good but are all of the streams provided the
same oversight processes? Is the IAB stream for instance also controlled
under the IETF oversight controls and processes? how about the other
streams?
All of that is covered in
On 7/15/2010 9:42 AM, John C Klensin wrote:
In principle, I'm in favor of having a published privacy policy.
...
extended repetition of based goals elided
...
...
IMO, those are the types of issues we should be discussing and
that several people on the list have been discussing.
-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On
Behalf Of NomCom Chair
Sent: Thursday, July 15, 2010 2:56 PM
To: IETF Announcement list
Subject: Nomcom 2010-2011: Results of Random Selection
Hi all,
The following is the list of 10
Paul,
You appear to be concerned about exposing the IETF to risk by the
adoption of a privacy policy (but apologies if I am misunderstanding
the concern you expressed). The absence of a privacy policy, however,
actually increases risk to the IETF in at least three ways:
1. As a general
I'm not really keen on getting involved in this discussion any more
than I have been, but I can't help noting one thing:
On Thu, Jul 15, 2010 at 11:50:58PM +0100, John Morris wrote:
2. We have many examples of leading banks, stores, and others
mishandling credit card and other records, so
At 4:08 PM -0700 7/15/10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Representation and Verification of Domain-Based Application Service
Identity in Certificates Used with Transport Layer Security '
John Morris wrote:
1. As a general matter, many organizations that interact with lots of
people (especially collecting financial information from them) use a
broad range of written policies to reduce risk, by plainly stating a
position on an issue so that employees have clear guidance
On Jul 16, 2010, at 12:59 AM, Martin Rex wrote:
is very likely (if not certain) that right now the IETF is operating
in violation of the European Union's Data Protection Directive,
nope, never while they're in the U.S. National data protection laws
do
not apply for someone operating
Hi Alissa,
After following the discussion, I thought that I would share my thoughts. I
hope that you find them constructive.
The document seems almost complete from a technical perspective. I'm
reasonably happy that the details of how private information is stored is
(almost) correct.
Total of 151 messages in the last 7 days.
script run at: Fri Jul 16 00:53:02 EDT 2010
Messages | Bytes| Who
+--++--+
7.28% | 11 | 4.85% |47974 | ra...@psg.com
5.30% |8 | 5.84% |57732 |
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 application that needs the
The IESG has received a request from an individual submitter to consider
the following document:
- 'Teredo Extensions '
draft-thaler-v6ops-teredo-extensions-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has approved the following document:
- 'IPFIX Export per SCTP Stream '
draft-ietf-ipfix-export-per-sctp-stream-08.txt as a Proposed Standard
This document is the product of the IP Flow Information Export Working Group.
The IESG contact persons are Dan Romascanu and Ron Bonica.
A
78th IETF Meeting
Maastricht, Netherlands
July 25-30, 2010
1. Registration: Early Bird Cut-off is TOMORROW Friday, 16 July
2. Social Event
Please note: Breakfast will -NOT- be provided at the MECC (IETF meeting
venue)
===
1) Registration:
Hi all,
The following is the list of 10 nomcom volunteers selected randomly from
this list: https://datatracker.ietf.org/ann/nomcom/2395/
87. Huub van Helvoort, Huawei Technologies;
25. Dorothy Gellert, InterDigital Communications;
14. Gregory Cauchie, France Telecom Orange;
46. Suresh
The IESG has received a request from an individual submitter to consider
the following document:
- 'Representation and Verification of Domain-Based Application Service
Identity in Certificates Used with Transport Layer Security '
draft-saintandre-tls-server-id-check-08.txt as a Proposed
39 matches
Mail list logo
