Re: Mirja Kühlewind's Discuss on draft-ietf-dm m-4283mnids-04: (with DISCUSS)

Mirja Kühlewind <[email protected]> Thu, 16 Feb 2017 13:56:20 +0100
Newsgroups gmane.ietf.mip6
Message-ID <b3f97c9e-d705-6fb9-9805-0e7428ac064f__11367.3250576996$1487249802$gmane$org@kuehlewind.net>
Hi Charlie,

okay, yes I think a MUST is the right thing to do here and I probably already 
enough.

I'll clear my discuss now.

Mirja


On 16.02.2017 01:08, Charlie Perkins wrote:
> Hello Mirja,
>
> My previous answer was intended to mean that I would change to MUST.
>
> Would you be willing to suggest some text about the non-leakage? I
> thought that the point of strengthening to MUST was to ensure that
> sensitive identifier information was not leaked.  If there is something
> more to be said, I'll be happy to say it.
>
> Regards,
> Charlie P.
>
>
>
> On 2/15/2017 4:46 AM, Mirja Kühlewind wrote:
>> Hi Charlie,
>>
>> can you please also answer the question below on SHOULD vs. MUST? Thanks!
>>
>> Also, does it maybe make sense to then add something in the security
>> section that information should/must not be leaked to other networks?
>>
>> Thanks!
>> Mirja
>>
>>
>> On 13.02.2017 22:06, Charlie Perkins wrote:
>>> Hello Mirja and Suresh,
>>>
>>> I am happy to make the proposed changes as agreed below.
>>>
>>> Regards,
>>> Charlie P.
>>>
>>>
>>> On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote:
>>>> Hi Suresh,
>>>>
>>>> sounds all good! I’m happy to quickly resolve my discuss if the
>>>> authors agree!
>>>>
>>>> Mirja
>>>>
>>>>
>>>>> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan
>>>>> <[email protected]>:
>>>>>
>>>>> HI Mirja,
>>>>>
>>>>>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Mirja Kühlewind has entered the following ballot position for
>>>>>> draft-ietf-dmm-4283mnids-04: Discuss
>>>>>>
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>>> this
>>>>>> introductory paragraph, however.)
>>>>>>
>>>>>>
>>>>>> Please refer to
>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>
>>>>>>
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> DISCUSS:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> I would realy like to see the following changes in the security
>>>>>> considerations section:
>>>>>> OLD
>>>>>> "If used in the MNID extension as defined in this
>>>>>>   document, the packet including the MNID extension should be
>>>>>> encrypted
>>>>>>   so that personal information or trackable identifiers would not be
>>>>>>   inadvertently disclosed to passive observers."
>>>>>> NEW
>>>>>> "If used in the MNID extension as defined in this
>>>>>>   document, the packet including the MNID extension SHOULD be
>>>>>> encrypted
>>>>>>   so that personal information or trackable identifiers would not be
>>>>>>   inadvertently disclosed to passive observers.”
>>>>> Is this just for changing the "should" to upper case? I think that
>>>>> makes sense.
>>>>>
>>>>>> Or even better make it a MUST? Is there a reason for only having a
>>>>>> SHOULD?
>>>>> Authors, any specific reason for this to be a SHOULD?
>>>>>
>>>>>> as well as the following change:
>>>>>> OLD
>>>>>> "Moreover, MNIDs containing sensitive identifiers might only be used
>>>>>>   for signaling during initial network entry. "
>>>>>> NEW
>>>>>> "Moreover, MNIDs containing sensitive identifiers MUST only be used
>>>>>>   for signaling during initial network entry and MUST NOT be
>>>>>> leaked to
>>>>>>   other networks.”
>>>>> The statement in OLD: is just a statement of fact that in some
>>>>> networks use temporary identifiers for reattachment and they use
>>>>> long term (and hence sensitive) identifiers only at initial attach.
>>>>> I don’t think it makes sense to change this to 2119 language.
>>>>>
>>>>> Thanks
>>>>> Suresh
>>>>>
>>>>
>>>
>>
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm