Hi Brian,
On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter < [email protected]> wrote: > a) Since this is fixing some of the damage done by NAT, it's > really unfinished business for BEHAVE, which if iirc was a > Transport Area WG. Just saying... > > b) The word "privacy" doesn't appear in the draft. Discussing > privacy aspects is clearly essential if there is any thought of > advancing this work. Actually I doubt if such a host ID is ever > going to be acceptable from a privacy point of view, unless the > end system is at liberty to change it at random (like RFC 4941). > > Scott Brim said there are no privacy issues. > c) A hard-nosed argument is that since we want to sunset IPv4, > it's time to stop working on ways of making NAT solutions work > better. Is there anything in the use cases that can't be fixed by > native IPv6? > > Brandon could better address this, I think. > (The use case in expired draft > http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 > is not at all convincing to me, especially when adding the privacy > argument. It actually seems to describe a bug in 3GPP. But in any case, > the draft appears to suggest mitigations.) > > It is kind of a bug in 3GPP, but remember that 3GPP makes protocols for their own hosts called UEs. While here we are talking about fixed hosts. This is what is called fixed mobile convergence, or policy for convergence, to add more acronyms to the discussion. Regarding privacy, in this use case, the communication is one hop and the edge router already knows about the host, it is connected. So the privacy property is not the same in this use case. Regards, Behcet > Regards > Brian > > On 07/03/2014 05:28, joel jaeggli wrote: > > Greetings int-area and hiaps-mailing-list folks, > > > > I realize that this is midweek at the IETF, however this question is not > > far from several discussions I've had this week. > > > > I have been asked to consider AD sponsoring > > > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 > > > > In the process of considering doing so I'd like to get some input with > > respect to: > > > > A. The appetite for pursuing some or any of this work in existing > > working groups, and in particular within the INT area. > > > > B. A consensus basis for moving beyond RFC 6269 into active work in this > > area. > > > > C. How we address concerns raised by the IETF community expressed > > through draft-farrell-perpass-attack when evaluating scenarios and > > beginning to address requirements and solution-space. > > > > Obviously these are complex questions and I do not expect that we will > > arrive at answers easily nor does work on this or other drafts depend on > > answering them, however it's part of the dialog. > > > > Thanks > > joel > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
