[mif] Review of draft-ietf-mif-mpvd-ndp-support-01

[Ian Farrer <[e-mail]>]

Hi,

Here’s my review of the draft.

Cheers,
Ian

Please note - I’m going to be on holiday for the next couple of weeks so if I am slow in responding to any replies, then this is why.

-----------

These comments are in addition to the one that I have raised in the mail thread https://mailarchive.ietf.org/arch/msg/mif/3LQ6W1kj7nwOIvI_KGfbKoyOkCs
Depending on the outcome of this discussion, other changes to this document may be necessary.


Section 3

a) Which NDP messages can include this option? RA and RS messages are mentioned, but is it envisaged
that e.g. a host may make an NS request which contains the PVD_ID option, in order to 
find other hosts which are configured for the same PVD? My feeling is that in this document
and at this stage of the development, they should be restricted to RS with requested PvDs
and RAs with advertised PvD NDP messages only.


b) I’m not clear on what the intended solicitation process for a host requesting information for a specific PvD. 
The behaviour seems to be that in an RA, a client includes a list of the PVD_ID options which it is interested in receiving.

But, para 2 of section 3 says that the RA can also include the PVD_CO. What is this for? Do the requested 
PVD_IDs need to be in a container, or are they listed directly in the RS options (or are both allowed)?

c) Para 2
The PVD container MUST NOT be fragmented"
RFC6980 prevents NDP messages from being fragmented at all, so perhaps this should be 
referenced?
Would it also help to describe how to correctly handle this situation (i.e. send two RAs with
un-fragmented PvD containers)


Section 5
"The PVD container option MAY be used to encapsulate any allocated IPv6 NDP options, which may appear more than once in a NDP message."

Ambiguous text - Is the intention to say that the PVD container, or the encapsulated options may appear more than once in the NDP message?
If it is the encapsulated options, then the sentence restricts the allowable options to only those options which can appear more than once
(i.e. an option which can only appear once can not be encapsulated). I guess that this is not the intention.


Section 6
Per PVD certificates/sigs sound like they are going to cause problems with the NDP message length.
In the appendix of RFC6980, there’s some information about message sizes when carrying 
certificates. 864 bytes is given as the smallest size for the certificate itself (1024 bytes), so for a 1280 v6 MTU, 
2 and you’re bust.





Language / grammar nits etc.

Throughout: s/a NDP/an NDP
Reason: With acronyms, ‘a’ or ‘an’ before a consonant/vowel is chosen based on the sound of the letter when spoken (i.e. ’n’ is pronounced ‘en’)

Section 1
Old
This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating
provisioning domain information along with any configuration that will be provided.

New
This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating
provisioning domain information along with any configuration which is associated with that provisioning domain.

Reason: new wording more clearly associates the configuration with the PVD it is being provisioned for.

Section 3
Old:
Implementations that do not recognize  the PVD container option plain ignore it and also skip PVD container
option "encapsulated" NDP options normally without associating them into any provisioning domain (since the
implementation has no notion of provisioning domains).

New:
Implementations that do not recognize the PVD container option will ignore it, and any PVD container
option "encapsulated" NDP options without associating them into any provisioning domain (since the
implementation has no notion of provisioning domains).

Reason: Old version reads a little ‘colloquially’ :-)

Old:
certificates needed to sign PVD containers) belong

New:
 
certificates needed to sign PVD containers belong

Reason: ) with no corresponding (


Old:
the length of the PVD identifier option and the optional Key Hash/Digital Signature/Padding.

New:
the length of the PVD identifier option, and the optional Key Hash/Digital Signature/Padding.

Reason: Oxford comma. Might as well put it in now and save the editor the job.

Section 4
Old: …  the natural NDP options’ alignment.

New: ... the natural NDP option’s alignment.

Reason: Option is singular and doesn’t end with an ’s'

Section 5
Old:
If the receiver of the PVD identity option does not understand any of the ID-Types,
then anything belonging to this provisioning domain  MUST be silently discarded.  
This would mean the PVD identity option, the PVD container option and all other options.
 
New: 
If the receiver of a PVD identity option does not have one (or more) of the received
ID-Type format’s implemented, then all configuration and options which are associated with
the unimplemented PvD(s) MUST be silently discarded.

Reason: Original wording could be mis-interpreted to mean that the entire NDP message, including
options associated with implemented ID-types must be discarded


Section 7
Old: The options TBD1 and TBD2 are described in Section 3 and Section 4

New: Options TBD1 and TBD2 are described in Section 3 and Section 4 respectively.

Reason: Clarity