In your previous mail you wrote:
This is a late comment but I think it is worth raising it.
=> as the gen-art reviewer of the document I'd like to
understand the comment.
This I-D recommends to log the source port number for
internet-facing servers. But due to the presence of load-b
In your previous mail you wrote:
Med: To understand the issue, I recommend you the following
reading: http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
Med: You can make a quick search on the XFF practices in
load-balances/proxies to see how it is used for logging purposes
In your previous mail you wrote:
I fear "IPsec required for IPv6" would slow deployment of IPv6.
=> IMHO it doesn't matter as the IETF has *no* way to enforce
such a thing: you can require IPv6 boxes to be blue with red points,
it will have the same effect (other to show it is ridiculous :-).
In your previous mail you wrote:
Is it not true, then, that the better multiplexing ratio disappears
(while it is often presented as the main advantage of ISP's running
the NATs instead of CPE's)?
=> IMHO this better multiplexing ratio is an illusion: it relies on
a heterogeneous pop
Wellcome Scott!
francis.dup...@fdupont.fr
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
(oops, too happy, now with correct spelling :-)
Welcome Scott!
francis.dup...@fdupont.fr
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Perhaps I repeat myself but as far as I know solutions to the
draft-boucadair-intarea-nat-reveal-analysis problem are illegal
at some places, in particular in European Union (and at a level
which overrules national texts)...
IMHO this issue should be clarified before adopting any document
as a WG i
In your previous mail you wrote:
I would argue the opposite: the IETF should completely discard this
issue. Much of the rationale behind RFC 2804 would apply equally
here.
=> it is a very different issue than wiretapping, here the problem
is the proposed mechanisms are clearly agains
In your previous mail you wrote:
I don't know if you are talking about legal data storage or
something else
=> no, I am talking about the privacy principle which is included
in the European Convention on Human Rights and at the exception of
the USA is in similar texts in all modern democra
In your previous mail you wrote:
Are you saying that what draft-boucadair-intarea-nat-reveal-analysis
argues for cannot be implemented in the European Union?
=> IMHO it may be implemented but not be deployed, and I cited
the European Union only because as a citizen I am supposed to kno
In your previous mail you wrote:
As for your comment about IPv6, I'm afraid we have similar issues
=> no, in IPv6 we have RFC 4941 and the point of control is not
at the same place (i.e., nobody trusts ISPs to protect privacy :-).
Med: This is not the point. RFC4941 does no
In your previous mail you wrote:
NEW:
The volatility of the HOST_ID information is similar to the source IP
address: a distinct HOST_ID may be used by the address sharing
function when the host reboots or gets a new internal IP address. If
the HOST_ID is assigned w
In your previous mail you wrote:
The enhance privacy that you consider *a rare benefit from the CGN*
it is actually a BIG issue for a Service Provider, because we are
quite often requested by the authorities to be able to track who
was the user who did something and the only informati
I share your concern about the (or the lack of real) privacy considerations.
I know the IETF is still dominated by people from a country where
privacy is not a fundamental right so can be considered as a side question.
BTW I question if some authors (one lives in the same city than me so
should sha
In your previous mail you wrote:
Frankly, I find all this new-found privacy concern to be misplaced,
=> it is not new found, I raised the same issue at least at the last
two IETF meetings. And BTW it is not really a technical issue, it
is a legal one in many countries (I'd like to believe mos
In your previous mail you wrote:
Technical objections would be useful. Please make some technical
objections.
=> I'll be as friendly as you: don't make this kind of comments
in public without looking at the history of the problem first.
francis.dup...@fdupont.fr
___
In your previous mail you wrote:
> If this privacy concern persists, ISP's will be required
> to deploy CGN for privacy. We do not want that.
=> nobody wants that but it is the kind of things which can happen
from privacy activists if we continue to provoque them in place to
just not pay
In your previous mail you wrote:
I have seen the concerns that you and Hannes have raised, and I have
requested Alissa to help out the authors with the privacy aspects of
this document. I can understand why you are objecting to the document
being published as is, but I would like t
In your previous mail you wrote:
I would like to point out that the author of the draft requested
feedback on the ietf-privacy mailing list [1] (I could not find the
original message is not in the archive).
=> yes, the author didn't receive the help we could expect to fix
the privacy
In your previous mail you wrote:
I think that Francis' point is that the authors are writing a
specification which, if implemented, may be illegal to deploy in some
jurisdictions.
=> the word "may" is the right one. If the spec should stay about
technical stuff IMHO it is an error to
In your previous mail you wrote:
If and when a document describing the privacy considerations
requirements has passed IETF review, sure.
=> to wait this document is published as a RFC to add a privacy
consideration section to the nat-reveal I-D is no more reasonable
to block all documen
In your previous mail you wrote:
This claim requires an adequate operationalization of "privacy". What
exactly does one mean by this? Most of the claims I hear about it,
including a number of the windy assertions that there is a fundamental
right (whatever that is) to it, seem never
In your previous mail you wrote:
Again, stop holding this doc to requirements that gave not been
agereed by the IETF as a whole.
=> I clarified my objection to the nat-reveal document: I really want
to get it with a privacy considerations section and I have no technical
concerns about i
In your previous mail you wrote:
As a preliminary note, I will suggest to you that your quoting
conventions ...
=> as I can't see a difference between mine and yours I suggest
to address this in private.
> >This claim requires an adequate operationalization of "privacy". What
In your previous mail you wrote:
As you know there is already a "Privacy" Section in the document:
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2
=> you refer to this statement:
The HOST_ID does not reveal more privacy information than what the
In your previous mail you wrote:
> On Mon, Nov 28, 2011 at 02:36:45PM +0100, Francis Dupont wrote:
> >
> > => I (mis?)interpreted your message as asking for a formal
> > definition of the term "privacy" so I tried to answer.
>
> I think I
I still deeply dislike the reveal idea but at least the new version has
a decent privacy implication part.
As I don't want to get the IETF associated with names like Amesys or
Blue Coat, I suggest to use only negative recommendations at the
exception of one mechanism so nobody should be able to say
In your previous mail you wrote:
> What analysis is missing from draft-ietf-intarea-nat-reveal-analysis
> to weigh the drawbacks of the 8 solutions.
=> there are two kinds of drawbacks: the technical drawbacks and the not
technical drawbacks, e.g., the impact on privacy... Note because if the
In your previous mail you wrote:
> You keep saying "privacy", but without explaining the problem or
> how IPv4 address sharing makes privacy better or worse than IPv6.
=> there are two levels about the privacy problem: the technical one
which is explained/addressed in the draft (section 4) and
29 matches
Mail list logo
