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