Multiple Provisioning Domain Architecture
draft-ietf-mif-mpvd-arch-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-06-01
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-05-28
|
11 | Terry Manderson | Changed consensus to Yes from Unknown |
2015-05-15
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-05-11
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-03-24
|
11 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-03-24
|
11 | (System) | RFC Editor state changed to EDIT |
2015-03-24
|
11 | (System) | Announcement was received by RFC Editor |
2015-03-22
|
11 | (System) | IANA Action state changed to No IC from In Progress |
2015-03-22
|
11 | (System) | IANA Action state changed to In Progress |
2015-03-21
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-03-21
|
11 | Amy Vezza | IESG has approved the document |
2015-03-21
|
11 | Amy Vezza | Closed "Approve" ballot |
2015-03-21
|
11 | Amy Vezza | Ballot approval text was generated |
2015-03-21
|
11 | Ted Lemon | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-03-18
|
11 | Cindy Morgan | New revision available |
2015-03-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sean Turner. |
2015-03-01
|
10 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-02-19
|
10 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-02-19
|
10 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-19
|
10 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-19
|
10 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. I'm fine with it, but have one minor text suggestion resulting from considering the SecDir review. … [Ballot comment] Thanks for your work on this draft. I'm fine with it, but have one minor text suggestion resulting from considering the SecDir review. http://www.ietf.org/mail-archive/web/secdir/current/msg05457.html In 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly - and is explicitly stated elsewhere). From: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to. Such creation / augmentation of PvD(s) could be static or dynamic. To: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach via the same PvD. Such creation / augmentation of PvD(s) could be static or dynamic. |
2015-02-19
|
10 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-19
|
10 | Adrian Farrel | [Ballot comment] I have No Objection to the publication of this document. Here are some comments that you can take or leave in discussion with … [Ballot comment] I have No Objection to the publication of this document. Here are some comments that you can take or leave in discussion with your AD. Some of these Comments and nits come from a "training review" by Alvaro. --- I think you correctly avoid the use of 2119 language. You can delete the boilerplate and reference. --- I think you are talking about dual homed devices rather than dual homed networks. More precisely, the "node" that is dual homed is not a router but is a host. Possibly, you are extending to a dual homed home gateway. But I think (I hope) you are not intnding to cover dual homed ASBRs or ABRs. And you are not (I hope) covering dual-homed CPEs such as might provide access to a substantial enterprise network. I think that this would benefit from more explanation of scope in the document. In practice, you are discussing making connectivity choices rather than routing choices. If I have this wrong, please tell me and I can worry about whether this should have been a Discuss :-) [BTW Section 4 is great, but it addresses my specific concerns by example rather than statement.] --- The document uses "policy" a bit like a unicorn. Of course, there is a fine tradition of saying "the node will apply locally configured policy" but you have an opportunity to be much more specific and so far more helpful for protocol developers and for implementers. Policies are easy to write in pseduorcode, and I think you know the core set of policies you expect to see supported. So you could supply some guidance. --- I also think there is a problem with how policy is expected to be configured. The "nodes" you are talking to are (I think) end-system hosts rather than routers (see my prvious) and many of these will be relatively dumb devices and/or have relatively dumb users. These users will not be capable of making more than very basic policy decisions and their choics will need to be presented in different terms to the choices that the device itself makes. This would benefit from discussion because the policy model will need more work. --- Some references to other parts of the document are missing. 2.1 discusses about the possibility of using DHCP to carry information about the PvD, but there's no reference to the later section that talks about the same topic. 2.3 talks a little about authentication, but no reference to the trust section later. --- Section 2.1 Link-specific and / or vendor-proprietary mechanisms for the discovery of PvD information (differing from IETF-defined mechanisms) can be used by nodes either separate from, or in conjunction with, IETF-defined mechanisms; providing they allow the discovery of the . necessary elements of the PvD(s). In all cases, nodes must by default ensure that the lifetime of all dynamically discovered PvD configuration is appropriately limited by relevant events. For example, if an interface media state change is indicated, previously discovered information relevant to that interface may no longer be valid and so need to be confirmed or re- Discovered. The first paragraph seems to be superfluous to me (of course I can use proprietary mechanisms!), but then the second has (what should be) a normative directive: "must ensure appropriate lifetime". But, I tend to see "appropriate" and "relevant" as red flags! Why are you not able to give firmer directives? --- Section 2.4 PvD ID is a value that is, or has a high probability of being globally unique. If it's capable of not being unique, you have to handle conflict. If you have to handle conflict, it becomes less important that the probability of being unique is high. Maybe... If two PvDs have the same ID, this conflict must be detected and resolved. Using a mechanism that selects values that are more likely to be unique has the benefit of more rapid convergence and no need to execute the conflict resolution mechanism. And please be careful with "globally unique". Is "global" really that or is it constrained? --- Section 3.3 has references to what seems to be possible solutions or just other work. I think that just saying that "any new mechanisms should consider co-existence with deployed mechanisms" is enough. --- Section 5.2.3 introduces "PvD-aware applications". This is not clearly defined. Maybe this is just another example of a policy that is not defined in the document. |
2015-02-19
|
10 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-02-19
|
10 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from No Record |
2015-02-19
|
10 | Jari Arkko | [Ballot comment] A number of comments were submitted by Francis Dupont in his Gen-ART review. Hopefully the authors will be able to see if those … [Ballot comment] A number of comments were submitted by Francis Dupont in his Gen-ART review. Hopefully the authors will be able to see if those comments result in some changes to the text. |
2015-02-19
|
10 | Jari Arkko | Ballot comment text updated for Jari Arkko |
2015-02-18
|
10 | Spencer Dawkins | [Ballot comment] In this text: 5.2.3.1.2. Connectionless APIs For connectionless APIs, the host should provide an API that PvD- aware applications can use … [Ballot comment] In this text: 5.2.3.1.2. Connectionless APIs For connectionless APIs, the host should provide an API that PvD- aware applications can use to query the PvD associated with the packet. For outgoing traffic on this transport API object, the OS should use the selected outgoing PvDs, determined as described above. does "above" mean "in section 5.2.2"? Whatever it means, perhaps a cross reference would be helpful. |
2015-02-18
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-02-18
|
10 | Barry Leiba | [Ballot comment] -- Section 1.1 -- As far as I can see, there are no 2119 key words in this document (and I'm glad about … [Ballot comment] -- Section 1.1 -- As far as I can see, there are no 2119 key words in this document (and I'm glad about that). You should remove this section and the reference to RFC 2119. |
2015-02-18
|
10 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-02-17
|
10 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-16
|
10 | Francis Dupont | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Francis Dupont. |
2015-02-12
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2015-02-12
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2015-02-10
|
10 | Ted Lemon | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-02-10
|
10 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-02-10
|
10 | Ted Lemon | Ballot has been issued |
2015-02-10
|
10 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2015-02-10
|
10 | Ted Lemon | Created "Approve" ballot |
2015-02-10
|
10 | Ted Lemon | Ballot writeup was changed |
2015-02-09
|
10 | Dmitry Anipko | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-09
|
10 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-10.txt |
2015-02-06
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-02-01
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-02-01
|
09 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mif-mpvd-arch-09, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mif-mpvd-arch-09, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-01-31
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2015-01-31
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2015-01-29
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2015-01-29
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2015-01-29
|
09 | Ted Lemon | Placed on agenda for telechat - 2015-02-19 |
2015-01-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-01-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2015-01-23
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-01-23
|
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Multiple Provisioning Domain Architecture) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC The IESG has received a request from the Multiple Interfaces WG (mif) to consider the following document: - 'Multiple Provisioning Domain Architecture' as 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 2015-02-06. 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. Abstract This document is a product of the work of the MIF Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD) which is a a consistent set of network configuration information. PvD aware nodes learn PvD specific information from the networks they are attached to and / or other sources. PvDs are used to enable separation and configuration consistency in presence of multiple concurrent connections. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-01-23
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-01-23
|
09 | Ted Lemon | Last call was requested |
2015-01-23
|
09 | Ted Lemon | Last call announcement was generated |
2015-01-23
|
09 | Ted Lemon | Ballot approval text was generated |
2015-01-23
|
09 | Ted Lemon | Ballot writeup was generated |
2015-01-23
|
09 | Ted Lemon | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-01-22
|
09 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-09.txt |
2015-01-10
|
08 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-08.txt |
2014-12-17
|
07 | Ted Lemon | IESG state changed to AD Evaluation::AD Followup from Publication Requested |
2014-11-03
|
07 | Ted Lemon | IESG process started in state Publication Requested |
2014-11-03
|
07 | (System) | Earlier history may be found in the Comment Log for /doc/draft-anipko-mif-mpvd-arch/ |
2014-11-03
|
07 | Ted Lemon | Working group state set to Submitted to IESG for Publication |
2014-11-03
|
07 | Ted Lemon | Notification list changed to denghui02@hotmail.com, mif@ietf.org, mif-chairs@tools.ietf.org, draft-ietf-mif-mpvd-arch.all@tools.ietf.org |
2014-11-03
|
06 | Ted Lemon | Shepherding AD changed to Ted Lemon |
2014-10-01
|
07 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-07.txt |
2014-09-17
|
06 | Hui Deng | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? ==>Informational, because it doesn't specify any protocol spec and request IANA number assignment. and It is indicated in the page header. (2) 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 ==> This document outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD) which is a a consistent set of network configuration information. PvD aware nodes learn PvD specific information from the networks they are attached to and / or other sources. PvDs are used to enable separation and configuration consistency in presence of multiple concurrent connections. Working Group Summary ==> The workng group has quite concensus to move forward this document Document Quality ==> there is annunced implementationsof the dcument since it is a document about architecture. There several OS vendors indicate that they have implement the specification. There are couple of good review inputs done by the potential users. Personnel ==> Hui Deng is the Document Shepherd Ted Lemmon is the Responsible Area Director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. ==> This document was the output of the design team, it is well writen and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? ==> No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. ==> No (6) Describe any specific concerns or issues that the Document Shepherd has 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. ==>No Concerns and Issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. => Yes, both editor and deisgn team. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. ==>No. (9) 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? ==> quite concensus (10) 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 publicly available.) ==> No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ==> Done, editor will change (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. ==> No (13) Have all references within this document been identified as either normative or informative? ==> Yes, they have. (14) 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 plan for their completion? ==> No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. ==> No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. ==> No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). ==> There is no IANA requrement. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. ==> No (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. ==> No formal language exists. |
2014-09-17
|
06 | Hui Deng | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-09-17
|
06 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-06.txt |
2014-09-17
|
05 | Hui Deng | Changed document writeup |
2014-09-17
|
05 | Hui Deng | Intended Status changed to Informational from None |
2014-09-17
|
05 | Hui Deng | Document shepherd changed to Hui Deng |
2014-09-15
|
05 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-05.txt |
2014-09-12
|
04 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-04.txt |
2014-08-06
|
03 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-03.txt |
2014-07-03
|
02 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-02.txt |
2014-05-03
|
01 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-01.txt |
2014-03-03
|
00 | Hui Deng | This document now replaces draft-anipko-mif-mpvd-arch instead of None |
2014-02-03
|
00 | Dmitry Anipko | New version available: draft-ietf-mif-mpvd-arch-00.txt |