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

Okay.

> Am 16.09.2016 um 07:30 schrieb Tom Henderson <[email protected]>:
> 
> 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

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