Re: Revised Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I like this. Nit: There's a missing to in the last line.
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
Joel, Thanks for writing this. I have some detailed comments, but perhaps I should first start with my own perception of the meeting. I traveled to this meeting as a part my trip to attend RIPE a few days, and to catch a few different people in the hallways on separate topics. One datapoint: I would probably not have made the trip just for RIPE this time (although I usually do travel to them), nor would I have attended just for the LIM itself. I was quite surprised by the small attendance, what I heard from the secretariat was 30+ people registered for the interim. From a pure financial perspective this meeting did not seem to make a lot of sense for the IETF, 30 x 100$ for a lot of secretariat effort/travel, and presumably money for room fees and other costs. Most previous interim meetings have operated on a hosting/sponsoring model, or run in zero cost environments. I'd say that anything under hundred persons is probably easier to deal with in that way than attempt to use an official organization for it. But money is really a side issue, so lets not focus on the above too much. What matters if we can progress the IETF's work: The various meeting had a big difference between them. The SIDR meeting was clearly a close group of people with an intent to solve a design problem, going over an issue after another issue, involving people who would not have traveled to the IETF, and at least from my perspective the meeting was making quite a lot of progress in some issues that had been divisive earlier. This reminded me of some earlier SOFTWIRE meetings, for instance, where the designers and implementors met and made a lot of progress. An excellent meeting! FWIW, in the IETF I would not have had time to go to SIDR, and I would not have traveled anywhere to go to a SIDR meeting. But I'm glad I went to this one because it allowed me to learn more about this technology, and some of the layer nine implications at the IAB force me to try to understand its state. I did not attend OPSEC, but I attended V6OPS. All discussions were useful, but topics seemed somewhat disconnected, and they did not cover the whole range of usual V6OPS work. It was clear that the room did not have the full set of key contributors in the WG. I had prepared comments on a recent topic in the mailing list, but the relevant people were not there to receive my comments. Nevertheless, the V6OPS meeting did have a fair number of the usual experts in this topic, as well as a couple of extra people from the European routing community. I was able to have a high-bandwidth discussion on several topics with the people present; albeit that was in the hallways and after the meeting. We started one new draft for V6OPS based on this interim, and another (yet to be completed) work item for the HOMENET WG. In the latter case I would not have had the necessary people present in the IETF, so for me this was quite positive. It is hard to tell why there was no more attendance in V6OPS. Wrong time and place? Or true lack of interest to invest in some of the topics that we are just not seeing it in the IETF because everyone comes there anyway? Conclusions? Maybe we need more discussion on this, but here are some obvious ones: o Interim meetings can be extremely productive in the right situation. Or completely unnecessary in others. It is difficult to find a situation where the planets are properly aligned such that several working groups are in the right phase to have an interim meeting, and that the co-location with some event makes sense for all of those working groups. In other words, the success of a LIM seems somewhat unlikely, though there may be success for individual WG interims. o Co-location with RIPE appeared useful. I agree with you Joel that tighter packing would have made a difference. I met some people who noted they will not attend, but probably would have attended if it was during the week. Co-locating individual WG interims with RIPEs and NANOGs seems like a useful concept to consider in the future. o LIMs will not create a new big funding source for the IETF. We should also right-size our organization for the task at hand. 30, 50, or even 100 people could probably be handled as part of the RIPE meeting, and might have been something that the RIPE registration system and agenda could have accommodated, or have someone sponsor a room and leave the rest to participants. o As usual, hallways matter more than the official meetings. Put the right people in the same building, and I'll attend, even if the topic would be International Charactersets for EBCDIC-based FTP. o Saturday is not a good day. Detailed comments: The LIM was the attempt that I am aware of an interim meeting scheduled by IETF management for the purposes of accumulating interim Does not parse. Did you mean to say that LIM was the only attempt of its kind? A couple of years ago we also had the Malta
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
On 10/15/12 2:53 PM, Adrian Farrel wrote: ok, i am lost. the draft is only an outline and has zero content? is it a quiz? Treat it like that and see if you can give Joel the right answers. 01 is available. I imagine the SIDR experience was a bit different, having been to another SIDR interim, I tried to call that out, but I wasn't in the room. http://tools.ietf.org/html/draft-jaeggli-interim-observations-01 For me: Did it make any difference to you that it was a LIM rather than simply a SIDR interim? Were logistics and resources worth the fee? Should we hold future LIMs, or do the scheduling and other issues mean that normal interims are the way forward? cheers, Adrian
Gen-ART review of draft-ietf-softwire-dslite-deployment-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-dslite-deployment-06 Reviewer: David L. Black Review Date: October 15, 2012 IETF LC End Date: October 16, 2012 IESG Telechat Date: October 25, 2012 Summary: This draft is on the right track but has open issues, described in the review. This is a generally well-written draft that expands considerably on the brief deployment considerations for DS-Lite in Appendix A of RFC 6333. The draft is clear and reasonably well-written, and a significant improvement on that RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to understand this draft, which seems completely reasonable. The B4 and AFTR acronyms are clever - kudos to whomever came up with those. I found five open issues, all of which are minor. Minor Issues: [1] Ironically, the first issue is that something should be said about the relationship of this draft to Appendix A of RFC 6333. It probably suffices to say that this draft expands on the material in that Appendix, as I see no need to specify that this draft updates RFC 6333 solely to change non-normative material in an Appendix. [2] The MTU increase technique in Section 2.2 is a may, which is consistent with Section 5.3 of RFC 6333. OTOH, Section 2.2 of this draft should also discuss the AFTR resource exhaustion concern that described in Section 6.3 of RFC 6333, as that is a potential operational reason for an ISP to increase MTU size (e.g., if customer sourcing of large IPv4 packets is not sufficiently rare). [3] Section 2.7 refers to the AFTR's internal interface. There may be two internal interfaces, the physical IPv6 interface (outer header) and the tunnel's IPv4 interface (inner header). The text should be clarified to indicate which interface is involved - it appears that the AFTR's physical IPv6 interface is intended in this section. [4] Section 2.7 cites RFC 6333 for use of DHCPv6 with DS-Lite. RFC 6334 should be cited - either in addition to or instead of RFC 6333. [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that the AFTR does not have detailed customer identity information. Does that create a theft of service possibility? If so, that possibility should be mentioned as a security consideration. Also, Section 2.8 ought to be expanded with a sentence or two explaining why the AFTR does not have that identity information, and in particular to explain whether and why it is unreasonable in some or all cases to expect that customer identity information be provided to the AFTR as part of provisioning each customer's softwire. Nits: Section 2.3 on MTU Considerations could usefully mention MTU discovery techniques, as possibilities for customer IPv4 traffic to adapt to a smaller IPv4 MTU. If this is done, it would be useful to mention RFC 4821 in addition to the mention of RFC 1191 in RFC 6333. Section 2.4 should define lawful intercept. It would be helpful to cite a reference for this concept if something appropriate can be found. Section 2.5: - Are one or both types of logging recommended? - Last paragraph on p.4, timestamped log is not a good verb phrase. maintain a timestamped log of would be a better replacement. - Last paragraph in section, where is the batch file sent? In Section 2.7, I'm having a hard time understanding which traffic is intended to be subject to the Outgoing Policies and the Incoming Policies. Expanding each of those two bullets to explain what traffic is subject to each class of policies would help. Section 3.2.2.2 uses 192.0.0.2/32 as an example IP address for the B4. That section should also cross-reference Section 5.7 on RFC 6333 on IP address assignment to B4s, as other IP addresses may be used. idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at version 28. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Format=flowed quoting (was Re: IETF...the unconference of SDOs)
At 9:12 AM -0400 9/5/12, Michael Richardson {quigon} wrote:
Maybe I'm also concerned because many in the former elite have
moved to Apple Mail, and it seems that it is bug
compatible with Outlook in it's assumption that format=flowed is
the default, an act which destroys email quoting, and therefore
discussion.
I just noticed this assertion, which is quite false. Format=flowed
protects and preserved quoting. It's the only way to avoid ludicrous
and impossible to read quoting (which happens after quoted passages
get line-wrapped at odd points). Also, as far as I know, Exchange
does not support format=flowed at all. My understanding is that it
insists on HTML quoting, which is entirely different.
--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly selected tag: ---
Once a job is fouled up, anything done to improve it only makes
it worse.
RE: Last Call: draft-ietf-storm-iser-12.txt (iSCSI Extensions for RDMA Specification) to Proposed Standard
For those interested in what has changed in this draft by comparison to the specification of iSER in RFC 5046, here's a reasonably readable diff that shows the text changes: http://www.stiemerling.org/ietf/storm-review/diff-rfc5046-to-iser.html and the edited version of RFC 5046 on which this was based http://www.stiemerling.org/ietf/storm-review/rfc5046-edited.txt All of the content of RFC 5046 is preserved in that version, but the changes to improve the diff include swapping the order of sections 1 and 2 in order to match the storm-iser draft, and taking out page gutters that confuse the IETF diff tool. And many thanks to our AD (Martin Stiemerling) for hosting this on his web site. FYI, --David -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, October 08, 2012 10:13 AM To: IETF-Announce Cc: st...@ietf.org Subject: Last Call: draft-ietf-storm-iser-12.txt (iSCSI Extensions for RDMA Specification) to Proposed Standard The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'iSCSI Extensions for RDMA Specification' draft-ietf-storm-iser-12.txt 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 2012-10-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iser/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iser/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
o Co-location with RIPE appeared useful. I agree with you Joel that tighter packing would have made a difference. I met some people who noted they will not attend, but probably would have attended if it was during the week. Co-locating individual WG interims with RIPEs and NANOGs seems like a useful concept to consider in the future. ripe/foonog would not appreciate a meeting in schedule conflict. would ietf appreciate a foonog meeting scheduled in conflict with and at the same venue as an ietf meeting? fwiw, sidr has met adjacent to a few foonogs and it was quite worthwhile to have the extra ops that brought in. i wonder if it would be good to have a sidr meeting adjacent to a security meeting. oops, we did that too i think. o LIMs will not create a new big funding source for the IETF. We should also right-size our organization for the task at hand. 30, 50, or even 100 people could probably be handled as part of the RIPE meeting, and might have been something that the RIPE registration system and agenda could have accommodated, or have someone sponsor a room and leave the rest to participants. foonog meeting coordination folk are generally very accommodating and generous. but beware that, often due to association with organizations which have a monopoly on scarce intergers and thus pre-crash budget contraints, foonogs often meet at expensive venues. randy
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
Randy, ripe/foonog would not appreciate a meeting in schedule conflict. would ietf appreciate a foonog meeting scheduled in conflict with and at the same venue as an ietf meeting? Agreed. But here's at least one idea on how to avoid that. Arrange an interim on a RIPE Friday afternoon, after the meetings have ended. Say, 2pm - 8pm. Long day and somewhat shorter WG time. But probably more doable for participants than a full Saturday. Other meetings may have similar scheduling opportunities. Jari
Re: [IETF] I-D Action: draft-jaeggli-interim-observations-00.txt
On Oct 15, 2012, at 5:53 PM, Adrian Farrel adr...@olddog.co.uk wrote: ok, i am lost. the draft is only an outline and has zero content? is it a quiz? Treat it like that and see if you can give Joel the right answers. For me: Did it make any difference to you that it was a LIM rather than simply a SIDR interim? Yes -- because it was LIM multiple WGs met at the same time. This meant that OpSec and V6Ops conflicted with SIDR, and so I missed the SIDR meeting. Were logistics and resources worth the fee? Personally I think so -- I have been involved in multiple interims, and the quality of the remote participation was (IMO) much better at the LIM. Having someone else (Meetecho) handle the audio / video was great… We (OpSec) were hoping to get more of the RIPE attendees (aka, operators) to show up and participate, but: A: there was a gap between RIPE and the LIM, B: the existence of the LIM was not announced far enough in advance for most RIPE attendees to change their plans C: we (OpSec) did a poor job of announcing the fact that we would be meeting, and asking for operators to come participate. Should we hold future LIMs, or do the scheduling and other issues mean that normal interims are the way forward? Sorry, but figuring this sort of thing out is what we pay *you* for… (aka, I don't know, to close to call). W cheers, Adrian -- What our ancestors would really be thinking, if they were alive today, is: Why is it so dark in here? -- (Terry Pratchett, Pyramids)
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
Hi Olafur, I posted the following question about the draft about two weeks ago [1]: On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be part of STD 13? I did not see any comments from the WG about that. I had an off-list exchange with the RFC Series Editor about STDs. The question seems like an IETF matter. Has this question been discussed by the WG, and if so, what was the conclusion? Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg75156.html
Re: [dnsext] Last Call: draft-ietf-dnsext-rfc2671bis-edns0-09.txt (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard
On 16/10/2012 17:43, SM wrote: Hi Olafur, I posted the following question about the draft about two weeks ago [1]: On publication of draft-ietf-dnsext-rfc2671bis-edns0-09, will it be part of STD 13? I did not see any comments from the WG about that. I had an off-list exchange with the RFC Series Editor about STDs. The question seems like an IETF matter. Has this question been discussed by the WG, and if so, what was the conclusion? It was not explicitly discussed. Olafur Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg75156.html
Re: I-D Action: draft-jaeggli-interim-observations-00.txt
On Oct 17, 2012, at 4:19 AM, Randy Bush wrote: o Co-location with RIPE appeared useful. I agree with you Joel that tighter packing would have made a difference. I met some people who noted they will not attend, but probably would have attended if it was during the week. Co-locating individual WG interims with RIPEs and NANOGs seems like a useful concept to consider in the future. ripe/foonog would not appreciate a meeting in schedule conflict. would ietf appreciate a foonog meeting scheduled in conflict with and at the same venue as an ietf meeting? One hopes he was looking for constructive engagement, such as IETF and IRTF do during an IETF meeting. The interspersed meeting is on the same agenda as all of the other meetings, and not on a separate track. The IETF doesn't promise IRTF meeting slots, but if slots are available, it makes them available.
WG Review: Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2012-10-23. Bidirectional Forwarding Detection (bfd) Current Status: Active Working Group Chairs: David Ward dw...@cisco.com Jeffrey Haas jh...@pfrc.org Technical advisors: Dave Katz dk...@juniper.net Assigned Area Director: Adrian Farrel adr...@olddog.co.uk Mailing list Address: rtg-...@ietf.org To Subscribe: rtg-bfd-requ...@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol in discussion with the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying-based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Assist the MPLS working group in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 5. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. The working group will maintain a relationship with the KARP and MPLS working groups, and will communicate with the IEEE with respect to BFD over LAGs. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Sep 2011 - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Dec 2011 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Mar 2012 - Submit the the document on BFD
WG Action: Rechartered Operations and Management Area Working Group (opsawg)
The Operations and Management Area Working Group (opsawg) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Operations and Management Area Working Group (opsawg) Current Status: Active Working Group Chairs: Scott Bradner s...@harvard.edu Chris Liljenstolpe christopher.liljensto...@bigswitch.com Melinda Shore melinda.sh...@gmail.com Assigned Area Director: Ronald Bonica rbon...@juniper.net Mailing list Address: ops...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Charter of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the OM area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Templates and tools for Operations and Management Area Documents (B) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). (C) The RFC 5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB has transitioned to the IEEE 802.3. However, as agreed with the IEEE, the IF-CAP-STACK-MIB MIB module (from RFC5066) is generic by nature and should continue to be supported by the IETF. The WG will develop a document extracting the IF-CAP-STACK-MIB from RFC5066, emphasizing the generic nature of this module, and obsolete RFC5066. (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with the corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions (mailing lists, reviews), and clarifications on the intellectual property considerations. Milestones: Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP Done - WGLC for the 'Structured Data Elements (SDEs) for syslog' Done - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard Oct 2012 - Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft Mar 2013 - Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational
