Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support

[Jouni Korhonen <[e-mail]>]

Steven,

7/23/2015, 7:22 AM, Steven Barth kirjoitti:
>
>>
>> Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container.
>
> The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and without container). Aside my doubts in general about your use of RSs, I think you should decide that whether you want these signed requests then require that the PVD-ID must always be inside a container otherwise only allow them to be on top-level. Allowing both doesn't really give you anything aside unnecessarily bloating implementations.

Fair enough.. I'll put some more clarifications there for reasons to use 
or not to use container.

>> The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment."
>>
>> I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it.
> Both parts of the sentence make sense to me but not in the "i.e."-combination.
> The MUST NOT be fragmented parts sounds to me as if the whole container must not be fragmented but in the "i.e." you only talk about ID but not other encaps'ed options which is what confused me.
>
> Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here since at least to me its not obvious.

The text says "should the IPv6 packet be fragmented,.." which imho is 
rather clear it means IPv6 level fragmentation.

Now that the intent should be clear could you propose text that makes 
sense to you? Just to avoid having the same discussion again when the 
next version is out ;)

- Jouni

>
>
>
> Cheers,
>
> Steven
>