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

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Aug 2015 11:13:53 -0700

Ian,

Thanks for a detailed review! See my initial comments inline.

7/25/2015, 5:46 AM, Ian Farrer kirjoitti:
> 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.

Same here.. back now ;-)

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

RA and RS are what were in my mind.. I will clarify this and limit the 
PDVs to RA/RS 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.

You probably mean RS not RA?  One of the ideas was to allow "clever" 
unicast RA type of PVD information delivery.. i.e. the router would 
typically advertise just the normal stuff that would go under implicit 
PVD. Once some end host solicits for a specific PVD or PVDs that 
information could be unicasted to that specific end host.

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

s/RA/RS

If the solicitator wants to sign the PVD-ID it solicits for then the 
container is needed.

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

Fragmentation part is outdated and has to be done according to RFC6980.

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

I'll revise the text. Did you check Appendix A.1? It shows what is meant 
with this. For example, it is OK one RA to contain PIOs inside and 
outside the container. Also, if the RA has multiple containers same NDP 
options (like PIO) can be used in every of those.

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

There is no need to carry certificates around. The key hash in the 
container is there for to purpose of locating a proper public key for 
verification. How you learn the public key / certificate is outside this 
specification.

>
>
>
> 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’)

Ack.

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

Ack.

>
> 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’ :-)

Ack.

>
> Old:
> certificates needed to sign PVD containers) belong
>
> New:
>
> certificates needed to sign PVD containers belong
>
> Reason: ) with no corresponding (

Ack.

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

Ack ;-)

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

Ack.

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

Ack.

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

Ack.

Thanks a lot,
	Jouni

>
>
>
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ian Farrer <[email-masked]>
Date: Wed, 19 Aug 2015 10:20:40 +0200

Hi Jouni,

Please see one comment below.

Also, on looking through the draft again, in Figure 1, the convention for DHCP container options is to have an ‘encapsulated options’ field, but there isn’t one in the diagram. Is this intentional?

> If the solicitator wants to sign the PVD-ID it solicits for then the container is needed.
> 

[if] OK. That’s not clear from the current text. Can you add text to clarify when the PVD_CO is/isn’t necessary?

Actually, a section that describes the PVD RS & RA process might be the clearest way of pulling this together in one place.

Cheers,
Ian