Skip to main content

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

Discuss


Yes

(Jari Arkko)

No Objection

(Alexey Melnikov)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)

Note: This ballot was opened for revision 15 and is now closed.

Lars Eggert Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-08-23) Unknown
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.
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2011-04-21) Unknown
Thank you for the series of revisions to this I-D which I believe go far enough to allow me to clear my Discuss.
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2010-08-25) Unknown
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.
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2010-08-25) Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection (2010-08-24) Unknown
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"?
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2010-08-26) Unknown
  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.)
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown