IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks
draft-ietf-softwire-mesh-multicast-25
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-09-09
|
25 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-08-19
|
25 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2019-08-19
|
25 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Carlos Martínez was marked no-response |
2019-07-22
|
25 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-07-22
|
25 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-06-10
|
25 | (System) | RFC Editor state changed to EDIT |
2019-06-10
|
25 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-06-10
|
25 | (System) | Announcement was received by RFC Editor |
2019-06-10
|
25 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-06-10
|
25 | (System) | IANA Action state changed to In Progress |
2019-06-10
|
25 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2019-06-10
|
25 | Amy Vezza | IESG has approved the document |
2019-06-10
|
25 | Amy Vezza | Closed "Approve" ballot |
2019-06-10
|
25 | Amy Vezza | Ballot approval text was generated |
2019-06-10
|
25 | Amy Vezza | Ballot writeup was changed |
2019-06-10
|
25 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2019-06-10
|
25 | Éric Vyncke | Eric V requested IETF secretary to move forward and send it to RFC editor. Last revision includes Med Boucardair's cosmetic comments. |
2019-06-09
|
25 | Éric Vyncke | Notification list changed to ianfarrer@gmx.com from "Ian Farrer" <ianfarrer@gmx.com> |
2019-06-09
|
25 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-25.txt |
2019-06-09
|
25 | (System) | New version approved |
2019-06-09
|
25 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , Shu Yang , Yong Cui , Chris Metz , Mingwei Xu |
2019-06-09
|
25 | Shu Yang | Uploaded new revision |
2019-06-03
|
24 | Éric Vyncke | Check whether all comments were address + new comments by M. Boucanair |
2019-06-03
|
24 | Éric Vyncke | IESG state changed to Approved-announcement to be sent::AD Followup from Approved-announcement to be sent::Point Raised - writeup needed |
2019-06-03
|
24 | Éric Vyncke | Ballot approval text was generated |
2019-03-27
|
24 | Amy Vezza | Shepherding AD changed to Éric Vyncke |
2018-12-18
|
24 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-24.txt |
2018-12-18
|
24 | (System) | New version approved |
2018-12-18
|
24 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , Shu Yang , Yong Cui , Chris Metz , Mingwei Xu |
2018-12-18
|
24 | Shu Yang | Uploaded new revision |
2018-12-13
|
23 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-09-27
|
23 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-09-27
|
23 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-09-26
|
23 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-09-26
|
23 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-09-26
|
23 | Benjamin Kaduk | [Ballot comment] I'm balloting No Objection instead of Discuss, but I think this document has a few things that need to be resolved before publication. … [Ballot comment] I'm balloting No Objection instead of Discuss, but I think this document has a few things that need to be resolved before publication. In particular: I'm concerned that the informative references may actually need to be normative references, but not quite enough to cross my Discuss threshold. See my comments on Section 9 for details. There are several things that look like internal references but are not resolvable (see per-section comments). Section 1 I think you should provide a brief summary of what "(S,G) states" are in this document, as well as the reference. Section 3 o Address Family Border Router (AFBR) - A router interconnecting two or more networks using different IP address families. Besides, in the context of softwire mesh multicast, the AFBR runs E-IP and I-IP nit: maybe s/Besides/Additionally/? nit: using "upper reaches" and "lower reaches" is still basically the same metaphor as upstream/downstream. I guess "closer to the source" and "closer to a receiver" might be different, but offer no opinion on whether it would be better. Section 5.2/5.3 Please expand SSM and ASM on first usage. Section 5.4 To achieve this, every AFBR MUST announce the address of one of its E-IPv4 interfaces in the "v4" field alongside the corresponding uPreifx64. The announcement MUST be sent to the other AFBRs through MBGP [RFC4760]. Every uPrefix46 that an AFBR announces MUST be unique. "uPrefix46" is an IPv6 prefix, and the distribution mechanism is the same as the traditional mesh unicast scenario. I am not very familiar with this space, and just wanted to check that both "uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64" being a typo). When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be generated according to the format specified in Figure 3, with the "source address" field set to * (wildcard value). The translated There is no "source address" field in Figure 3. message will be forwarded to the corresponding upstream AFBR. Since every PIM router within a PIM domain MUST be able to map a particular multicast group address to the same RP (see Section 4.7 of [RFC7761]), when the upstream AFBR checks the "source address" field of the message, it finds the IPv4 address of the RP, and ascertains that this is originally a (*,G) message. This is then translated back to the (*,G) message and processed. I'm failing to find where the downstream AFBR is setting the source address to that of the RP; presumably this just means I'm confused about how this part works. Section 6.4 Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT of (S,G), and decided to perform an SPT switchover. According to Is it the AFBR that has joined the (E-IP) group and decided to switchover, or some system in the client network? Section 8 In Figure 5, the semantics of fields "PIM Ver", "Type", "Reserved", and "Checksum" can be referred in Section 4.9 of [RFC7761]. IPv4 Group Address (Encoded-Group format): The encoded-group format of the IPv4 group address described in Section 4.2. IPv4 Source Address (Encoded-Group format): The encoded-unicast format of the IPv4 source address described in Section 4.3. IPv6 Group Address (Encoded-Group format): The encoded-group format of the IPv6 group address described in Section 4.2. IPv6 Source Address (Encoded-Group format): The encoded-unicast format of the IPv6 source address described in Section 4.3. This document has no Section 4.2 or 4.3 (and those sections of RFC 7761 do not seem appropriate here, either). Section 9 "MUST [...] follow the requirements mentioned in [I-D.ietf-intarea-tunnels]" seems like it needs a normative reference. "MUST [...] allow the use of encapsulation mechanisms mentioned in [RFC4925]" would seem to do the same. Section 10 It may be worth calling out the "interface agent" as being an additional workload susceptible to DDoS. It is true that the trusted nature of the BGP peer is what is relevant for deciding to accept Well-Known prefix advertisements, but perhaps there is room to mention the potential use of cryptographic methods for authenticating the peer so as to have increased confidence that such trust is properly placed. |
2018-09-26
|
23 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-09-26
|
23 | Alissa Cooper | [Ballot comment] Building off of Mirja's comment and the Gen-ART review, I have a specific suggestion for Sec. 7.3: OLD The specific requirements for … [Ballot comment] Building off of Mirja's comment and the Gen-ART review, I have a specific suggestion for Sec. 7.3: OLD The specific requirements for fragmentation and tunnel configuration COULD be referred to in [I-D.ietf-intarea-tunnels], which is under revision currently. NEW Fragmentation and tunnel configuration considerations are provided in [RFC4459] and [I-D.ietf-intarea-tunnels]. |
2018-09-26
|
23 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-09-26
|
23 | Ben Campbell | [Ballot comment] §2: Please use the boilerplate from RFC 8174. §10: "... the security concerns SHOULD be considered more carefully...": That seems more a … [Ballot comment] §2: Please use the boilerplate from RFC 8174. §10: "... the security concerns SHOULD be considered more carefully...": That seems more a statement of fact than a normative requirement. I suggest changing the "SHOULD" to "should". |
2018-09-26
|
23 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-09-26
|
23 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-09-26
|
23 | Alexey Melnikov | [Ballot comment] A couple of nits: 1) "COULD" is not one of RFC 2119 keywords, so it shouldn't be uppercased in order to avoid causing … [Ballot comment] A couple of nits: 1) "COULD" is not one of RFC 2119 keywords, so it shouldn't be uppercased in order to avoid causing confusion for readers. 2) In Section 10 the document says: Compared with [RFC4925], the security concerns SHOULD be considered more carefully: ... This is not a requirement statement on implementations or operators, so use of SHOULD is not appropriate here. So please lowercase it to avoid RFC 2119 meaning. |
2018-09-26
|
23 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-09-26
|
23 | Alvaro Retana | [Ballot comment] (1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format". Even though source address mapping had just been discussed (§5.3), it wasn't clear … [Ballot comment] (1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format". Even though source address mapping had just been discussed (§5.3), it wasn't clear right away that you were talking about the same thing. Maybe it was the name used ("IPv4-Embedded IPv6 Virtual Source Address Format"), which doesn't show up anywhere else. Putting a note in §5.3 about the name would be nice. (2) §5.4: "...every AFBR MUST announce the address of one of its E-IPv4 interfaces in the "v4" field..." Please put a reference here to rfc6052 (so it's easy to remember where that field came from). (3) §6.4: "According to [RFC7761], it SHOULD propagate..." That SHOULD is out of place because it is not normative in this document. Either change it to 'should', or quote the text. (4) §6.4: Several SHOULDs are used in this section. In general, are there cases where it's ok to not follow the specification? For example, "When RP' receives this encapsulated message, it SHOULD decapsulate..." -- are there cases where the RP' wouldn't decapsulate. IOW, why not use MUST instead? (5) §6.4: "...so RP' SHOULD NOT simply process this message as specified in [RFC7761] on the incoming interface." That "SHOULD NOT" seems to just be a statement and not have normative value (the normative text comes in the next paragraph). s/SHOULD NOT/should not |
2018-09-26
|
23 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-09-26
|
23 | Alvaro Retana | This document now replaces draft-xu-softwire-mesh-multicast instead of None |
2018-09-25
|
23 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-09-21
|
23 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list. |
2018-09-20
|
23 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2018-09-20
|
23 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2018-09-20
|
23 | Mirja Kühlewind | [Ballot comment] On section 7.3: Thanks for discussing fragmentation and pointing to [I-D.ietf-intarea-tunnels]. As [I-D.ietf-intarea-tunnels] is still work in progress, I … [Ballot comment] On section 7.3: Thanks for discussing fragmentation and pointing to [I-D.ietf-intarea-tunnels]. As [I-D.ietf-intarea-tunnels] is still work in progress, I guess it could make sense to also add a reference to rfc4459 directly. Also I don't think COULD is a well-know key word... |
2018-09-20
|
23 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-09-15
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-09-15
|
23 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-23.txt |
2018-09-15
|
23 | (System) | New version approved |
2018-09-15
|
23 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Yong Cui , Chris Metz , Mingwei Xu , Shu Yang |
2018-09-15
|
23 | Shu Yang | Uploaded new revision |
2018-09-13
|
22 | Terry Manderson | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-09-10
|
22 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Nicolai Leymann. |
2018-09-10
|
22 | Amy Vezza | Placed on agenda for telechat - 2018-09-27 |
2018-09-09
|
22 | Terry Manderson | Ballot has been issued |
2018-09-09
|
22 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-09-09
|
22 | Terry Manderson | Created "Approve" ballot |
2018-09-09
|
22 | Terry Manderson | Ballot writeup was changed |
2018-09-06
|
22 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-09-04
|
22 | Joseph Touch | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Joseph Touch. Sent review to list. |
2018-08-30
|
22 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2018-08-30
|
22 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2018-08-28
|
22 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martinez |
2018-08-28
|
22 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martinez |
2018-08-27
|
22 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-08-27
|
22 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-softwire-mesh-multicast-22, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-softwire-mesh-multicast-22, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-08-26
|
22 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list. |
2018-08-23
|
22 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
2018-08-23
|
22 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to Nicolai Leymann |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to Nicolai Leymann |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to He Jia |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to He Jia |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2018-08-23
|
22 | Min Ye | Request for Last Call review by RTGDIR is assigned to Geoff Huston |
2018-08-23
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-08-23
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-08-23
|
22 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
2018-08-23
|
22 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
2018-08-23
|
22 | Alvaro Retana | Requested Last Call review by RTGDIR |
2018-08-23
|
22 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-08-23
|
22 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-09-06): From: The IESG To: IETF-Announce CC: softwire-chairs@ietf.org, Ian Farrer , ianfarrer@gmx.com, draft-ietf-softwire-mesh-multicast@ietf.org, … The following Last Call announcement was sent out (ends 2018-09-06): From: The IESG To: IETF-Announce CC: softwire-chairs@ietf.org, Ian Farrer , ianfarrer@gmx.com, draft-ietf-softwire-mesh-multicast@ietf.org, softwires@ietf.org, terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network' 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 2018-09-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 During the transition to IPv6, there will be scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family), connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks. This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on IPv4-over-IPv6 scenario, due to lack of real- world use cases for IPv6-over-IPv4 scenario. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-08-23
|
22 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-08-23
|
22 | Terry Manderson | Last call was requested |
2018-08-23
|
22 | Terry Manderson | Ballot approval text was generated |
2018-08-23
|
22 | Terry Manderson | Ballot writeup was generated |
2018-08-23
|
22 | Terry Manderson | IESG state changed to Last Call Requested from AD Evaluation |
2018-08-23
|
22 | Terry Manderson | Last call announcement was generated |
2018-07-31
|
22 | Terry Manderson | IESG state changed to AD Evaluation from Publication Requested |
2018-06-29
|
22 | Ian Farrer | Dear INT Area Directors and IESG-Secretary - Please advance in the process and publish the draft from the Softwires WG. Here is the proto writeup … Dear INT Area Directors and IESG-Secretary - Please advance in the process and publish the draft from the Softwires WG. Here is the proto writeup for the draft: draft-ietf-softwire-mesh-multicast-22 (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? Intended status: Standards Track (Indicated on title page) This document describes a mechanism for transporting IPv4 multicast traffic over meshed IPv6 native backbones using encapsulation. (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 defines a mechanism for transporting IPv4 multicast traffic over single-stack IPv6 multicast service provider's networks. This is achieved through the use of the underlying IPv6 multicast distribution tree. The IPv4 traffic is statelessly encapsulated in IPv6. The main benefit of this solution is using an IPv6 multicast network for the efficient distribution of IPv4 based multicast content. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is consensus in the WG for the publication of this document. A question was raised about scope overlap between this document and RFC8114 (Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network). The two differ in the RFC8114 covers multicast for DSLite based networks, whereas this document is for multicast over mesh based provider backbone networks. Text has been added to the Introduction of this document to clarify the difference in scope and the authors of RFC8114 have agreed the text. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? One of the authors (Shu Yang) stated that the Bitway company (a networking device company in China) have implemented a prototype. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Ian Farrer (Softwire co-chair), is the Document Shepherd. Terry Manderson is the Responsible AD. (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. The document has been reviewed by the Document Shepherd for technical content, completeness and language. All raised comments have been resolved. The document is well written 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. N/A. (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. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR issues have been filed. All authors have confirmed that they are not aware of any IPR related to this document. (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 WG consensus has been achieved and all of the related active participants agree on the advancement of 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.) 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. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review are necessary. (13) Have all references within this document been identified as either normative or informative? Yes. (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). This document contains no requests to IANA. (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. N/A. (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. None (no formal language included in the document). |
2018-06-29
|
22 | Ian Farrer | Responsible AD changed to Terry Manderson |
2018-06-29
|
22 | Ian Farrer | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-06-29
|
22 | Ian Farrer | IESG state changed to Publication Requested |
2018-06-29
|
22 | Ian Farrer | IESG process started in state Publication Requested |
2018-06-29
|
22 | Ian Farrer | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-06-29
|
22 | Ian Farrer | Changed consensus to Yes from Unknown |
2018-06-29
|
22 | Ian Farrer | Intended Status changed to Proposed Standard from None |
2018-06-29
|
22 | Ian Farrer | Changed document writeup |
2018-06-18
|
22 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-22.txt |
2018-06-18
|
22 | (System) | New version approved |
2018-06-18
|
22 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , Yong Cui , Chris Metz , Shu Yang , Mingwei Xu |
2018-06-18
|
22 | Shu Yang | Uploaded new revision |
2018-06-01
|
21 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-21.txt |
2018-06-01
|
21 | (System) | New version approved |
2018-06-01
|
21 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Shu Yang , Yong Cui , Chris Metz , Mingwei Xu |
2018-06-01
|
21 | Shu Yang | Uploaded new revision |
2018-03-24
|
20 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-20.txt |
2018-03-24
|
20 | (System) | New version approved |
2018-03-24
|
20 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Chris Metz , … Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Chris Metz , Mingwei Xu |
2018-03-24
|
20 | Shu Yang | Uploaded new revision |
2018-01-29
|
19 | Ian Farrer | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-01-29
|
19 | Ian Farrer | IETF WG state changed to WG Document from In WG Last Call |
2018-01-11
|
19 | Ian Farrer | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-01-11
|
19 | Ian Farrer | IETF WG state changed to In WG Last Call from WG Document |
2017-11-15
|
19 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-19.txt |
2017-11-15
|
19 | (System) | New version approved |
2017-11-15
|
19 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , Greg Shepherd , Shu Yang , Yong Cui , Chris Metz , Mingwei Xu |
2017-11-15
|
19 | Shu Yang | Uploaded new revision |
2017-10-26
|
18 | Ian Farrer | This got accidentally left in the WGLC state. Once an update with the issues raised at WGLC is received, the document should be ready to … This got accidentally left in the WGLC state. Once an update with the issues raised at WGLC is received, the document should be ready to advance. |
2017-10-26
|
18 | Ian Farrer | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-10-26
|
18 | Ian Farrer | IETF WG state changed to WG Document from In WG Last Call |
2017-09-24
|
18 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-18.txt |
2017-09-24
|
18 | (System) | New version approved |
2017-09-24
|
18 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Mingwei Xu , … Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Mingwei Xu , Chris Metz |
2017-09-24
|
18 | Shu Yang | Uploaded new revision |
2017-08-03
|
17 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-17.txt |
2017-08-03
|
17 | (System) | New version approved |
2017-08-03
|
17 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , Greg Shepherd , Mingwei Xu , Yong Cui , Shu Yang , Chris Metz |
2017-08-03
|
17 | Shu Yang | Uploaded new revision |
2017-03-31
|
16 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-16.txt |
2017-03-31
|
16 | (System) | New version approved |
2017-03-31
|
16 | (System) | Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Mingwei Xu , Yong Cui , … Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Mingwei Xu , Yong Cui , Chris Metz |
2017-03-31
|
16 | Shu Yang | Uploaded new revision |
2017-03-09
|
15 | Ian Farrer | IETF WG state changed to In WG Last Call from WG Document |
2017-01-10
|
15 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-15.txt |
2017-01-10
|
15 | (System) | New version approved |
2017-01-10
|
15 | (System) | Request for posting confirmation emailed to previous authors: "Shu Yang" , "Jianping Wu" , "Mingwei Xu" , "Greg Shepherd" , "Chris Metz" , "Yong Cui" |
2017-01-10
|
15 | Shu Yang | Uploaded new revision |
2016-11-13
|
14 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-14.txt |
2016-11-13
|
14 | (System) | New version approved |
2016-11-13
|
14 | (System) | Request for posting confirmation emailed to previous authors: "Shu Yang" , "Jianping Wu" , "Mingwei Xu" , "Greg Shepherd" , "Chris Metz" , "Yong Cui" |
2016-11-13
|
14 | Shu Yang | Uploaded new revision |
2016-07-05
|
13 | Ian Farrer | Notification list changed to "Ian Farrer" <ianfarrer@gmx.com> |
2016-07-05
|
13 | Ian Farrer | Document shepherd changed to Ian Farrer |
2016-05-23
|
13 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-13.txt |
2016-04-04
|
12 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-12.txt |
2016-02-04
|
11 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-11.txt |
2015-08-04
|
10 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-10.txt |
2015-01-22
|
09 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-09.txt |
2015-01-22
|
08 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-08.txt |
2014-07-21
|
07 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-07.txt |
2014-01-14
|
06 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-06.txt |
2013-07-15
|
05 | Shu Yang | New version available: draft-ietf-softwire-mesh-multicast-05.txt |
2013-01-12
|
04 | Xuan Chen | New version available: draft-ietf-softwire-mesh-multicast-04.txt |
2012-07-14
|
03 | Xuan Chen | New version available: draft-ietf-softwire-mesh-multicast-03.txt |
2012-04-18
|
02 | Xuan Chen | New version available: draft-ietf-softwire-mesh-multicast-02.txt |
2011-10-28
|
01 | (System) | New version available: draft-ietf-softwire-mesh-multicast-01.txt |
2011-09-14
|
00 | (System) | New version available: draft-ietf-softwire-mesh-multicast-00.txt |