Current Practices for Multiple-Interface Hosts
draft-ietf-mif-current-practices-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2011-09-01
|
12 | (System) | IANA Action state changed to No IC from In Progress |
2011-09-01
|
12 | (System) | IANA Action state changed to In Progress |
2011-09-01
|
12 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-08-30
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-08-30
|
12 | Amy Vezza | IESG has approved the document |
2011-08-30
|
12 | Amy Vezza | Closed "Approve" ballot |
2011-08-30
|
12 | Amy Vezza | Approval announcement text regenerated |
2011-08-30
|
12 | Amy Vezza | Ballot writeup text changed |
2011-08-30
|
12 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-08-09
|
12 | Ralph Droms | [Ballot comment] I've cleared my DISCUSS based on the most recent revisions and e-mail discussions. |
2011-08-09
|
12 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2011-07-28
|
12 | Adrian Farrel | [Ballot comment] Thank you for addressing my Discuss and especially the new text in Section 3 |
2011-07-28
|
12 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2011-07-28
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-07-28
|
12 | (System) | New version available: draft-ietf-mif-current-practices-12.txt |
2011-05-11
|
12 | David Harrington | Request for Last Call review by TSVDIR Completed. Reviewer: Haibin Song. |
2011-04-30
|
12 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Donald Eastlake. |
2011-04-28
|
12 | Cindy Morgan | Removed from agenda for telechat |
2011-04-28
|
12 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-04-28
|
12 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
12 | Pete Resnick | [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, … [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. |
2011-04-27
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
12 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
12 | Dan Romascanu | [Ballot comment] I support Adrian's DISCUSS and Ralph's COMMENT. |
2011-04-27
|
12 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
12 | Pete Resnick | [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, … [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? |
2011-04-27
|
12 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-27
|
11 | (System) | New version available: draft-ietf-mif-current-practices-11.txt |
2011-04-26
|
12 | Ralph Droms | [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 … [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? |
2011-04-26
|
12 | Ralph Droms | [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 … [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? |
2011-04-26
|
12 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-26
|
12 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-26
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-25
|
12 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-25
|
12 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-25
|
12 | Stewart Bryant | [Ballot comment] I agree with Adrian's Discuss. |
2011-04-25
|
12 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-24
|
12 | Adrian Farrel | [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 … [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. |
2011-04-24
|
12 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-24
|
10 | (System) | New version available: draft-ietf-mif-current-practices-10.txt |
2011-04-22
|
12 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2011-04-22
|
12 | Jari Arkko | Ballot has been issued |
2011-04-22
|
12 | Jari Arkko | Created "Approve" ballot |
2011-04-15
|
12 | Jari Arkko | Placed on agenda for telechat - 2011-04-28 |
2011-04-15
|
12 | Jari Arkko | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-04-12
|
12 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-04-11
|
12 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Haibin Song |
2011-04-11
|
12 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Haibin Song |
2011-04-11
|
12 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-06
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2011-04-06
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2011-03-28
|
12 | Amy Vezza | Last call sent |
2011-03-28
|
12 | Amy Vezza | 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: … 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/ |
2011-03-28
|
12 | Jari Arkko | Last Call was requested |
2011-03-28
|
12 | (System) | Ballot writeup text was added |
2011-03-28
|
12 | (System) | Last call text was added |
2011-03-28
|
12 | (System) | Ballot approval text was added |
2011-03-28
|
12 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2011-03-28
|
12 | Jari Arkko | Last Call text changed |
2011-03-28
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-03-28
|
09 | (System) | New version available: draft-ietf-mif-current-practices-09.txt |
2011-03-28
|
12 | Jari Arkko | 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 … 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. |
2011-02-28
|
08 | (System) | New version available: draft-ietf-mif-current-practices-08.txt |
2011-02-14
|
07 | (System) | New version available: draft-ietf-mif-current-practices-07.txt |
2011-02-01
|
06 | (System) | New version available: draft-ietf-mif-current-practices-06.txt |
2010-10-25
|
05 | (System) | New version available: draft-ietf-mif-current-practices-05.txt |
2010-10-21
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-10-21
|
04 | (System) | New version available: draft-ietf-mif-current-practices-04.txt |
2010-10-01
|
12 | Jari Arkko | 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 … 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 |
2010-10-01
|
12 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2010-10-01
|
12 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2010-09-17
|
12 | Cindy Morgan | # (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, … # (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. |
2010-09-17
|
12 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-09-17
|
12 | Cindy Morgan | [Note]: 'Hui Deng (denghui02@gmail.com) is the document shepherd.' added by Cindy Morgan |
2010-08-11
|
03 | (System) | New version available: draft-ietf-mif-current-practices-03.txt |
2010-06-28
|
02 | (System) | New version available: draft-ietf-mif-current-practices-02.txt |
2010-06-10
|
01 | (System) | New version available: draft-ietf-mif-current-practices-01.txt |
2010-04-22
|
12 | (System) | Document has expired |
2009-10-19
|
00 | (System) | New version available: draft-ietf-mif-current-practices-00.txt |