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

[Jouni Korhonen <[e-mail]>]

Hi Steve,

7/23/2015, 4:40 AM, Steven Barth kirjoitti:
>
>
>>> 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

I do not think we are changing anything or assuming new behavior 
regarding _when_ to send RS. The end host just can add PVD information 
to an RS it would send anyway based on the rules in RFC4861.

I do agree that is it unnecessary for others in a broadcast link to see 
PVD information that was hinted by a specific end host. However, there 
are existing tools to around that. But anyway, I can add more 
clarification on the assumptions we have on the use here.

> behave differently but you should make clear how they should and that
> shouldn't clash with v6ops / 6man etc.

I do not see what is clashing with V6OPS/6MAN. Please clarify.

>>> 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?

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.

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

With container Section 3 should be clear enough with that.
Without container, just add the PDV-ID into the RS like any other ND option.

>>> 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.

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.

>>> 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.

While there is no such thing as "normative MAY" I agree using RFC2119 
language might not be appropriate here.

You do not need to add padding if the alignment is met it, which 
sometimes can be the case. Anyway, I would reword the sentence as:
   "This may require adding padding zero octets to the end of the PVD
    container option to meet the alignment requirement."

>>> 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.

Maybe moving the reference to normative part and clarifying in the text 
that only specific sections of that reference are to be used?

- JOuni

>
>
>
> Cheers,
>
> Steven