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

[Steven Barth <[e-mail]>]

Hello everyone,

some probably non-conclusive comments on the NDP-support draft.

3 "However, including a PVD container or identity
   options inside a Router Solicitation (RS) NDP messages is also
   possible (actually, in this way a host can solicit for information
   from a specific provisioning domain)."

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

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.


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?


3 S-bit: Could this not just be encoded as "Name Type" = 0?

3 "Name Type": I find it peculiar that the name type is selectable but not
the signature algorithm (at least to my understanding).

3 "Key Hash": Since this doesn't have a length field a client not understanding
the name type cannot interpret anything in the container even if it does not
want to check the signature. I'm not sure if this is intended.

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)

4 Is it useful that PVD ID is a separate TLV if a container MUST have exactly 1 in it
and the stand-alone use (e.g. in RS) is probably questionable?

6 Again as for dhcpv6, timestamps may not be ready for checking at the point
where RAs are evaluated since these are essentially bootstrap protocol and
not all devices do have RTCs or unauthenticated NTP server options may be used
to tamper with wallclock settings.

9 RFC 3971 is in informative references but since you use it as source for
your signature algorithm should it not be normative?




Cheers,

Steven