Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

[Tom Henderson <[e-mail]>]

Mirja,
Inline below (the points still being discussed)....

On Thu, 15 Sep 2016, Mirja Kühlewind wrote:

>>> 3) section 4: Can you give any hints how large the lifetime typically
>>> should be? Can only the original address have an unbounded lifetime (see
>>> section 5) or can I also set the lifetime value in a certain way to
>>> declare the lifetime of this address of unbounded?
>> 
>> Effectively unbounded lifetimes can be set by setting the 32-bit field to 
>> the maximum value.
>
> Okay that's not spelled out in the doc.
>
>>  In practice, I don't know of any guidance to offer, other than perhaps 
>> aligning it with lifetimes of the addresses such as DHCP leased addresses.
>
> That means like useful guidance.
>> 
>> I guess that we could add a statement that an 'effectively unbounded' 
>> lifetime can be set by setting the field to the maximum (unsigned) value.
>
> Would you then also need to talk about risks when doing so...?

I can make the above changes about lifetimes, but for the last one, I am not sure that there are any risks to it-- I won't mention risks unless someone in the list has ideas about any.


>>> 
>>> 3) I believe reading would be easier for me if section 4 would have been
>>> first but not sure...
>> 
>> I'm not sure about reordering sections without more specific change 
>> proposals.
>
> Or you could add a paragraph in the intro explaining where to find what.

OK

>
>> 
>>> 
>>> 4) This docuemnt states several times that mutlihoming is out of scope
>>> and only the handover case is described. I think it would be better to
>>> state this clearly at the very beginning and remove the other cases (I
>>> believe these are anyway kind of left-overs from the previous document.)
>> 
>> Can you point to what you would like to have removed or changed?  Early on, 
>> we moved most of this material to the other draft, and in scanning it again 
>> just now, I am not sure what more to take out or rephrase.  It is hard to 
>> completely avoid the topic of having multiple addresses in this draft, 
>> particularly since we are defining the LOCATOR_SET parameter that is used 
>> in the multihoming specification.
>> 
> Maybe just grab from the word multihoming and double-check if you really need 
> it there. For me it somtimes showed up at place there I thought it's actually 
> not needed to mentioned that again.
> But that's nothing big...

I searched for the word just now and wasn't inclined to remove any of those remaining references, so I think I'll leave it for now unless someone proposes a specific change.

- Tom