[Int-area] Opsdir early review of draft-ietf-intarea-provisioning-domains-01

[Tim Chown <[e-mail]>]

Reviewer: Tim Chown
Review result: Has Issues

This is an early review of draft-ietf-intarea-provisioning-domains-01.

Overall: the draft is generally in good shape; with some relatively minor
revisions to address some issues it should be approaching ready for last call
soon.  In my comments below, I am omitting some comments already made by other
reviewers.

The draft is well structured and well written, and is relatively easy to follow.

General comments:

It might be better to be clearer about implicit PVDs, that these are created by
PVD-aware hosts, that automatically create separate PVDs for received
information.

RFC7556 uses the term non-PvD-aware, while the draft uses PVD-ignorant; is
there a reason not to use the architecture terminology?

RFC7556 also talks of mixed mode PVD environments, where a host sees multiple
networks, some carrying PVD options, some not.  That language also isn't used
here.

Is there value in stating / asserting RFC7556 compliance and any differences
(if they exist)?

Does the host generate a 'local' PVD iD for an implicit PVD, or if not what
does it do?  How are ID name clashes avoided?  Perhaps a little extra section
on forming an implicit PvD would be useful?

Specific comments:

Page 1:

Suggest changing

"An increasing number of hosts access the Internet via multiple
   interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix
   configurations.

   This document describes a way for hosts to identify such means, called
   Provisioning Domains (PvDs), with Fully Qualified Domain Names (FQDN). Those
   identifiers..."

to

"An increasing number of hosts access the Internet via multiple
   interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix
   configuration contexts.

   This document describes a way for hosts to identify such contexts, called
   Provisioning Domains (PvDs), where Fully Qualified Domain Names (FQDNs) act
   as PvD identifiers.  Those identifiers..."

Page 5:

The L-bit seems not that different to draft-ietf-6man-ipv6only-flag-00 ... ? 
At least here the node has to be changed anyway to support PvDs, in which case
it can be changed to support this flag.

Page 6:

RFC6106 or RFC8106?

Should that first m be an x?

Page 7:
Section 3.2 - is that first sentence saying the same thing twice?

Multiple RAs is the natural way to do this, but maybe then say supporting
RFC7772 is more desirable in such environments.  Or maybe the host detecting
multiple PVDs can change its behaviour if necessary.

Page 8:
Section 3.3.2:

Should implicit PVDs in dual stack networks carry both protocols in one
implicit PVD?  This section talks only of explicit IPv4.

Page 9:
How does the PvD "allow for" temporary addresses?  There's no RA option for
that, is there?  Or do you mean if the host has a temporary address, it should
prefer it (which it should do anyway by RFC 6724?)

Page 10:
An error message logged or displayed where?  If a user would see this, how will
they understand it?  What do they do about it?

Paragraph 3 - does it matter if the temp address changes when doing this?

Page 13:
OperationAL considerations - add 'al'
And 'For THE sake" - 'add the'

Page 15:
Suggest changing:

"Although some solutions such as IPsec or SeND [RFC3971] can be used
   in order to secure the IPv6 Neighbor Discovery Protocol, actual
   deployments"

to

"Although in theory some solutions such as IPsec or SeND [RFC3971] can be used
   in order to secure the IPv6 Neighbor Discovery Protocol, in practice actual
   deployments"

"to wrong" -> "to provide wrong" ?

connexion -> connection

References:
Check informative and normative, seems to be some in the wrong place.

Page 20:

It says Marcus Keane added in WG-00, but he isn't?