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?