Last Call: draft-ietf-krb-wg-gss-cb-hash-agility-08.txt (Kerberos Version 5 GSS-API Channel Binding Hash Agility) to Proposed Standard
The IESG has received a request from the Kerberos WG (krb-wg) to consider the following document: - 'Kerberos Version 5 GSS-API Channel Binding Hash Agility' draft-ietf-krb-wg-gss-cb-hash-agility-08.txt as a 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 i...@ietf.org mailing lists by 2011-11-07. 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 Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-gss-cb-hash-agility/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-gss-cb-hash-agility/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'LSP Attributes Related Routing Backus-Naur Form' to Proposed Standard (draft-ietf-ccamp-attribute-bnf-02.txt)
The IESG has approved the following document: - 'LSP Attributes Related Routing Backus-Naur Form' (draft-ietf-ccamp-attribute-bnf-02.txt) as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-attribute-bnf/ Technical Summary Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attribute are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form, and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. Working Group Summary No issues. The document is considered to be both stable and complete. Note that the updates cahin for RSVP-TE is quite complex and it is customary to only show the updates for the head of the chain in any new update. Thus, this document is shown as updating RFC 4875 and RFC 5420, but not RFC 3209 or RFC 3473. Document Quality Note that no formal tool exists for checking RBNF as defined in RFC 5511. Thus, all checks have been done by hand/eye. No implementations have been publicly discussed. However, implementations of RFC 4875 and RFC 5420 are known to exist, and are conformant with this specification. Furthermore, this document is required as a normative reference from draft-ietf-mpls-rsvp-te-no-php-oob-mapping which is known to have been implemented. Personnel Deborah Brungard (dbrung...@att.com) is the Document Shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note Please edit for consistency: The objects are called LSP Attributes and LSP Required Attributes Section 1 OLD: processed in Resv messages of P2MP LSPs. NEW processed in Resv messages of P2MP LSPs (which are defined in [RFC4875]). END Section 1 OLD: The current message format description has led to an issue in how the LSP Attributes related objects are to be processed... NEW The current message format description has led to the open question of how the LSP Attributes related objects are to be processed... END Section 3.2.1 OLD: A node that does not support the LSP Attribute object formatting as defined in this section will interpret the first present LSP Attribute object as representing LSP operational status even when it is intended to represent S2L sub-LSP status. NEW: A node that supports [RFC4875] and [RFC5420], but not this document, will interpret the first LSP Attribute object present in a received message, which is formatted as described in this document, as representing LSP operational status rather than S2L sub-LSP status. END ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The RPKI Ghostbusters Record' to Proposed Standard (draft-ietf-sidr-ghostbusters-15.txt)
The IESG has approved the following document: - 'The RPKI Ghostbusters Record' (draft-ietf-sidr-ghostbusters-15.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-ghostbusters/ Technical Summary In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. Working Group Summary There was no outstanding notable action from the WG work on this document. Document Quality There are two vendors providing support and software for this solution. Personnel Chris Morrow (morr...@ops-netman.net) is the document shepherd. Stewart Bryant is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Time to Remove Filters for Previously Unallocated IPv4 /8s' to BCP (draft-ietf-grow-no-more-unallocated-slash8s-04.txt)
The IESG has approved the following document: - 'Time to Remove Filters for Previously Unallocated IPv4 /8s' (draft-ietf-grow-no-more-unallocated-slash8s-04.txt) as a BCP This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-no-more-unallocated-slash8s/ Technical Summary It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile and expensive. Network administrators are advised to remove filters based on the registration status of the address space. This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. Working Group Summary There were no standout notes in the WG process for this document. Document Quality This document covers operational guidance, not code. As such there are no implementations and this is not a protocol. RFC Editor Note OLD Network operators who only wish to filter traffic originating from addresses that should never be routed across the Internet, Martians, can deploy a set of packet and prefix filters designed to block traffic from address blocks reserved for special purposes. These are: - 0.0.0.0/8 (Local identification) [RFC1122]; - 10.0.0.0/8 (Private use) [RFC1918]; - 127.0.0.0/8 (Loopback) [RFC1122]; - 169.254.0.0/16 (Link local) [RFC3927]; - 172.16.0.0/12 (Private use) [RFC1918]; - 192.0.2.0/24 (TEST-NET-1) [RFC5737]; - 192.168.0.0/16 (Private use) [RFC1918]; - 198.18.0.0/15 (Benchmark testing) [RFC2544]; - 198.51.100.0/24 (TEST-NET-2) [RFC5737]; - 203.0.113.0/24 (TEST-NET-3) [RFC5737]; - 224.0.0.0/4 (Multicast) [RFC5771]; and - 240.0.0.0/4 (Future use) [RFC1112]. A full set of special use IPv4 addresses can be found in [RFC5735]. It includes prefixes that are intended for Internet use. NEW Network operators may deploy filters that block traffic destined for Martian prefixes. Currently, the Martian prefix table is defined by [RFC 5735] which reserves each Martian prefix for some specific, special-use. If the Martian prefix table ever changes, that change will be documented in an RFC that either updates or obsoletes [RFC 5735]. END ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
All, I've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I have taken the time to read this document and support it's publication. From an operational PoV, the discussion in the Section 3 (particularly Sections 3.5 3.6) really hit home in that the costs of deploying a protocol to the network _and_ maintaining that protocol in the network are non-trivial. And, ultimately, for a function as critical as OAM it absolutely needs to just work *everywhere*. -shane On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Loa, As per my previous email , I have only seen one response to the 12 points that I raised, I do not agree with your assessment of this document. Just to remind you of the points made by myself and several others on SONET and SDH: SONET is a true subset of SDH: The SDH standard supports both the North American and Japanese 24 channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based hierarchy within a single multiplexing structure. SDH has no options for payloads at VC-4 (150Mb/s) and above. This has provided the basis for common solutions for packet based clients (GFP). SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infra structure. A single standard that supported either the T1/T3 hierarchy or the E1 hierarchy would not have been successful. Deployment of a E1 only standard in North America would have required the conversion of all of the 24 channel/T1 deployed equipment and services into the 30 channel/E1 format. Similarly deployment of a T1 only standard in Europe would have required the conversion of all of the 30 channel/E1 equipment and services into 24 channel/T1 format. Clearly given the existing network deployments (in 1988) this was not a practical proposition. Regards, Malcolm Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 23/10/2011 02:07 PM To i...@ietf.org cc The IESG iesg-secret...@ietf.org, IETF-Announce ietf-announce@ietf.org Subject Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-24. 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 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list
Document Action: 'Requirements for a Working Group Milestones Tool' to Informational RFC (draft-ietf-genarea-milestones-tool-06.txt)
The IESG has approved the following document: - 'Requirements for a Working Group Milestones Tool' (draft-ietf-genarea-milestones-tool-06.txt) as an Informational RFC This document is the product of the General Area Open Meeting. The IESG contact person is Russ Housley. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-genarea-milestones-tool/ Technical Summary The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. Working Group Summary This document is not the product of any IETF WG. Issues covered by this document have been discussed on the WG Chair mailing list. Document Quality The document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 169, RFC 6382 on Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
A new Request for Comments is now available in online RFC libraries. BCP 169 RFC 6382 Title: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services Author: D. McPherson, R. Donnelly, F. Scalzo Status: Best Current Practice Stream: IETF Date: October 2011 Mailbox:dmcpher...@verisign.com, rdonne...@verisign.com, fsca...@verisign.com Pages: 10 Characters: 25224 See Also: BCP0169 I-D Tag:draft-ietf-grow-unique-origin-as-01.txt URL:http://www.rfc-editor.org/rfc/rfc6382.txt This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. This memo documents an Internet Best Current Practice. This document is a product of the Global Routing Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6392 on A Survey of In-Network Storage Systems
A new Request for Comments is now available in online RFC libraries. RFC 6392 Title: A Survey of In-Network Storage Systems Author: R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed. Status: Informational Stream: IETF Date: October 2011 Mailbox:ral...@google.com, akbar.rah...@interdigital.com, y...@cs.yale.edu Pages: 44 Characters: 90978 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-decade-survey-06.txt URL:http://www.rfc-editor.org/rfc/rfc6392.txt This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Decoupled Application Data Enroute Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
