[Ballot comment]
Thanks for your work on this draft.  I'm fine with it, but have one minor text suggestion resulting from considering the SecDir review.
http://www.ietf.org/mail-archive/web/secdir/current/msg05457.html

In 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly - and is explicitly stated elsewhere).
From:
  As an example, a node administrator could inject a DNS server which
  is not ISP-specific into PvDs for use on any of the networks that the
  node could attach to.  Such creation / augmentation of PvD(s) could
  be static or dynamic.
To:
  As an example, a node administrator could inject a DNS server which
  is not ISP-specific into PvDs for use on any of the networks that the
  node could attach via the same PvD.  Such creation / augmentation of PvD(s) could
  be static or dynamic.

[Ballot comment]
I have No Objection to the publication of this document.

Here are some comments that you can take or leave in discussion with
your AD.

Some of these Comments and nits come from a "training review" by Alvaro.

---

I think you correctly avoid the use of 2119 language. You can delete the
boilerplate and reference.

---

I think you are talking about dual homed devices rather than dual homed
networks. More precisely, the "node" that is dual homed is not a router
but is a host.

Possibly, you are extending to a dual homed home gateway. But I think
(I hope) you are not intnding to cover dual homed ASBRs or ABRs. And you
are not (I hope) covering dual-homed CPEs such as might provide access
to a substantial enterprise network.

I think that this would benefit from more explanation of scope in the
document.

In practice, you are discussing making connectivity choices rather
than routing choices.

If I have this wrong, please tell me and I can worry about whether this
should have been a Discuss :-)

[BTW Section 4 is great, but it addresses my specific concerns by
example rather than statement.]

---

The document uses "policy" a bit like a unicorn. Of course, there is a
fine tradition of saying "the node will apply locally configured policy"
but you have an opportunity to be much more specific and so far more
helpful for protocol developers and for implementers.

Policies are easy to write in pseduorcode, and I think you know the core
set of policies you expect to see supported. So you could supply some
guidance.
                                       
---

I also think there is a problem with how policy is expected to be
configured. The "nodes" you are talking to are (I think) end-system
hosts rather than routers (see my prvious) and many of these will be
relatively dumb devices and/or have relatively dumb users. These users
will not be capable of making more than very basic policy decisions and
their choics will need to be presented in different terms to the choices
that the device itself makes.

This would benefit from discussion because the policy model will need
more work.

---

Some references to other parts of the document are missing.
2.1 discusses about the possibility of using DHCP to carry information
about the PvD, but there's no reference to the later section that talks
about the same topic.  2.3 talks a little about authentication, but no
reference to the trust section later.
                                       
---

Section 2.1

  Link-specific and / or vendor-proprietary mechanisms for the
  discovery of PvD information (differing from IETF-defined mechanisms)
  can be used by nodes either separate from, or in conjunction with,
  IETF-defined mechanisms; providing they allow the discovery of the  .
  necessary elements of the PvD(s).

  In all cases, nodes must by default ensure that the lifetime of all
  dynamically discovered PvD configuration is appropriately limited by
  relevant events.  For example, if an interface media state change is
  indicated, previously discovered information relevant to that
  interface may no longer be valid and so need to be confirmed or re-
  Discovered.

The first paragraph seems to be superfluous to me (of course I can use
proprietary mechanisms!), but then the second has (what should be) a
normative directive: "must ensure appropriate lifetime".

But, I tend to see "appropriate" and "relevant" as red flags! Why are
you not able to give firmer directives?

---

Section 2.4

  PvD ID is a value that is, or has a high probability of being
  globally unique.
 
If it's capable of not being unique, you have to handle conflict.
If you have to handle conflict, it becomes less important that the
probability of being unique is high.

Maybe...
If two PvDs have the same ID, this conflict must be detected and
resolved. Using a mechanism that selects values that are more likely
to be unique has the benefit of more rapid convergence and no need to
execute the conflict resolution mechanism.

And please be careful with "globally unique". Is "global" really that
or is it constrained?

---

Section 3.3 has references to what seems to be possible solutions or
just other work.  I think that just saying that "any new mechanisms
should consider co-existence with deployed mechanisms" is enough.

---

Section 5.2.3 introduces "PvD-aware applications". 

This is not clearly defined.

Maybe this is just another example of a policy that is not defined in
the document.

[Ballot comment]
A number of comments were submitted by Francis Dupont in his Gen-ART review. Hopefully the authors will be able to see if those comments result in some changes to the text.

[Ballot comment]
In this text:

5.2.3.1.2.  Connectionless APIs

  For connectionless APIs, the host should provide an API that PvD-
  aware applications can use to query the PvD associated with the
  packet.  For outgoing traffic on this transport API object, the OS
  should use the selected outgoing PvDs, determined as described above.
 
does "above" mean "in section 5.2.2"? Whatever it means, perhaps a cross reference would be helpful.

[Ballot comment]
-- Section 1.1 --
As far as I can see, there are no 2119 key words in this document (and I'm glad about that).  You should remove this section and the reference to RFC 2119.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mif-mpvd-arch-09, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: [email protected]
Sender:
Subject: Last Call:  (Multiple Provisioning Domain Architecture) to Informational RFC

The IESG has received a request from the Multiple Interfaces WG (mif) to
consider the following document:
- 'Multiple Provisioning Domain Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email protected] mailing lists by 2015-02-06. Exceptionally, comments may be
sent to [email protected] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document is a product of the work of the MIF Architecture Design
  team.  It outlines a solution framework for some of the issues
  experienced by nodes that can be attached to multiple networks
  simultaneously.  The framework defines the concept of a Provisioning
  Domain (PvD) which is a a consistent set of network configuration
  information.  PvD aware nodes learn PvD specific information from the
  networks they are attached to and / or other sources.  PvDs are used
  to enable separation and configuration consistency in presence of
  multiple concurrent connections.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ballot/

No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
==>Informational, because it doesn't specify any protocol spec and request
IANA number assignment. and It is indicated in the page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
==>
  This document outlines a solution framework for some of the issues
  experienced by nodes that can be attached to multiple networks
  simultaneously.  The framework defines the concept of a Provisioning
  Domain (PvD) which is a a consistent set of network configuration
  information.  PvD aware nodes learn PvD specific information from the
  networks they are attached to and / or other sources.  PvDs are used
  to enable separation and configuration consistency in presence of
  multiple concurrent connections.

Working Group Summary
==>
  The workng group has quite concensus to move forward this document

Document Quality
==>
  there is annunced implementationsof the dcument since it is a
document about architecture. There several OS vendors indicate
that they have implement the specification. There are couple of
good review inputs done by the potential users.

Personnel
==>
  Hui Deng is the Document Shepherd
  Ted Lemmon is the Responsible Area  Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
==> This document was the output of the design team, it is well writen
and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 
==> No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
==> No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
==>No Concerns and Issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
=> Yes, both editor and deisgn team.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
==>No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
==> quite concensus

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
==> No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
==> Done, editor will change

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
==> No

(13) Have all references within this document been identified as
either normative or informative?
==> Yes, they have.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
==> No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
==> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
==> No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
==> There is no IANA requrement.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
==> No

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
==> No formal language exists.