On 17/04/2022 20:14, Christian Huitema wrote:
This submission raises an interesting question for the IETF: how to
treat anonymous (or pseudonymous) submissions?
Perhaps if the author wishes the draft to proceed they will
be happy to self-identify, or perhaps not. I'd not worry
too much about
Hiya,
I didn't read the drafts, but Nick's comments make sense to
me so I'd give those a +1 (modulo not having read the draft
of course:-)
One other thought...
On 19/08/2019 17:07, Kai Engert wrote:
> If the client
> supports it, and if the connection is encrypted, then the client
> sends
Hiya,
On Monday, 27 November 2017, Fred Baker wrote:
> Interesting article, cross-posted from ISOC Public Policy list
I'm not sure it's that interesting, but regardless of that the article is v. US
centric and I'm fairly sure such traditional nationalisms are less important
than previously.
On 05/05/16 15:53, Alissa Cooper wrote:
> +1. If people want to consider privacy as a heading under which we
> group a bunch of different kinds of attacks, that works perfectly
> well I think.
In the case of privacy, not all the bad things are correctly
described as attacks IMO. E.g. leaving
Hi Cyrus,
On 30/01/15 16:39, Cyrus Daboo wrote:
Whilst that is true I don't think we should be required to deal with
issues that are generic to HTTP itself (and in some cases already
covered in the base HTTP specs - e.g. server log information).
I think that's fair, but could you also
Hi SM, Linus,
On 15/06/14 13:14, Linus Nordberg wrote:
S Moonesamy sm+i...@elandsys.com wrote
Thu, 05 Jun 2014 23:39:53 -0700:
| I suggest that the BCP be reconsidered given the lack of privacy
| considerations.
+1
Q: How will that happen?
A: Someone will need to write an I-D:-)
If
Hiya,
On 15/06/14 19:38, S Moonesamy wrote:
Hi Stephen,
At 05:51 15-06-2014, Stephen Farrell wrote:
Q: How will that happen?
A: Someone will need to write an I-D:-)
If someone does such an I-D that is reasonable and improves
privacy, I'll be happy to help that progress.
Ok.
Not sure
On 11/06/14 15:54, Joe Touch wrote:
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike
Hiya,
On 11/06/14 15:38, mohamed.boucad...@orange.com wrote:
Re-,
Please see inline.
Cheers, Med
-Message d'origine- De : ietf-privacy
[mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen
Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc :
ietf-privacy
On 09/06/14 14:46, Brandon Williams wrote:
Would you please indicate where the draft proposes a new identifier? If
you are seeing a proposal for protocol changes somewhere in the draft,
editing work is required in order to either clarify or excise the
associated text.
Fair enough that its
Hi Dan,
On 07/06/14 02:38, Dan Wing wrote:
Stephen,
It seems NAPT has become IETF's privacy feature of 2014 because
multiple users are sharing one identifier (IP address and presumably
randomized ports [RFC6056], although many NAPT deployments use
address ranges because of fear of
I think Ted answered this but one little bit more...
On 05/06/14 21:28, Brian E Carpenter wrote:
Stephen,
On 06/06/2014 00:48, Stephen Farrell wrote:
Hiya,
On 05/06/14 08:05, Hannes Tschofenig wrote:
If you want to review a document with privacy implications then
have a look
: ietf-privacy
[mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen
Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
int-a...@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos
Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
Hiya,
On 05/06/14 08:05
On 22/05/14 07:44, Christian Huitema wrote:
As I mentioned before, the lottery should only return RFC that are on the
standard track and are not obsolete. Otherwise, we are wasting the
reviewers' efforts.
Fair point. Also raised by Karen earlier. [1] If people keep
using it, I'll add a
Hiya,
A while back Scott and Avri sent out a link [1] to
where you can put reviews of old RFCs. So far, that
hasn't seen overwhelming activity, which is a pity,
but maybe understandable, since we're all busy and
doing this is probably not top of anyone's todo list.
As a reminder, the goal is to
On 06/05/14 13:23, Scott Brim wrote:
On Tue, May 6, 2014 at 12:57 AM, Christian Huitema huit...@huitema.netwrote:
I wrote 6 of those. I could go on reviewing more stuff, but the lack of
feedback made me believe that the exercise was futile...
Thanks for doing those btw.
Channeling
Hiya,
On 11/19/2013 09:46 AM, Stephane Bortzmeyer wrote:
On Tue, Nov 19, 2013 at 10:39:00AM +0100,
Eliot Lear l...@cisco.com wrote
a message of 55 lines which said:
in fact there are several different forms.
I find three:
1) Encryption without a peer-specific arrangement. This is
Hi Caspar,
On 09/29/2013 02:52 PM, Caspar Bowden wrote:
Although partly EU-specific, this http://t.co/X4j9iCE6Ox research Note
on FISA/NSA for European Parliament PRISM inquiry might interest list
members (35 pages, interdisciplinary). It was presented on 24th Sep and
has now been accepted,
Hi Avri,
On 09/25/2013 01:08 PM, Avri Doria wrote:
Hi
Very much support the draft and the idea of creating a BCP.
Have also appreciated the discussion on opportunistic encryption,
which I consider akin to a holy grail. Been thinking about it in a
DTN context for a while, but don't feel
On 03/01/2013 05:48 AM, SM wrote:
At 18:25 28-02-2013, David Singer wrote:
in 'privacy considerations' I think we need to explore the privacy
consequences of using protocols 'appropriately'. And there are, and
it's no longer OK not to worry about them as we design protocols.
Yes.
+1
Hiya,
You're entirely correct. I'm still happy to try again:-)
S.
On 12/11/2012 10:01 AM, SM wrote:
At 00:58 11-12-2012, Stephen Farrell wrote:
We did try but it didn't work. Happy to try again. If folks here are
willing to do occasional draft reviews for privacy considerations
please mail
My comments on this below.
Cheers,
S.
General:
1. I like sections 5 6, which by themselves make the
document useful enough to publish IMO. Perhaps consider if
that text with a lot less surrounding text might be a more
useful standalone document?
2. I wonder if threats and countermeasures is
22 matches
Mail list logo
