[mif] Adrian Farrel's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Adrian Farrel has entered the following ballot position for
draft-ietf-mif-mpvd-arch-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/



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