Current Practices for Multiple-Interface Hosts
draft-ietf-mif-current-practices-12

[Ballot comment]
In section 2, I was left a bit confused because I think you reversed the sense of the opening sentences of 2.1, 2.2, and 2.3. Are you describing the approach, or summarizing which OSs use which approach? I think you meant to do the former. For example, in 2.1, do desktop OSs ever use centralized connection management? If not, perhaps this would be a better opening for 2.1:

  A centralized connection manager does network interface selection
  based on application or user input. This approach to dealing with
  multiple interfaces is employed by many mobile handset operating
  systems.

Similarly for 2.2 and 2.3. I *think* each of these are simply describing the approach.

[Ballot comment]
- In section 2, I was left a bit confused because I think you reversed the sense of the opening sentences of 2.1, 2.2, and 2.3. Are you describing the approach, or summarizing which OSs use which approach? I think you meant to do the former. For example, in 2.1, do desktop OSs ever use centralized connection management? If not, perhaps this would be a better opening for 2.1:

  A centralized connection manager does network interface selection
  based on application or user input. This approach to dealing with
  multiple interfaces is employed by many mobile handset operating
  systems.

Similarly for 2.2 and 2.3. I *think* each of these are simply describing the approach.

- With regard to Android in particular: Can Android actually handle multiple interfaces at once? My own experience is that once one interface comes up, it tears down all other interfaces. Is that a configurable thing?

[Ballot comment]
I support Adrian's DISCUSS and would like to hear why the details
of the specific operating systems are included.

I'm also a little confused, as I was when reading the problem
statement draft, about the scope of the documents, based
on the WG charter.  Is the scope focused on dealing with
"configuration objects" from different "provisioning domains"
or is it more broadly issues related to multiple simultaneously
active interfaces?

Also, the problem statement document, referenced in this
document, talks about "provisioning domains" and "attachment
to a provisioning domain", while this document says nothing
about provisioning domains.  In my opinion, it would strengthen
the documents if this document provided some additional
motivation for the discussion of provisioning domains in the
problem statement document.

Include a citation for the MIF problem statement at the first
reference in section 1.

The Introduction include OS X in the list of operating systems for
which information has been collected, but I don't see any specific
information (or even any other references) to OS X.

Why are Linux and BSD-based operating systems together in
section 3.2.2, when many of the details are different?

[Ballot discuss]
In section 2, are the differentiations between the various mechanisms
in the subsections really differentiated between mobile handset and
desktop systems?  Is making that differentiation germane?  In
particular, does the configuration information for mobile handsets not
come from "DHCP, proprietary configurations systems or manual
configuration"?  Does Android implement a "connection manager"?

In section 2.3, why is RA/SLAAC not mentioned for desktop systems?

[Ballot discuss]
I found this document quite a good read, but I have three issues I would like to Discuss before balloting "no objection".

The first two issues are relatively easily addressed. The third one might result in the deletion of substantial portions of the text.

---

As with draft-ietf-mif-problem-statement, I would be happier if
discussion of "routing" was clarified to "first hop selectiong" as
what is going on here is not to be confused with general path
selection or the type of routing that a router does.

---

Does it actually matter for this document whether the different
interfaces on the host provide unequal levels of service or
connectivity?  The Abstract seems to think so, but many of the
decisions to be made eixst regardless of this point.

---

While it is, of course, useful to survey existing implementations,
and the use of public domain information cannot be complained about,
I find it unfortunate that this document presents a comparison of
the behaviors of different products rather than restricting itself
to the (very good) sections that provide a generic anlysis of the
mechanisms in use.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Current Practices for Multiple Interface Hosts) to Informational RFC


The IESG has received a request from the Multiple Interfaces WG (mif) to
consider the following document:
- 'Current Practices for Multiple Interface Hosts'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
I have re-reviewed this draft after changes per my earlier review. I think the draft is ready to move forward with one change: please add a reference to RFC 5113 and explain that it containsfurther discussion about the access network selection problem.

I don't have a strong opinion on whether we should add something to highlight Ted's scenario from today's meeting. I'll let the working group and the chairs decide that. I have set the status of the draft to Revised ID Needed, and we are ready to start IETF Last Call as soon as the above issue is fixed; if you don't add anything about the other scenario then a quick update this week would move the draft forward. Let me know when you have a new version that can be advanced.

I have reviewed this document. Overall, this is a good document, but some work still remains. My biggest issues were the following:

The document is quite focused on the access network selection problem, which has already been discussed extensively in RFC 5113. It is fine to  include discussion of the access network selection problem as well, because it is all part of the same problem space. But I would have expected the document discuss in more detail what the various implementations do at layer 3. For instance, do they use RFC 3484, are DNS settings per-node or per-interface, if an application is bound to an interface does it always use the DNS settings for exactly that interface or the per-node settings, what happens with overlapping address space, etc.

The document is somewhat imbalanced, there's very little (too little) information about some devices and operating systems whereas the Windows description is detailed and informative. I would suggest that some of the devices for which there is very little information are either removed from the document or some more information is inserted about them.

Detailed comments:

Section 3.1.3 s/in a MIF context/here/ (the MIF context is a fine term to use in WG discussion, but will look odd in a published RFC by the time the WG has concluded).

On Section 3.1.4 (BlackBerry) it was unclear to me what type of gateways the text refers to. Default router, web proxy, application proxy, something else? On the second paragraph of the same section it is unclear what "device" refers to. The entire device can use multiple networks simultaneously? Does that mean that one application can use multiple networks simultaneously, to the same destinations (like in mp-tcp) or to different destinations? Or just that multiple applications can use different networks simultaneously?`Please be more precise about what is actually happening, as opposed to claiming a general capability.

Section 3.1.7 says very little about the hard issues around MIF, such as whether overlapping address space is tolerated, whether there is a possibility of some policy being sent from the network, whether DNS info is per node or per interface, etc.

But also other sections under 3.1 seem thin. I realize that its hard to get information, but at least some of these devices are open source and run on top of standard kernels such as Linux, so it should be possible to find out a bit more.

> iPhone
> Iphone
Inconsistent capitalization.

>      Whatever is the handset, fallback on L3 attachment failure is not
>      supported for motionless terminals.  Actually, the connection
>      manager always selects the most powerful signal strength without
>      considering IP configuration results.  In other words, if the
>      terminal is unable to set up the IP connectivity on one wifi
>      access, the connection manager will not try to attach to an
>      alternative point of attachment (or SSID) as long as the signal
>      strength of the first radio link is the most powerful.

What is "motionless terminal"? All devices that you mention are mobile.

Besides, I'm fairly certain that the above does not apply to Android. The device that I have does seem to switch away from a strong-signal SSID to another SSID, if L3 attachment fails.

> in the scope of MIF.

... in the scope of this document.

Jari

# (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.
It has no MIF/Media type/URI type defined.

# (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 1 normative reference, that one is in the process of
IESG LC already, the strategy
would be that document the refernce first, then go through this one. there
are no downward 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
An increasing number of hosts are operating in multiple-interface
environments, where different network interfaces are providing
unequal levels of service or connectivity. This document summarizes
current practices in this area, and describes in detail how some
common operating systems cope with these challenges.

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.