Hi Joe,
On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <[email protected]> wrote: > Brian, > > Although I don't disagree with the points below, it's useful to consider > that INT is already working in this area, so I don't see either (a) or (c) > as being relevant unless you expect to shift current INT docs to other WGs > too. > > Respectfully disagree. There has been some time passed since then and many thing happened such as hiaps and a solution draft submission to tcpm. Use case draft contains many more use cases than was discussed before. Different use cases may require different solutions at different levels. I think it is the mystery of this century to find out where this works belongs :-). > (b) just warrants an update. I disagree that privacy concerns will negate > the benefits, though - a HOST ID might also be used to defeat or deny other > claimed identifiers. > > We identified many places for a revision in this document in an informal hiaps Bar BoF this week, the resulting document could become a completely different draft. Regards, Behcet > Joe > > > On 3/6/2014 10:03 AM, Brian E Carpenter 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). >> >> 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? >> >> (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.) >> >> 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 >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
