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

[Behcet Sarikaya <[e-mail]>]

Hi Joe,



On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/int-area
>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>