Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02
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 worse the way it can be perceived which is less (or not at all) rational as the long and silly history of the "privacy extensions for stateless address autoconfiguration in IPv6" (RFC 3041 and 4941) has shown. So there is a technical and a "political" argument against the whole HOST_ID idea. Unfortunately the IETF (and this mailing list) can only deal with the first one. Regards francis.dup...@fdupont.fr PS: to discuss about the technical point IMHO no HOST_ID proposal brings a clear advantage. The real issue (address sharing breaks the address == identity assumption) has to be solved by the impacted part (i.e., people should accept this assumption doesn't apply)... ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02
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 second kind I am strongly against the 3.3 (if not changed into a SHOULD NOT :-) and I suggested to "NOT RECOMMEND" all proposals perhaps at the exception of one (i.e., leave one proposal without any recommendation). Regards francis.dup...@fdupont.fr PS: IMHO only the not advertised port set makes sense, any other proposal deployed in countries where privacy is protected (any place in European Union for instance) should make the ISP to be sued... PPS: we can postpone the discussion to Berlin meeting (privacy concerns are pushed in Germany clearly behind the sillyness point :-). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] about draft-ietf-intarea-nat-reveal-analysis-01.txt
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 we (the IETF) have recommended such a mechanism. Regards francis.dup...@fdupont.fr PS: Winston Churchill quote: "It has been said that democracy is the worst form of government except all the others that have been tried." PPS: in the case google was hacked to not help you: amesys lybia (3rd suggestion on amesys, which btw is to be sold :-) bluecoat syria (these prove that an active technology is unfortunately not so needed) ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 said I wanted an "operational definition" => BTW what is the operational definition of security (just to know)? Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 source IP address does in a non-shared address environment if it is not false it is very far to be complete: the HOST_ID (and other methods) should be compared to a shared address environment without HOST_ID (and any other method) too. I know it is incomplete but I really would like to capture the privacy concerns you have in that section. => it should be fine to explain the IETF doesn't endorse the use of this, etc. I leave the wording to better skilled people, the idea is: the document explains "if you have to do it, you should do it this way" and no more. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 > >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 to state what exactly it is > >supposed to mean. > > => it is in the European Convention on Human Rights as a legal > principle so there is at least a basis but I am afraid it won't really > help. As a (French) lawyer explained to me one day, a legal text must be > as less accurate as possible so it can be applied to more than one > particular case so a legal principle... => I (mis?)interpreted your message as asking for a formal definition of the term "privacy" so I tried to answer. > PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights > (see the article 8 about privacy). Yes, of course. We should base new policies on the official opinion of all the people who can be bothered to work on Wikipedia articles. => you are free to follow the pointer to the text itself and not stop at the comments which, I agree, can't be blindly assume as impartial. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 it (i.e., even I don't like the methods it describes I share the idea to not leave ISPs invent their own shaky methods). Based on input from a directorate that is proposed in a doc that is still a draft. => it doesn't matter as soon as we can put a name on it (i.e., what matters is the result, there is no need to fix the process first when we can get it). The privacy considerations IAB doc is misguided IMO. We don't need a required section for every squeaky wheel. => perhaps but the idea is to enforce authors to not ignore the question. It worked well for security which at its time was far to be easy too. So IMHO it is the hard but right way, i.e., without this we can get documents with a real impact on privacy but no argument about it (and I am afraid you are contributing to prove this :-). Regards francis.dup...@fdupont.fr PS: I propose to use our energy to other things... ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 to state what exactly it is supposed to mean. => it is in the European Convention on Human Rights as a legal principle so there is at least a basis but I am afraid it won't really help. As a (French) lawyer explained to me one day, a legal text must be as less accurate as possible so it can be applied to more than one particular case so a legal principle... None of this is to say it is impossible to add what you suggest. But it needs something more than to say "privacy" over and over again: to begin with, how is one supposed to have any clue what features might have privacy implications if one simply doesn't know what "privacy" means? => it is clearly a job for the IAB and fortunately this seems to have been well understood (cf draft-iab-privacy-considerations) To lean on your analogy a little, security discussions often exhibit the sorts of problems I'm talking about here, too. That is nowise an argument that we don't need the sort of operational definition I'm talking about. On the contrary, many of the nastier security discussions I've ever seen boil down to a disagreement about the boundaries of the term "security". => I am sure it is easy to find some examples where a particular point is viewed in favor or against the security according to different people. And we can expect some trade-offs between security and privacy too... Regards francis.dup...@fdupont.fr PS: http://en.wikipedia.org/wiki/European_Convention_on_Human_Rights (see the article 8 about privacy). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 documents related to privacy until it is published... Right now, that document is an individual submission with no track. => perhaps you are not about the same 'that document' than me, cf draft-iab-privacy-considerations-01.txt which is far to be an individual submission without a clear future. It is quite premature to be holding up this document on an issue that the IETF has not yet decided on. => as there is a solution proposed by a third party and I wish to leave the possible announce to him I moved to offline... Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 ignore its impact on privacy. In a document produced by a standardization body, this could be even considered as a provocation. But the solution is easy: add a privacy consideration section which explains the technical impact and show the IETF doesn't endorse in any way the not-technical aspects of the implementation of methods described in the spec. It's premature to draw any conclusion about the merits of the draft at such an early stage. => if it is about the not-technical merits this should stay true for the whole life of the document... There has been a few drafts recently on which questions about privacy were raised. If privacy wasn't an issue, the web would be faster ( www.afasterinternet.com ). The discussions in several working groups point to a privacy void, i.e. there isn't any guidance about limiting data exposure when designing a protocol. => IMHO this should change. We solved a similar issue about security, there is no reason the same method won't work for privacy. And we should agree to deny privacy issues is not the right way, shouldn't we? Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 text issue... People are going to ignore privacy considerations if there isn't any feedback or expertise to discuss such issues. => here my feedback was the same from the beginning: the privacy impact of the nat-reveal I-D is sensible and must be correctly handled. I'd like to have been more positive... Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 to understand better why you do not want this to be adopted and brought under wg change control so that we can make the necessary changes. => perhaps I was not very clear: my concern is about only a publication under the draft-ietf-* name of the document in its current state, of course I am perfectly fine if the WG takes control, makes the changes I believe are required and then publish it (and I believe Hannes shares this opinion even I prefer he answers for himself). Thanks francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 more attention to them than needed. Francois (and others) => I don't know who you are speaking to? If there is a legitimate (and/or legally required) need for privacy => this is not the point: bt any standard, including technical, the document is very far to address correctly its impact on privacy. So we (me, Francois? and others) simply ask to get this fixed before it is published with a name beginning by draft-ietf-*. Note this is very far from being new, I have warned since the first presentation some meetings ago (March one) than particular care should be required about the sensible privacy aspect in the document. Now you can read it (if you haven't yet) and find how this was translated in the current version, and perhaps you'll understand why this aggravates me a bit. simply trolling with threats of lawsuits => it is not trolling: the problem of the privacy is a legal one and as I am a not lawyer individual the best way to get a legal opinion is from people whom it is the job. Now I expect to get the privacy considerations fixed (oops, there is not yet such a section in the document) before having to show our concern has real basis. vague handwaving about privacy issues for EU citizens. => I have given the pointers to the European Convention on Human Rights in a previous message (20110909 according to grep). Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 most at the exception of USA) and as usual with many legal issues we can expect not very rational arguments from the outside... (cf the embedded MAC address for IPv6). To summary I am afraid of the perception of this from the outside, and I argue the IETF *must not* endorse the document (i.e., publish it with a draft-ietf-* name) with the privacy considerations in the current state. Statements like "this is bad for privacy" are not technical; => unfortunately this is a wish, not an argument, as the real issue is legal and not technical from the beginning as you should get from the issue history. statements like yours which talk about a persistent identifier are technical, and helpful in framing the problems and how HOST_ID does not make the problem any worse than today's publicly-routable IPv4 addresses and tomorrow's publicly- routable IPv6 addresses. => in fact the end of your statement is not fun at all: as far as I know there is a legal lobby in Germany arguing publicly-routable IPv6 addresses is a threat against privacy... I repeat this again: ignoring this kind of problems is *not* the right way to get rid of them. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
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 share my concerns?) intimately believe this whole stuff should be simply forbidden to preserve the privacy but they don't follow the right way. To summarize my position: 1- I believe this (the devices described in the document) infringes my rights as an European citizen (cf European Human Rights) but I am not a lawyer so it has to be tested in a court 2- one is not allow to organize public meetings to discuss how to perform clearly illegal actions, in particular from a standardization body 3- as far as I know the legal umbrella of the IETF is the Internet Society so I propose suggest if no other way to solve the legal issue to sue the Internet Society at the next meeting in Paris in a French court on the 1 and 2 basis (e.g., to pay a court bailiff to officially see 2...) Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] RE : IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 information that we have is the source IP address. => with only the source IP address there is nothing you can do so your argument is not about the problem analyzed in Mohammed's I-D, but for authorities who need to understand what is a CGN (or to make CGNs illegal... :-). Being able to identify the users behind NAT, for example by using the HOST_ID proposed in this draft, is in my opinion an important problem to be solved no only for content providers but also for Service Providers. => the HOST_ID doesn't solve anything if the authorities provide only the source IP address in their identification requests, and if they provide more they can provide the source port... Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] RE : IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 with mid or long lifetime, it may be used to track a host. => I believe you didn't catch my idea: the HOST_ID should be hard to use to track a host: the enhance privacy is one of the rare benefits from using a CGN so it is *not* something we should suppress. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] RE : IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 not solve the issue of blacklisting for instance all hosts belonging to a given /64 prefix (e.g., all users of a hotel, IETF meeting, etc.). => and what you want to do if for instance someone blacklists all hosts belonging to a give /32 prefix? So if you still want to go forward I strongly suggest to make HOST_ID hard to reverse (i.e., to get the user should require the NAT logs) and short life. Med: We have this text in the current version. Do you think we should add more? => add far more 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 persistent it may be used to track a host (similar to persistent IP addresses). => it doesn't need to be persistent: it just need to have medium/long life. So IMHO you should develop the text from the last statement and forget any reference to the source IP address. (or give up about the whole idea) Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 know its laws (treaty in this case), i.e., this should be true at al places where privacy is protected and BTW privacy is supposed to be a goal in IETF protocols too... Regards francis.dup...@fdupont.fr PS: I am more concerned by the potential damages this could do to the IETF's image, this is why I said I am happy these I-Ds are personal contribs and not WG items. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] RE : IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 democracies. There is a section in the I-D which discusses privacy concerns. => yes, the I-D confirms the proposed mechanisms could reduce the privacy and decribes it as "what the source IP address does in a non-shared address environment". If this seems technically valid I remember well some European lawyers already described the IP source address as being a piece of personal data. 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 :-). So if you still want to go forward I strongly suggest to make HOST_ID hard to reverse (i.e., to get the user should require the NAT logs) and short life. Regards francis.dup...@fdupont.fr PS: cf. the discussion about this topics in the mailing list during the March IETF meeting. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 against the end-user privacy. So even without the legal problem at some places some of us already believe this (HOST_ID stuff) is bad idea. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]
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 item. Regards francis.dup...@fdupont.fr PS: I am not a lawyer PPS: I know that to consider the source IP address is a personal piece of data is silly but who did say lawyers should be rational (:-)? PPPS: of course the best should be to simply go to IPv6! ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Scott Brim, intarea WG co-chair
(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
Re: [Int-area] Scott Brim, intarea WG co-chair
Wellcome Scott! francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] mic comments on draft-matsushima-v6ops-transition-experience
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 population but this doesn't match what one should get in the real world: a small number of end-users sharing the same address and likely living in the same block... I believe the same thing about the similar argument on the provisioning: stateful is supposed to make overbooking easier, i.e., you can put a hard limit L to the number of ports per user with L * <#user> >> <#ports>. With other words, between BSDs which pre-allocated the swap space when processes request it, and Linux which kills arbitrary a process when the swap space is full, you should guess what I prefer... Regards francis.dup...@fdupont.fr PS: when applicable stateless solutions are better just because by definition they are scalable. Exactly the opposite for a CGN. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-george-ipv6-required-01.txt --- what about IPsec ?
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 :-). BTW this was fixed in the requirements for IPv6 nodes and similar documents. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Last Call: (Logging recommendations for Internet facing servers) to BCP
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. => another basic questions: is any of these an IETF blessed protocol? It doesn't seem to be the case so IMHO these protocols should adapt to the logging recommendations, not the opposite, and of course this should be done where these protocols were developed. Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Last Call: (Logging recommendations for Internet facing servers) to BCP
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-balancers in the path, the "original" source port may be lost. The source port number that will be passed to the target server may not be accurate and hence does not meet the initial requirment. => where are these load-balancers and as they perform a NAT function why they don't log mappings they create? Or if they are placed in front of servers why they are not integrated in the logging system? Regards francis.dup...@fdupont.fr ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
