Hi John, If Mark is correct, and if C247 <http://www.rfc-editor.org/cluster_info.php?cid=C247> is the set of documents in question, note that we expect to have these documents moved to AUTH48 within the next week.
The information Mark provided is correct from the RPC perspective (thanks Mark), but we would ask the the IESG to request expedited processing, which means that the docs would take priority in our queue and we could realease the documents (with their assigned RFC numbers) to AUTH48 more quickly. This isn't necessary for C247 because the cluster is about ready to move to AUTH48. Please let us know if you have any questions. Thank you, RFC Editor/sg On Thu, Jun 25, 2015 at 06:00:53PM +0200, Mark Townsley wrote: > John, > > Here is a link to the cluster of documents that I believe you are looking > to have RFC numbers for: > > http://www.rfc-editor.org/cluster_info.php?cid=C247 > > IIRC, at least back when I was AD, it was possible to request RFC numbers > in advance as long as they were in the Editor's queue (past all WG, IESG, > and IETF approvals). I've cc'd the softwires AD and the RFC Editor here as > they would be the ones that could make that happen if it is still possible. > Of course, it will be important in the cablelabs documents to only use the > RFC number as a placeholder until the RFC is actually available. > > As for how long it will take with the normal process, you may draw your own > conclusions here: > > http://www.rfc-editor.org/all_clusters.php > http://www.rfc-editor.org/CurrQstats.txt > > Pro tip: If you reference a draft using the tools.ietf.org website without > a specific version number, it will automatically reflect the RFC number and > a link to it once the RFC is finally published. e.g., > > https://tools.ietf.org/html/draft-ietf-softwire-map-dhcp > > It could be better though, as while you will get the link to the RFC once > it arrives, what you really want is to see the final RFC itself displayed > by default. For example, > > https://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd > > displays draft-ietf-softwire-ipv6-6rd-10 rather than RFC5969 by default. > I'll open a wish-list ticket to fix that :-) > > Hope this helps, > > - Mark > > > > > > > On Jun 18, 2015, at 6:41 PM, John Berg <[email protected]> wrote: > > > > > > This is my first time posting to the Softwires mailing list and I would > > like to introduce myself, John Berg, Lead Engineer supporting emerging > > network technologies projects for CableLabs. I have been a long term > > proponent for migration to IPv6 and a long time follower of drafts coming > > out of this working group, even if this is my first time posting here. A > > lot of good work has come out of this group over the years, and a lot of > > the substance of this work has helped form the standards in many CableLabs > > specifications. So, I hope to continue to learn from and contribute to > > this working group going forward. > > > > > > My purpose in writing to the mailing list today was to draw attention to > > some of the work being done around co-existence technologies, particularly > > MAP-E and MAP-T. Over the last several years I have seen great progress > > made by several of our member organizations in the migration to IPv6 only > > networks. It has also been clear that IPv6 network evolution has outpaced > > the adoption of IPv6 in home networks, particularly in the various CPE > > products that would be attached to them. There is no question that this > > has bogged down the efforts of operators to migrate to full end to end IPv6 > > networks. > > > > > > In the past year or so, another thing that has become clear is the need > > to continue to co-exist with IPv4 only devices in the home network. IPv4 > > exhaustion set aside, there is a clear and imminent need to accommodate > > IPv4 only capable devices in IPv6 only networks. In fact, several MSOs > > have come to us asking that we help define new standards that will make > > IPv4/IPv6 co-existence possible, particularly in customer edge devices such > > as home routers and eRouters. These new standards must avoid the pitfalls > > of earlier co-existence technologies that introduced a potential for > > impacting the user experience. Enter MAP-E and MAP-T as viable and > > scalable solutions to this problem. > > > > > > CableLabs, with the input of our member organizations, is now > > aggressively adding requirements to our eRouter specification for MAP-E and > > MAP-T. These technologies are viewed as being the quick and near term > > solution to IPv4/IPv6 co-existence, and the hope is that they can be > > adopted quickly and in a manner that is seamless to the subscriber. But > > although the substance of the MAP IETF draft documents is solid, we find > > ourselves writing requirements against the current versions of the drafts > > and not the RFCs. > > > > > > Given the urgency with which operators would like to deploy MAP as a > > solution for IPv4/IPv6 co-existence, CableLabs respectfully requests the > > Softwires working group to advance the IETF drafts for MAP to RFC status as > > quickly as possible. In particular, MAP-E, MAP-T, and MAP DHCP IETF drafts > > are extremely relevant to defining requirements for edge devices and > > operator deployment strategies. We feel that RFC versions of these > > standards would lead to more stable implementations of MAP in vendor > > products, and the potential for new or shifting requirements would be > > greatly reduced or eliminated. > > > > > > Thank you in advance for your consideration of my observations and > > requests, and I will look forward to my future interaction with this > > working group. > > > > > > Best Regards, > > > > > > John Berg > > > CableLabs > > > Lead Engineer ??? Network Technologies > > > 858 Coal Creek Circle > > > Louisville, CO 80027 > > > 303 661-3882 > > > _______________________________________________ > > > Softwires mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
