Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

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.

(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.

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
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>