Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)
draft-ietf-mpls-seamless-mcast-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-05-05
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-04-27
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-04-15
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2015-04-09
|
17 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-03-25
|
17 | Amy Vezza | Shepherding AD changed to Deborah Brungard |
2015-03-23
|
17 | Loa Andersson | Notification list changed to mpls@ietf.org, draft-ietf-mpls-seamless-mcast.shepherd@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-seamless-mcast.ad@ietf.org, draft-ietf-mpls-seamless-mcast@ietf.org, loa@pi.nu, erosen@juniper.net from mpls-chairs@ietf.org, draft-ietf-mpls-seamless-mcast@ietf.org, erosen@juniper.net |
2015-03-04
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-04
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-03-01
|
17 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2015-02-27
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-02-23
|
17 | (System) | IANA Action state changed to In Progress |
2015-02-23
|
17 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-02-23
|
17 | (System) | RFC Editor state changed to EDIT |
2015-02-23
|
17 | (System) | Announcement was received by RFC Editor |
2015-02-23
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-02-23
|
17 | Amy Vezza | IESG has approved the document |
2015-02-23
|
17 | Amy Vezza | Closed "Approve" ballot |
2015-02-23
|
17 | Amy Vezza | Ballot approval text was generated |
2015-02-23
|
17 | Adrian Farrel | Ballot writeup was changed |
2015-02-23
|
17 | Adrian Farrel | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-02-20
|
17 | Eric Rosen | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-02-20
|
17 | Eric Rosen | New version available: draft-ietf-mpls-seamless-mcast-17.txt |
2015-02-19
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-02-19
|
16 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-18
|
16 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-18
|
16 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-02-18
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-02-18
|
16 | Stephen Farrell | [Ballot comment] Apologies, I didn't really have time to read and understand this, but I got triggered by the mention of "thousands of PEs" in … [Ballot comment] Apologies, I didn't really have time to read and understand this, but I got triggered by the mention of "thousands of PEs" in the intro and wonder if we think the existing security mechanisms referred to in the security considerations would scale appropriately for such cases. Am I worrying over nothing or is there maybe a bit more work (or text) needed to secure such a setup? |
2015-02-18
|
16 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-02-18
|
16 | Alia Atlas | [Ballot comment] For the Global Administrator field, it would be really nice to specify that the IP address needs to be routeable and within what … [Ballot comment] For the Global Administrator field, it would be really nice to specify that the IP address needs to be routeable and within what scope (area, AS, inter-AS). I think the answer is just AS. This comes up because a recommendation is to use a router's loopback address - and frequently those are deliberately not routeable outside the AS. |
2015-02-18
|
16 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-18
|
16 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to No Record from Discuss |
2015-02-18
|
16 | Richard Barnes | [Ballot discuss] This time I'm going to be the one to file a DISCUSS over reference categorization. Why are these references Informative? It seems like … [Ballot discuss] This time I'm going to be the one to file a DISCUSS over reference categorization. Why are these references Informative? It seems like they're pretty much all critical for implementing the requirements stated in this document. |
2015-02-18
|
16 | Richard Barnes | |
2015-02-18
|
16 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2015-02-18
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-02-17
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-17
|
16 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-17
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-13
|
16 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-02-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2015-02-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2015-02-05
|
16 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-02-05
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. |
2015-02-05
|
16 | Adrian Farrel | Ballot has been issued |
2015-02-05
|
16 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2015-02-05
|
16 | Adrian Farrel | Created "Approve" ballot |
2015-02-05
|
16 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2015-02-04
|
16 | Vijay Gurbani | Request for Last Call review by GENART No Response. Reviewer: Vijay Gurbani. |
2015-02-04
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-04
|
16 | Eric Rosen | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-02-04
|
16 | Eric Rosen | New version available: draft-ietf-mpls-seamless-mcast-16.txt |
2015-02-03
|
15 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Stig Venaas. |
2015-02-02
|
15 | Adrian Farrel | Changed consensus to Yes from Unknown |
2015-02-02
|
15 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2015-02-02
|
15 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-02-01
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2015-02-01
|
15 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-seamless-mcast-15. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-seamless-mcast-15. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, in the Transitive IPv4-Address-Specific Extended Community Sub-Types subregistry of the the Border Gateway Protocol (BGP) Extended Communities registry, IANA has assigned the value 0x12 in the Transitive IPv4-Address-Specific Extended Community Sub-Types registry for Inter-area P2MP Segmented Next-Hop. IANA will change the reference from the Internet Draft to [ RFC-to-be ]. Second, in the Transitive IPv6-Address-Specific Extended Community Types subregistry of the Border Gateway Protocol (BGP) Extended Communities registry located at: http://www.iana.org/assignments/bgp-extended-communities/ IANA has assigned the value 0x0012 for Inter-area P2MP Segmented Next-Hop. IANA will change the reference from the Internet Draft to [ RFC-to-be ]. Third, in the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types subregistry of the Border Gateway Protocol (BGP) Parameters registry located at: http://www.iana.org/assignments/bgp-parameters/ a new tunnel type will be registered as follows: Value: [ TBD-at-registration ] Meaning: Transport Tunnel Reference: [ RFC-to-be ] The value 0x08 is requested. IANA understands that these three actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2015-01-29
|
15 | Adrian Farrel | Telechat date has been changed to 2015-02-19 from 2015-02-05 |
2015-01-28
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2015-01-28
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2015-01-26
|
15 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2015-01-26
|
15 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2015-01-26
|
15 | Jonathan Hardwick | Assignment of request for Early review by RTGDIR to Bruno Decraene was rejected |
2015-01-26
|
15 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Bruno Decraene |
2015-01-26
|
15 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Bruno Decraene |
2015-01-22
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2015-01-22
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2015-01-22
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2015-01-22
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2015-01-20
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Juergen Quittek |
2015-01-20
|
15 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Juergen Quittek |
2015-01-19
|
15 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-01-19
|
15 | 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: (Inter-Area P2MP Segmented LSPs) 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: (Inter-Area P2MP Segmented LSPs) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Inter-Area P2MP Segmented LSPs' as Proposed Standard 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-02. 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 describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2047/ |
2015-01-19
|
15 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-01-19
|
15 | Amy Vezza | Last call announcement was changed |
2015-01-19
|
15 | Adrian Farrel | Placed on agenda for telechat - 2015-02-05 |
2015-01-19
|
15 | Adrian Farrel | Last call was requested |
2015-01-19
|
15 | Adrian Farrel | Ballot approval text was generated |
2015-01-19
|
15 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2015-01-19
|
15 | Adrian Farrel | Ballot writeup was changed |
2015-01-19
|
15 | Adrian Farrel | Ballot writeup was changed |
2015-01-19
|
15 | Adrian Farrel | Ballot writeup was generated |
2015-01-19
|
15 | Adrian Farrel | AD review ===== Hello authors, I have conducted my usual AD review of this document to attempt to catch issues that would otherwise show in … AD review ===== Hello authors, I have conducted my usual AD review of this document to attempt to catch issues that would otherwise show in IETF last call or IESG evaluation. There are number of small nits listed below. None of these needs delay the document and you should feel free to debate the points with me rather than blindly accepting my view. I will start the IETF last call and enter these as last call comments. You can then address them together with any other review comments you receive during last call. Thanks for the work. Adrian === idnits reveals that the copyright year needs to be 2015. Please update that if you revise the document. idnits also points out that you probably don't need the boilerplate for pre-RFC5378 work. unless you are sure you need it, please take it out. --- I think that the RFC Editor will need your help expanding some of the abbreviations that are not listed as "well known" in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt You might kick this off by doing a scrub yourselves. --- Section 3 line 1 s/suppose/assumed/ --- 5.1.2 and 5.2.2 titles s/re-advertise/re-advertised/ --- 5.1.3 has To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document requires ABRs NOT to modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. "NOT" is not a 2119 term in its own right. Suggest you rephrase as To avoid requiring ABRs to participate in the propagation of C- multicast routes, this document specifies that ABRs MUST NOT modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes. --- In 6.1.2 If the application is global table multicast, then the unicast routes to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended Community [RFC6514] where the IP address in the Global Administrator field is set to the IP address of the PE or ASBR advertising the unicast route. I wondered about this "SHOULD". Trying to decide why we might decide to vary that and what the consequences would be. Similarly one para later... Further, if the application is global table multicast, then the BGP unicast routes that advertise the routes to the IP addresses of PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended Community. --- 7.2.2.1 This section applies only if it is desirable to send a particular (S, G) or (*, G) global table multicast flow only to those egress PEs that have receivers for that multicast flow. Is this s/desirable/desired/ ? If not then some guidance as to how to judge when it is desirable. If so, then perhaps you could be a little less passive-voice: who desires it? --- 7.2.2.2 It may be desirable for an ingress PE to carry multiple multicast flows associated with the global table multicast over the same inter- area P2MP service LSP. Can you give guidance as to why it might be desirable? Or possible (as above) s/desirable for/desired that/ also adding some explanation about who has the desire (and possible why). --- 7.2.3 To allow the egress PE to determine the sender upstream node, the intra-area P2MP LSP must be signaled with no PHP, when the mapping between the inter-area P2MP service LSP for global table multicast service and the intra-area P2MP LSP is many-to-one. The lower case "must" jumped out. Probably upper case? --- Section 14 Is the term "transport LSP" introduced by this document? If so, a little more definition would be nice (just a few words to make it clear that you are defining the term). If not, can you supply a reference. --- After 38 pages of spec you have just five lines of security considerations. You don't even mention BGP security directly. I confess that I don't see anything obvious that is missing, but are there no specific risks associated with this approach? No amplification through mcast? |
2015-01-18
|
15 | Adrian Farrel | Last call announcement was changed |
2015-01-18
|
15 | Adrian Farrel | Last call announcement was generated |
2015-01-09
|
15 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-15.txt |
2015-01-09
|
14 | Adrian Farrel | Notification list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-seamless-mcast@tools.ietf.org, erosen@juniper.net from mpls-chairs@tools.ietf.org, draft-ietf-mpls-seamless-mcast@tools.ietf.org |
2015-01-09
|
14 | Adrian Farrel | Note that despite the naming, there is no strong dependency between this document and draft-ietf-mpls-seamless-mpls |
2015-01-09
|
14 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-09-28
|
14 | Loa Andersson | The MPLS working group requests that Inter-Area P2MP Segmented LSPs … The MPLS working group requests that Inter-Area P2MP Segmented LSPs draft-ietf-mpls-seamless-mcast-14.txt is published as an RFC on the Standards Track. (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? We want to start this document up on the Standards Track as a Proposes Standard. The document header says Standards Track. Proposed Standard is the right type of RFC, since the document specifies protocol, procedures and information elements. (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 describes procedures for building inter-area P2MP segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE (RFC 4875) or mLDP (RFC 63 88). If ingress replication is used within an IGP area, then LDP or RSVP-TE LSPs may be used. BGP VPN Multicast, VPLS multicast, or global table multicast over MPLS are applications/services that may use such inter-LSPs. Working Group Summary The WG process has been straightforward, there is a general agreement in the working group that support for multicast service is needed and that there are synergies if we can use the the same method for multiple cases There have been no controversies around this draft and the support for this document is good. Document Quality We are currently aware of one implementation. An implementation poll has been sent to the working group and the Shepherd Write-up will be updated as soon as we have more information. There has been no other reviews than the MPLS-RT and WGLC, MIB Doctor, Media Type or other expert reviews are not necessary for this document. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel 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 has been part of the discussion around Seamless MPLS, the Shepherd has reviewed at least three times - when the (individual) document first appeared (this document were part of a larger discussion on "Seamless MPLS" and attracted quite an interest from the start - while preparing the preparing mpls-rt review and working group adoption poll - prior to and after working group last call. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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 such reviews needed. (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 such concerns. (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 - all authors has state on the MPLS wg mailing list that they are unaware of any other IPRs than what has been disclosed to the IETF. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosed against this document, it was brought to the working group attention at working group last call. The IPR disclosure did not generate any discussion during the wglc, the shepherd has interpreted this as that the conditions related to the IPR is acceptable for the working group. Note: This ID were going through the wg adoption poll in April 2011, prior to when we routinely started to do IPR polls prior to the wg adoption poll. The IPR was disclosed in April 2013. (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? The working group support this document. (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.) (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. No real nits, the date in the document is given as "June 30 2014" while the nits toll expects "June 30, 2014" this generates 3 miscellaneous warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews required. (13) Have all references within this document been identified as either normative or informative? Yes, the references are correctly split into normative and informative.into references. (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? All normative references are to existing RFCs, with one exception. One normative references is to draft-ietf-l3vpn-pmsi-registry, that draft is in AUTH48 and is like to become an RFC prior to the IESG review of this document. (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 downward refernces. (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. The status of no other document will be change when this document is publsihed. (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). The shepherd has reviewed the IANA section and code point allocations several times. The IANA section is clear and well written. However in the earlier version of the document the IANA section included addition of code points to a table specified in RFC 6514, but for which an IANA registry never was created. The Shepherd in the early reviews assumed that since the allocation were mentioned in the IANA section it was requesting an IANA action. Having understood the situation and after consulting with the responsible AD it was decided to hold this document and write the document that creates this registry. The new document (draft-ietf-l3vpn-pmsi-registry) is now in AUTH48 and this document correctly request a code point to be allocated form the new registry. (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 such registries. (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 such reviews needed. |
2014-09-28
|
14 | Loa Andersson | State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-seamless-mcast@tools.ietf.org |
2014-09-28
|
14 | Loa Andersson | Responsible AD changed to Adrian Farrel |
2014-09-28
|
14 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-09-28
|
14 | Loa Andersson | IESG state changed to Publication Requested |
2014-09-28
|
14 | Loa Andersson | IESG process started in state Publication Requested |
2014-09-28
|
14 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2014-09-27
|
14 | Loa Andersson | Changed document writeup |
2014-09-26
|
14 | Loa Andersson | Changed document writeup |
2014-09-25
|
14 | Loa Andersson | Changed document writeup |
2014-09-24
|
14 | Loa Andersson | Changed document writeup |
2014-09-24
|
14 | Loa Andersson | Changed document writeup |
2014-09-24
|
14 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2014-09-24
|
14 | Loa Andersson | Changed document writeup |
2014-07-02
|
14 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-14.txt |
2014-06-08
|
13 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-13.txt |
2014-06-06
|
12 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-12.txt |
2014-06-02
|
11 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-11.txt |
2014-06-02
|
10 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-10.txt |
2013-12-09
|
09 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-09.txt |
2013-11-11
|
08 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-08.txt |
2013-10-11
|
07 | Loa Andersson | Document shepherd changed to Loa Andersson |
2013-05-14
|
07 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-07.txt |
2013-04-01
|
(System) | Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-mpls-seamless-mcast-06 | |
2013-01-22
|
06 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-06.txt |
2012-08-01
|
05 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-05.txt |
2012-05-30
|
04 | Yakov Rekhter | New version available: draft-ietf-mpls-seamless-mcast-04.txt |
2011-12-07
|
03 | (System) | New version available: draft-ietf-mpls-seamless-mcast-03.txt |
2011-11-15
|
02 | (System) | New version available: draft-ietf-mpls-seamless-mcast-02.txt |
2011-08-18
|
01 | (System) | New version available: draft-ietf-mpls-seamless-mcast-01.txt |
2011-06-06
|
00 | (System) | New version available: draft-ietf-mpls-seamless-mcast-00.txt |