> Am 16.09.2016 um 07:30 schrieb Tom Henderson <tomh...@u.washington.edu>:
> 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
>> Or you could add a paragraph in the intro explaining where to find what.
>>>> 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