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

[Steven Barth <[e-mail]>]

>> This is awkward. Foremost, hosts only send RSs when they change links
>> and also replies to RS may be multicasted to all hosts on the links
>> (and often in practice still are).
>
> And what is the issue in that case if all others on the same link see what you are asking for?
No, what I find awkward is that a multicasted RA may be triggered by that special RS. So one client's
RS now changes RAs for everyone else on the link. Also clients usually do not send RS regularly and rely on multicast RAs. Yes RA servers may behave differently but you should make clear how they should and that shouldn't clash with v6ops / 6man etc.

>
>> In any case I don't see the point of adding the container to the RS and / or
>> maybe the Identity. This is just plain ambiguous.
>
> Could you open more the "plain ambiguous" part? Ambiguous how to implement or how/when to use? If you have a better wording in mind I am happy to see it & incorporate it.
What is ambiguous is "However, including a PVD container or identity options inside a Router Solicitation (RS) NDP messages is also possible ". What's the point for making both possible or
more specifically what's the point of having the container in the RS at all?

Or another way: how would I request exactly: PVD identity inside container or just top-level identity?


>
>> 3 "The PVD container MUST NOT be fragmented i.e., should the
>>     IPv6 packet be fragmented, the PVD container and the accompanying PVD
>>     identity MUST both be inside the same fragment."
>>
>> The i.e. makes it ambiguous. Now MUST the whole container NOT be fragmented or
>> MUST every fragment have a PVD Identity or only the first one?
>
> Again, what is ambiguous here? The container must not be fragmented. If the ipv6 packet itself is fragmented the container has to be as a whole in one of those fragment. If you have a better wording in mind I am happy to see it & incorporate it.
You are saying "MUST NOT be fragmented" this is clear, but then you explain that statement to mean ("i.e.") that only identity must be in the same fragment as the container. The explanation itself is a bit strange as well since the identity is inside the container.

>
>> 3 "This MAY imply adding
>>     padding zero octets to the tail of the PVD container option until the
>>     alignment requirement has been met"
>>
>> A MAY padding seems awkward and actually ambiguous. (This also applies to
>> 4 to a lesser degree)
>
> Care to explain more what is ambiguous? You may end up doing padding but not in all cases. If you have a better wording in mind I am happy to see it & incorporate it.
You are using a normative MAY, to me that means if I feel like it I may pad here but if I won't nothing would break.

>
>> 9 RFC 3971 is in informative references but since you use it as source for
>> your signature algorithm should it not be normative?
>
> Hmm.. good point. However, we do not want to mandate entire RFC3971 but only parts of it.

Sure, but I must understand at least parts of that RFC to know the signatures work.



Cheers,

Steven