Multiple Provisioning Domain Architecture
draft-ietf-mif-mpvd-arch-11

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.

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

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.

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.

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.