Multiple Interfaces and Provisioning Domains Problem Statement
draft-ietf-mif-problem-statement-15

[Ballot comment]
I've cleared my Discuss position.

However, the minor changes regarding the term "provisioning domain" and the action "attach to a provisioning domain" have not addressed my fundamental concern that these terms are confusing and potentially inaccurate.  As I wrote previously, I think there is an intermediate action to accept configuration information from a provisioning domain, and then forward traffic according to the configurations of various interfaces.  I don't think, in practice, the relationship between the origin of specific configuration information and its eventual use in interface selection is maintained in any device.

The term "attach to a provisioning domain" hides the intermediate step and, as I read the document, has implications for interface selection and traffic forwarding that I don't think are reflected in practice.

[Ballot discuss]
(Edited based on e-mail discussion of previous DISCUSS)

I don't understand the behavior described as "attached to a
provisioning domain" and the process referred to as "selection of the
[...] provisioning domain".  Is there really a direct relationship
between a "provisioning domain" and node behavior?  Or is there an
intermediate step, in which the node receives various provisioning
objects, updates internal node-scoped and interface-scoped
configuration tables based on those objects, and then makes vraious
operational decisions independent of the source of the information in
the configuration tables?

For example, in section 3.7:

  In a MIF context, the node may handle simultaneously multiple domains
  with disparate characteristics, especially when supporting multiple
  access technologies.  Selection is simple if the application is
  restricted to one specific provisioning domain: the application must
  start on the default provisioning domain if available, otherwise the
  application does not start.  However, if the application can be run
  on several provisioning domains, the selection problem can be
  difficult.


What does it mean for an application to be "restricted to one specific
provisioning domain" or "run on several provisioning domains"?  What
does it mean for an application to select the provisioning domain on
which it is to run?  In section 2, a "provisioning domain" is defined as:

      A set of consistent configuration information (e.g.  Default
      router, Network prefixes, DNS,...).  One administrative domain may
      have multiple provisioning domains.

This definition doesn't seem to have anything to do with choosing
an interface and a network for outbound traffic.

[Ballot discuss]
I have not completed my detailed write-up for the revised document.  I
do have a couple of issues that we can work through while I complete
my more detailed review.

The document needs to clarify the model described as "attached to a
provisioning domain" and the process referred to as "selection of the
[...] provisioning domain".  Is there really a direct relationship
between a "provisioning domain" and node behavior?  Or is there an
intermediate step, in which the node receives various provisioning
objects, updates internal node-scoped and interface-scoped
configuration tables based on those objects, and then makes vraious
operational decisions independent of the source of the information in
the configuration tables?

It would likely be helpful to have a model (somewhere) of the
interactions among the various components that control outbound
datagram routing.  I see references to applications, session managers
and the IP stack all making routing decisions.  How are these pieces
assumed to interact?

[Ballot discuss]
This is an updated position.

An updated DISCUSS that includes a reference to the SECDIR review.

This is a placeholder DISCUSS while the authors, AD, and SECDIR reviewer work on some expanded text for the security considerations section.  See the thread: http://www.ietf.org/mail-archive/web/secdir/current/msg01963.html

Update follows:

There were two points made in the review the second was addressed.

> 1) Lower layer authentication and encryption
>
> It's possible that some interfaces may have link layer or IP layer
> encryption and authentication.  Its possible that this characteristic
> might be used in determining how configuration parameters are processed.
> Some connection managers may already do this to a certain extent.  I
> think this should be listed as a consideration in the appropriate
> sections of the document (3.1, 3.6,5)
> 

This seems reasonable. Authors, can you suggest some text and update the draft?

The -09 version includes text in 3.1 but not 3.6 and 5.  Was text omitted from 3.6 and 5 on purpose?

[Ballot discuss]
I have not seen any discussion of the Routing Area Directorate review performed by Joel Halpern. I should like to see the issues raised debated and resolved before this document goes forward.

===

This is a Routing Area Review.  Please consult with your document
shepherd before making any changes.  Consult the Routing Area
Directorate page for information on the review process
(http://www.ietf.org/iesg/directorate/routing.html)

Document file: draft-ietf-mif-problem-statement-07.txt
Document Name: Multiple Interfaces Problem Statement
Reviewer: Joel M. Halpern
Review Date: 15-August-2010
Last Call End Date: 2010-08-23
Telechat Date: 2010-08-26
Summary: This document is nearly ready for publication as an
informational RFC.
    However, there are some items that should be attended do.

Comments:
Moderate:
Section 5, item 3 on routing, sub-bullet 2 describes an underlying
problem attributed to routing.  As routing is sued by this section, it
seems to apply to host interface selection, first hop router selection,
and general path selection.  As written, the text seems an invitation
for the MIF working group to delve into the issues of host control over
routing path selection.  Please do not go there.  I sould suggest
tightening the text up to make it clear that what is meant is policy
based itnerface and first-hop router selection, where policy may reflect
the many things listed in sub-bullet 2.

Minor:
Section 2: MIF Characgteristics:
It is a bit odd to list the characteristics of a MIG host in the
Terminology section.  It seems like a section on its own.

In the thrid bullet in the characteristics, the English usage is a bit
misleading.  The text says "A MIF host can attach to more than one
provisioning domains."  I suspect that "can" here means "may be", that
is that the document recognizes the possibility of such attachment.  As
written, the text almost seems to be requiring special logic for
handling multiple domaisn, which while it may be a conclusion of the MIF
group is clearly not a requirement for the problem statement.  (The
following item uses "may be" in exactly the way I would recommend for
item 3.)

The last item in the list of characteristics refers to a MIF host as
potentially forwarding packets.  While the document is clear that such
behavior is out of scope (which is good), I wonder if it would be better
to note the IPv6 terminology and say that such devices are not hosts?
(they are nodes, but they are not hosts.)  The reason I raise this is
that the host-like logic in a router is probably also out of scope for
MIF, isn't it?

Section 3.5 on Finding and Sharing IP Addresses with Peers contains
clear, and to the best of my knowledge accurate, information.  However,
I can note determine what the relationship of this topic is to MIF.  I
suspect that the intention is to say that MIF will not be working on NAT
traversal of referral issues.  But the text does not seem to say that.
Similarly, for section 3.6 on APIs and connection managers, the text
talks about the issues, but is unclear as to whether they are in or out
of scope for MIF.

Yours,
Joel M. Halpern

[Ballot discuss]
An updated DISCUSS that includes a reference to the SECDIR review.

This is a placeholder DISCUSS while the authors, AD, and SECDIR reviewer work on some expanded text for the security considerations section.  See the thread: http://www.ietf.org/mail-archive/web/secdir/current/msg01963.html

[Ballot comment]
My concern is already captured in DISCUSS posiotns held by Ralph,
  so I am not going to pile on.  However, I do want to make it known
  that I also have the same concern.  (Note the same concern was
  raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)

[Ballot comment]
Some of the symptoms don't derive from the stated operational environments.  For example, in section 4.1:

  3.  H1 keeps only one set of DNS server addresses from the received
      configuration objects and kept S2 address.  H1 sends the DNS
      query for a.private.example.com to S2.  S2 asks its upstream DNS
      and gets an IP address for a.private.example.com.  However, the
      IP address is not the same one S1 would have given.  Therefore,
      the application tries to connect to the wrong destination host,
      or to the wrong interface of the latter, which may imply security
      issues or result in lack of service.

seems to be in conflict with the constraint at the top of the section that 'name "a.private.example.com" [...] is within the private namespace of S1 and only resolvable by S1'; that is, if the constraint holds, H1 would not get a resolution for a.private.example.com by sending a resolution query to S2.

Also in section 4.1:

  5.  H1 has resolved an FQDN to locally valid IP address when
      connected to N1.  After movement from N1 to N2, the host tries to
      connect to the same IP address as earlier, but as the address was
      only locally valid, connection setup fails.  Similarly, H1 may
      have received NXDOMAIN for an FQDN when connected to N1.  After
      movement from N1 to N2, the host should not assume the FQDN
      continues to be nonexistent.

what does "movement from N1 to N2" mean?

Still in section 4.1:

  A MIF host may also be provisioned with a Interface-specific suffix
  search list ([I-D.ietf-mif-current-practices]).  In this situation,
  if H1 sends DNS query on I1 using the search list tied to I2, the
  namespace could be not valid on I1 and the name could be not
  resolved.

isn't the described host behavior clearly a bug in the host stack?

From Andrew Sullivan, dns-directorate review:

First, this is an implicit recognition that the DNS namespace is not
actually a single, unified namespace.  I think that's just
acknowledging the facts in the world, but I know there are people
opposed to that.

Second, it seems to be setting up the mif WG to be trying to "solve"
the DNS split-views problem.  I think this effectively means that
we're (i.e. the dns-dir crowd) will need to keep on top of MIF.

[Ballot discuss]
I have a fundamental problem with the way in which this document characterizes the problems resulting from the simultaneous use of multiple interfaces as all resulting from receiving different configuration objects from different administrative domains.  In my opinion, some of the example problems in the document are a result of other problems inherent with the simlutaneous use of multiple interfaces.  This distinction is important because , again in my opinion, there are mif problems which cannot be solved by changes to the configuration behavior in the host.

For example, in section 4.1, the symptom:

  4.  S1 or S2 has been used to resolve "a.private.example.com" to an
      [RFC1918] address.  Both N1 and N2 are [RFC1918] addressed
      networks.  IPv4 source address selection may face challenges, as
      due address overlapping the source/destination IP addresses do
      not necessarily provide enough information for making proper
      address selection decisions.

is inherent in having interfaces connected to networks using overlapping address spaces, and cannot be solved by improvements to the configuration behavior.

Similarly in section 4.1:

  5.  H1 has resolved an FQDN to locally valid IP address when
      connected to N1.  After movement from N1 to N2, the host tries to
      connect to the same IP address as earlier, but as the address was
      only locally valid, connection setup fails.  Similarly, H1 may
      have received NXDOMAIN for an FQDN when connected to N1.  After
      movement from N1 to N2, the host should not assume the FQDN
      continues to be nonexistent.

How is this problem caused by configuration objects from different domains?

I see two ways to address my concern: either be explicit in limiting the problem statement and mif deliverables to those problems that can be solved with proper handling of configuration information from multiple admin domains or extend the scope of this document to include any problems that may result from the disparate environments (IP reachability, DNS resolution, QoS) to which interfaces are attached.

[Ballot comment]
This is an useful document. The comments below are not blocking, but in case they are considered they could improve readability:

1. In section 3.1 the following statement is made:

>  Network discovery and selection on lower layers as defined by
  [RFC5113] is out of scope of this document.  Moreover, lower layer
  interaction such as IEEE 802.21 is also out of scope.

It would be good to be more exact about what is IEEE 802.21 - for example

s/lower layer interaction such as IEEE 802.21/handover and interoperability between lower layer networks such as the mechanisms defined in IEEE 802.21/

An informative reference to IEEE 802.21 would also be in place.

2. Expanding acronyms at their first occurance would be useful.

3. The OPS-DIR review performed by Menachem Dodge also included a number of useful editorial comments which I suggest to consider.

[Ballot comment]
Some very minor editorial suggestions:

Is there a missing word (I think "may" at "may have") in the first sentence of
the introduction?

Should the first sentence of 3.6 start with "An Application"?

[Ballot comment]
INTRODUCTION, paragraph 4:
>    of its provisioning domain.  Some configuration objects are global to

  Nit: s/domain/domains/


Section 1., paragraph 1:
>    A multihomed host have multiple provisioning domains (via physical

  Nit: s/have/has/


Section 1., paragraph 4:
>    values from each provisioning domains, such as different DNS servers

  Nit: s/from/for/


Section 3.1., paragraph 1:
>    [RFC5113] is out of scope of this document.  Moreover, lower layer

  Nit: s/is/are/


Section 3.2., paragraph 2:
>    The host maintains a route cache table where each entry contains the
>    local IP address, the destination IP address, Type-of-Service and
>    Next-hop gateway IP address.  The route cache entry would have data
>    about the properties of the path, such as the average round-trip
>    delay measured by a transport protocol.

  Modern stacks don't store transport info in the route cache anymore.
  Suggest to remove the last sentence.


Section 3.2., paragraph 3:
>    As per [RFC1122], two models are defined:
>    o  The "Strong" host model defines a multihomed host as a set of
>      logical hosts within the same physical host.  In this model a
>      packet must be sent on an interface that corresponds to the source
>      address of that packet.

  And it will only be received on that interface, too.


Section 3.2., paragraph 4:
>    o  The "Weak" host model describes a host that has some embedded
>      gateway functionality.  In the weak host model, the host can send
>      and receive packets on any interface.

  This doesn't really make the distinction clear. A weak host can send
  and receive packets ***addressed to or from any of its source
  addresses on any of its interfaces***.


Section 3.5., paragraph 2:
>    Some application protocols do referrals of IP addresses and port
>    numbers for further exchanges.

  A referral also includes the transport protocol to be used.


Section 2., paragraph 0:
>    2.  For the IP1 address family, H1 has one default route (R1, R2) per
>        network (N1, N2).  IP1 is reachable by both networks, but N2 path
>        has better characteristics, such as better round-trip time, least
>        cost, better bandwidth, etc....  These preferences could be
>        defined by user, by the provider, by discovery or else.  H1 stack
>        uses R1 and tries to send through I1.  IP1 is reached but the
>        service would be better by I2.

  Note that "better" here is entirely dependent on what kind of traffic
  is to be exchanged with the destination, i.e., it is transport
  protocol and application dependent. General preferences of any sort
  are therefore likely to be wrong.


Section 11., paragraph 23:
>    [RFC4477]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
>              Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
>              Issues", RFC 4477, May 2006.

  Nit: Unused Reference: 'RFC4477'

[Ballot discuss]
Section 3., paragraph 1:
>        2.  Interfaces of a MIF host can provide different
>            characteristics (e.g. round-trip time, least cost, better
>            bandwidth, etc....).  So, user, applications or network
>            provider may wish to influence routing to take benefit of
>            this heterogeneity.  However, with current host
>            implementations, neither the Type-of-Service nor path
>            characteristics can be taken into account in the routing
>            table.

  DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are
  the first hops into *paths* of different characteristics, but what
  service quality an application sees across a path depends on the
  destination, the transport protocol in use and the communication
  patterns of the application. There is nothing here that can be
  optimized without taking these into account.

New version looks reasonable. Remaining comments:

I have reviewed the new version. It is much better, thanks! I have sent the draft forward to IETF Last Call. However, I did note the following issues that you might want to correct in the meantime:

> 2. On a MIF host, some source addresses are not valid if used on
>    some interfaces.  In this situation, the source address
>    should be taken into account in the routing table; but
>    current host implementations do not support such a feature.

... used on some interfaces or even on some default routers on the same interface.

> 1. In the MIF context, routing information could be specific to
>    each interface.  This could lead to routing issue because, in
>    current host implementations,Routing tables are node-scoped.

Some formatting issues here.

Jari

I have reviewed this draft.

It has a good discussion of the problem space, but still needs some work. My detailed comments are below. But the main issues from my perspective are:

1) We need a crisper definition of the problems for Section 5

2) The definition of a MIF host needs to be tightened up.

3) The draft refers to MIF issues or purpose in several places as a sort of a set of problems not yet solved by existing standards. I feel that it would be better for the draft to talk about, say, problems of hosts with multiple interfaces and include all the associated issues even if they have already been solved or are being solved.

4) The draft is very centered around IP layer functionality, and has minimal text about application functionality, middleware such as ICE, and problems such as referrals. This part of the draft should be expanded.

Technical:

>    A MIF host is defined as:
>
>    o  A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host
>    o  Configured with more than one IP addresses (excluding loopback,
>      link-local)
>    o  On one or more provisioning domains, as presented to the IP stack.
>    o  The interfaces may be logical, virtual or physical.
>    o  The IP addresses come from more than one administrative domains.
>    o  The IP addresses may be from the same or from different address
>      families, such as IPv4 and IPv6.
>    o  Communications using these IP addresses may happen simultaneously
>      and independently.
>    o  Communications using these IP addresses may be tied on all the
>      possible provisioning domains, or, at least, on a limited number
>      of provisioning domains.
>    o  While the MIF host may forward packets between its interfaces,
>      forwarding packets is not taken into account in this definition.

Does this definition actually translate to a host with more than one IP address from more than one administrative domains? The other conditions seems explanatory rather than definitive.

>    o  Configured with more than one IP addresses (excluding loopback,
>      link-local)

Do two identical net10 addresses on different interfaces count? (If it is possible, not sure about that.)

> o  Communications using these IP addresses may be tied on all the
>    possible provisioning domains, or, at least, on a limited number
>    of provisioning domains.
> 

I do not know what the above statement means. I cannot even parse the English language here. Are you trying to say something about with whom the communications of the host are with?

> 3.3. Mobility and other IP protocols
>
>    This document assumes hosts only implementing [RFC1122] for IPv4 and
>    [RFC4294] for IPv6, and not using any kind of new transport
>    protocols.  It is not required for the host to support additional IP
>    mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP,
>    HIP, RRG, LISP or else.  Moreover, the peer of the connection is also
>    not required to use these mechanisms.

RRG is not a protocol, and LISP is not affecting hosts.

And you should probably give some pointers to the already published RFCs on multiple interfaces and mobility/idsplit designs.

But more importantly, I'm not sure the style of discussion is appropriate here. You are not writing a requirements specification for "MIF hosts" somehow separate from all other hosts in the Internet. Your real point, I think, is that mobility and id/loc split mechanisms are not considered in your analysis. If so, you could just write:

"This document is only concerned with the situation where the hosts implement [RFC1122] for IPv4 and [RFC4294] for IPv6 and not special-purpose support for transport layers, mobility, multi-homing, or identifier-locator split mechanisms. Dealing with multiple interfaces with such mechanisms is somewhat separate problem and under active study elsewhere in the IETF [RFC4960,RFC5206,RFC5533,RFC5648,I-D.draft-ietf-mptcp-architecture]."

> Issues on using the Default Address Selection were found [RFC5220] in
> the context of multiple prefixes on the same link.  New work
> [I-D.chown-addr-select-considerations] discusses the multiple
> attached networks scenarios and how to update the policy table.
> 

You should refer to RFC 5221 as well. Also, I think the I-D that you want to refer to as new work is draft-ietf-6man-addr-select-sol.

> ICE does not solve the MIF issues, such as the incompatible
>    configuration objects received on different interfaces.
> While referrals feature does not
> solve the MIF issues, it is related since,

At these points in the text you have not really defined "the MIF issues".

> ICE does not solve the MIF issues, such as the incompatible
> configuration objects received on different interfaces.  However, ICE
> may be of use for address selection if the application is ICE-
> enabled.
> 

Mumble. I would argue that address selection is part of the MIF problem. In any case, I think these types of statements need to move away from "X does not solve the MIF problem" style to "X does A, B, and C but not D or E" style.

> Some application protocols do referrals (i.e. provides reachability
>    information to itself or to a third-part)

Perhaps you could pull the definition of a referral from somewhere. I think the definition is wider than passing information to third parties. For instance, storing information for your later use can also be a problem.

>  Grobj
>    [I-D.carpenter-behave-referral-object] defines the problem with
>    referrals in today's IP networks.  While referrals feature does not
>    solve the MIF issues, it is related since, in a multiple provisioning
>    domain context, referrals must provide consistent information
>    depending on which provisioning domain is used.

This RFC should really stand on its own and describe the problem, pointing to past solutions and ongoing efforts as needed. But individual drafts and BOF proposals that went nowhere aren't very real efforts that could you rely on in terms of solutions, for instance. Perhaps you could just say that "The general problem of referrals is related to the multiple interface problem, since ... The general referral problem has been studied elsewhere [I-D.carpenter-behave-referral-object] [I-D.ietf-shim6-refer], but no real solutions exist today."

> Application Programming Interface (API) may expose objects that user
> applications may use for the MIF purpose.

"The MIF purpose" is not defined yet. Perhaps you could just have said "... for dealing with multiple interfaces".

> If examples exist, as
> reminded above, there is no set of high level API to provide all
> required services for a connection manager expected to address IP
> configuration issues in a context of multiple provisioning domains.
> Moreover, various operation system implementations deliver different
> sets of high level API.

I cannot parse this text. Perhaps you wanted to say:

"However, there is no standardized high level API, and implementations differ also in the functionality that they provide."

> 3.7. Above IP Layers
>
>    The MIF issues discussed in this document assume no changes in
>    transport protocols or applications.  However, fixing the issues
>    might involve these layers.  For instance, an application may
>    implement the connection management function (as decribed in
>    preceding section).

This section has multiple problems. First of all, the assumptions about not dealing with multihoming mechanisms was already stated earlier. Secondly, the document itself states that ICE and application logic is used to solve some issues related to multiple addresses, such as address selection. You could argue that Section 3.5 is all about "above IP layers".

> 4.1. DNS resolution issues

This section should also deal with search path issues. In addition to server addresses, you will also receive DNS search paths via DCHP or RAs. "a" might resolve under the search path, but again, search paths for different interfaces may differ.

> A MIF host (H1) has an active interface(I1) connected to a network
> (N1) and another active interface (I2) connected to a network (N2).
> When the user or the application is trying to reach an IP address
> (IP1), the following situations may occur:
> H1 receives from both networks (N1 and N2) an update of its
> default address selection policy.  However, the policies are
> specific to each network.  The policies are merged by H1 stack.
> Based on the merged policy, the chosen source address is from N1
> but packets are sent to N2.  The source address is not reachable
> from N2, therefore the return packet is lost.
> 

Unlike the other issues discussed in the draft, this one is somewhat speculative, given that there are few deployed or even specified address selection policy distribution mechanisms. It might be good to prefix this paragraph with some statement that such mechanisms are under development (or pointers to the existing ones, if they exist).

> 2.  Same configuration objects (e.g.  DNS server addresses, NTP
>    server addresses, ..) received from multiple provisioning
>    domains are usually overwritten.
> 

"usually" -- I don't know if that's really the case. Does the existing practices document support this conclusion? If you are not sure about this, use "may be overwritten" instead.

> 2.  Same configuration objects (e.g.  DNS server addresses, NTP
>    server addresses, ..) received from multiple provisioning
>    domains are usually overwritten.
> 3.  Host implementations usually do not keep separate network
>    configuration (such as DNS server addresses) per provisioning
>    domain.
> 

But isn't the problem even more fundamental? There is really no concept of a provisioning domain as far as the host is concerned. It just gets information from multiple interfaces, routers, or DHCP servers, and has no idea what the relationship of the information might be. For instance, you could get default router and DNS server 10.0.0.1 from two interfaces, i.e., exactly the same information on both sides but it could still be two different domains and two different devices on the other end.

>        4.  Referrals must provide consistent information depending on
>            which provisioning domain is concerned.
> 

I'm not sure this belongs under configuration problems. I think referrals are a free-standing problem.

>        3.  Host implementations usually do not keep path
>            characteristics, user or provider preferences in the routing
>            table.
> 

Why would they?


>    2.  DNS resolution
>        1.  DNS server addresses are usually node-scoped.
>        2.  DNS answers are usually not kept with the interface from
>            which the answer comes from.
I feel that Section 5 is not doing a good enough job in nailing down what the real problem is. This is apparent in all the describes problems, but I'll illustrate the issue with the DNS text above. You make two statements, both of which are facts. But you do not draw the final conclusion. Why do these facts lead to some breakage?

>    3.  Host implementations usually do not implement the strong host
>        model [RFC1122] where the source address is in the routing
>        table.
>    4.  Applications usually do not use advanced APIs to specify the
>        source IP address or to set preferences on the address
>        selection policies.

Are you suggesting that mere switching to a strong host model would remove the problems?

Also, item 4 is more about moving the problem around than really solving it. IP layer doesn't employ policies, because it doesn't have the information. Applications wouldn't necessarily have the information either.

> 7. Security Considerations
>
>    The problems discussed in this document have security implications,
>    such as when the packets sent on the wrong interface might be leaking
>    some confidential information.  Moreover, the undetermined behavior
>    of IP stacks in the multihomed context bring additional threats where
>    an interface on a multihomed host might be used to conduct attacks
>    targeted to the networks connected by the other interfaces.

I would also add that attempts to provide more information to the host so that it could make a more intelligent decision would bring additional security concerns about protecting this additional information in some manner.

Editorial:

ID nits results, please look if these need action:

>  -- The document has a disclaimer for pre-RFC5378 work, but was first
>      submitted on or after 10 November 2008.  Does it really need the
>      disclaimer?
>
>  == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245
> 

> These mechanisms are not standardized and do not necessarily behave the same way across different OS, and/or platorms, in the presence of the MIF problems.

Typo: platorms

> of its access networks, through various mechanims such as DHCPv4

Typo: mechanims

> For instance, an application may implement the connection management function (as decribed in preceding section).

Typo: decribed

> S2 responds with an error for an non-existant domain (NXDOMAIN).

Typo: existant => existent

> has better characterictics, such as better round-trip time, least

Typo: characterictics

> provisioning domain (e.g. according to avalaible QoS).  Each

Typo: avalaible

> Or, when dealing with different domain selection policies, a connection manager may give precedence to user policy while another could favour mobile operator policy.

Typo: favour => favor

> 0ne administrative domain can contain multiple provisioning domains.

Typo:  0ne => One

> A MIF host is defined as:

The acronym MIF is not expanded anywhere in the document. Note that once the working group has completed, the RFCs need to stand out on their own and still be understandable.

> Some application protocols do referrals (i.e. provides reachability
>    information to itself or to a third-part)
Typo: third-part => third party

> These situations are also described in
> [I-D.savolainen-mif-dns-server-selection], [I-D.yang-mif-req] and
> [RFC4477].
> For example, as discussed
> in [I-D.savolainen-mif-dns-server-selection],
> [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a
> service provider might want to influence the routing table of the
> host connecting to its network.
> 

These sorts of notes would be better off in the contributor/acknowledgments section than in the middle of the text. Remember that the RFC has to be readable years from now, and by the all knowledge of other I-Ds may have disappeared.

> This section tries to list the underlying problems corresponding to
> the issues discussed in the previous section.

This section lists the ... (you should have confidence that you have described the problems correctly!)

>        2.  Host implementations usually do not implement the [RFC1122]
>            models where the Type-of-Service are in the routing table.
> 
Something wrong with the sentence. Type-of-Service field is considered in the routing table, maybe...

Shepherd Write-Up for draft-ietf-mif-problem-statement:

# (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, # does he or she believe this version is ready for forwarding to the IESG for # publication?

Document Shepherd is Hui Deng. I have personally reviewed the document and I believe the document is ready for publication.


# (1.b) Has the document had adequate review both from key WG members and from # key non-WG members? Does the Document Shepherd have any concerns about the # depth or breadth of the reviews that have been performed?

The document has had extensive reviews within the WG. I do not have any concerns about the depth or breadth of reviews received.


# (1.c) Does the Document Shepherd have concerns that the document needs more # review from a particular or broader perspective, e.g., security, operational # complexity, someone familiar with AAA, internationalization or XML?

I have no concerns about the reviews for this document.


# (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an # IPR disclosure related to this document been filed? If so, please include a # reference to the disclosure and summarize the WG discussion and conclusion # on this issue.

I have no concerns on the document. There have been no IPR disclosures filed on this document.


# (1.e) 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?

There is a strong consensus behind the document.


# (1.f) 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 entered into the ID Tracker.)

Nobody has threatened to appeal and the document is a product of the WG as a whole.


# (1.g) Has the Document Shepherd personally verified that the document # satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and # http://tools.ietf.org/tools/idnits/). Boilerplate checks are not # enough; this check needs to be thorough. Has the document met all formal # review criteria it needs to, such as the MIB Doctor, media type and URI # type reviews?

No ID nit errors are present on the document and the document meets the review criteria.
The idnits tool returns several warnings, but they mainly seem to be disclaimer and Outdated reference issues.

# (1.h) Has the document split its references into normative and informative?
# 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 strategy for their completion? Are there # normative references that are downward references, as described in # [RFC3967]? If so, list these downward references to support the Area # Director in the Last Call procedure for them [RFC3967].

The document has only informative references.

# (1.i) Has the Document Shepherd verified that the document IANA # consideration section exists and is consistent with the body of the # document? If the document specifies protocol extensions, are reservations # requested in appropriate IANA registries? Are the IANA registries clearly # identified? If the document creates a new registry, does it define the # proposed initial contents of the registry and an allocation procedure for # future registrations? Does it suggest a reasonable name for the new # registry? See [RFC2434]. If the document describes an Expert Review # process has Shepherd conferred with the Responsible Area Director so that # the IESG can appoint the needed Expert during the IESG Evaluation?

There are no actions for IANA in this document. However, an IANA considerations section stating that does exist.


# (1.j) Has the Document Shepherd verified that sections of the document that # are written in a formal language, such as XML code, BNF rules, MIB # definitions, etc., validate correctly in an automated checker?

No formal language segments exist.


# (1.k) 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
A multihomed host receives node configuration information from each
of its provisioning domains. Some configuration objects are global to
the node, some are local to the interface. Various issues arise when
multiple conflicting node-scoped configuration objects are received
on multiple interfaces. Similar situations also happen with single
interface host connected to multiple networks. This document
describes these issues.

Working Group Summary
There is a consensus in the MIF WG for publication as an informational RFC.

Document Quality
The document has gone through various reviews and a successful WGLC.

Personnel
Responsible AD is Jari Arkko and the document shepherd is Hui Deng.