BCP 141, RFC 9542 on IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
A new Request for Comments is now available in online RFC libraries. BCP 141 RFC 9542 Title: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters Author: D. Eastlake 3rd, J. Abley, Y. Li Status: Best Current Practice Stream: IETF Date: April 2024 Mailbox:d3e...@gmail.com, jab...@strandkip.nl, liyiz...@huawei.com Pages: 32 Obsoletes: RFC 7042 See Also: BCP 141 I-D Tag:draft-ietf-intarea-rfc7042bis-11.txt URL:https://www.rfc-editor.org/info/rfc9542 DOI:10.17487/RFC9542 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. This document is a product of the Internet Area Working Group 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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
Protocol Action: 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' to Best Current Practice (draft-ietf-intarea-rfc7042bis-11.txt)
The IESG has approved the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' (draft-ietf-intarea-rfc7042bis-11.txt) as Best Current Practice This document is the product of the Internet Area Working Group. The IESG contact persons are Erik Kline and Éric Vyncke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/ Technical Summary Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042. Working Group Summary The mailing list archives shows that even if the number of emails in support of the last call is not huge there were no objections in moving this document forward. During the meetings there was a general support for this document and the need to update RFC 7042 (which this document actually obsoletes). The responsible AD, Eric Vyncke, was (and still is) not comfortable of having a CBOR encoding section in this document describing mainly code points. But, there was no opposition on this inclusion even after an email sent to INTAREA & CBOR WG and ADs, so let it be. See https://mailarchive.ietf.org/arch/msg/cbor/sPQtY45DCla9y2K6VTdy-LCfLIM/ Document Quality The document does not specify a protocol. Therefore, no implementation exists. There have been extensive reviews (including CBOR WG and by IEEE via the IEEE-IETF coordination list and liaison statement: https://datatracker.ietf.org/liaison/1849/ Personnel The Document Shepherd for this document is Luigi Iannone. The Responsible Area Director is Éric Vyncke. IANA Note (copied from the shepherd's write-up) The whole document is an IANA Consideration. The content is consistent. The document does not request the creation of new registries neither any new assignment. However, a few updates are requested to IANA, namely: - The IANA "Ethernet Numbers" web page is re-named the "IANA OUI Ethernet Numbers" web page. - References to [RFC7042] in IANA registries on both the IANA IEEE 802 Numbers web page and the IANA IETF OUI Ethernet Numbers web pages will be replaced by references to this document. - IANA is requested to move the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers web page to the IANA OUI Ethernet Numbers web page, and to add this document as an additional reference for that registry. IANA is requested to update three entries in that Registry as follows: | Value | Description | Reference | |---|--|-| | 0 | Reserved | [this document] | |42 | Example for use in documentation | [this document] | | 255 | Reserved | [this document] | - IANA is requested to assign two CBOR Tags: | Tag | Data Item | Semantics| Reference | |--|-|--|-| | TBD1 | byte string | IEEE MAC Address | [this document] | | TBD2 | byte string | IEEE OUI/CID | [this document] | ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' as Best Current Practice 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 last-c...@ietf.org mailing lists by 2023-10-12. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/ The IESG will also welcome feedback on one specific topic raised by the responsible AD: https://mailarchive.ietf.org/arch/msg/int-area/uf7MZFktoQKohLXlhkCBK01-tGM/ 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
RFC 9157 on Revised IANA Considerations for DNSSEC
A new Request for Comments is now available in online RFC libraries. RFC 9157 Title: Revised IANA Considerations for DNSSEC Author: P. Hoffman Status: Standards Track Stream: IETF Date: November 2021 Mailbox:paul.hoff...@icann.org Pages: 5 Updates:RFC 5155, RFC 6014, RFC 8624 I-D Tag:draft-ietf-dnsop-dnssec-iana-cons-05.txt URL:https://www.rfc-editor.org/info/rfc9157 DOI:10.17487/RFC9157 This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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
Protocol Action: 'Revised IANA Considerations for DNSSEC' to Proposed Standard (draft-ietf-dnsop-dnssec-iana-cons-05.txt)
The IESG has approved the following document: - 'Revised IANA Considerations for DNSSEC' (draft-ietf-dnsop-dnssec-iana-cons-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ Technical Summary This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. Working Group Summary There was a lot of debate and discussion when it was first introduced. There was a feeling that loosening the requirements on adding new DNSSEC algorithms would lead to algorithms not getting implemented, algorithms designed around national/"vanity" crypto, etc. This was resolved with some discussion. Document Quality The document changes the registration policy for an IANA registry, to better align with other registries. It is a process document and so there are no implementations, it is written appropriately for the intended audience, etc. Personnel Tim Wicinski is the DS Warren Kumari is RAD! (nope, still not old...) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Revised IANA Considerations for DNSSEC) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Revised IANA Considerations for DNSSEC' 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 last-c...@ietf.org mailing lists by 2021-09-16. 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 This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ 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
RFC 8425 on IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
A new Request for Comments is now available in online RFC libraries. RFC 8425 Title: IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags Author: O. Troan Status: Standards Track Stream: IETF Date: July 2018 Mailbox:o...@cisco.com Pages: 4 Characters: 6692 Updates:RFC 4861 I-D Tag:draft-ietf-6man-ndpioiana-04.txt URL:https://www.rfc-editor.org/info/rfc8425 DOI:10.17487/RFC8425 The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861. This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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
Protocol Action: 'IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags' to Proposed Standard (draft-ietf-6man-ndpioiana-04.txt)
The IESG has approved the following document: - 'IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags' (draft-ietf-6man-ndpioiana-04.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ Technical Summary The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. Working Group Summary There is support for this document in the 6MAN working group. There is a consensus to advance this document. Document Quality The quality of the document is very good, it has received adequate review in the working group on the mailing list and at a 6man session at an IETF meeting. Personnel Bob Hinden is the Document Shepherd. Suresh Krishnan is the Responsible Area Director.
Last Call: (IPv6 ND PIO Flags IANA considerations) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 ND PIO Flags IANA considerations' 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 i...@ietf.org mailing lists by 2018-03-06. 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 Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. This document updates RFC 4861. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 26, RFC 8126 on Guidelines for Writing an IANA Considerations Section in RFCs
A new Request for Comments is now available in online RFC libraries. BCP 26 RFC 8126 Title: Guidelines for Writing an IANA Considerations Section in RFCs Author: M. Cotton, B. Leiba, T. Narten Status: Best Current Practice Stream: IETF Date: June 2017 Mailbox:michelle.cot...@iana.org, barryle...@computer.org, nar...@us.ibm.com Pages: 47 Characters: 109907 Obsoletes: RFC 5226 See Also: BCP 26 I-D Tag:draft-leiba-cotton-iana-5226bis-20.txt URL:https://www.rfc-editor.org/info/rfc8126 DOI:10.17487/RFC8126 Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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
Protocol Action: 'Guidelines for Writing an IANA Considerations Section in RFCs' to Best Current Practice (draft-leiba-cotton-iana-5226bis-20.txt)
The IESG has approved the following document: - 'Guidelines for Writing an IANA Considerations Section in RFCs' (draft-leiba-cotton-iana-5226bis-20.txt) as Best Current Practice This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ Technical Summary This document is an update to RFC 5226, Guidelines for Writing an IANA Considerations Section in RFCs. This is version 3. Working Group Summary This is unrelated to any specific WG or RG -- it is mostly about interactions with IANA. It has been thoroughly discussed within IANA based on their experiences. The document also had a few comments on the i...@ietf.org list. Document Quality Since RFC 2434 was published, tens of thousands Internet-Drafts have been posted with IANA Considerations sections, and thousands of RFCs have been published based on those IANA Considerations sections. Major reviews were received from John Klensin and Mark Nottingham, as well as the document shepherd. Personnel Document Shepherd: Tony Hansen Responsible Area Director: Brian Haberman
Last Call: (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'Guidelines for Writing an IANA Considerations Section in RFCs' as Best Current Practice 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 2016-05-17. 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 Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values used in these fields do not have conflicting uses, and to promote interoperability, their allocation is often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, IANA needs guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance given to IANA is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The file can be obtained via https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-leiba-cotton-iana-5226bis-08.txt (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'Guidelines for Writing an IANA Considerations Section in RFCs' draft-leiba-cotton-iana-5226bis-08.txt as Best Current Practice 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 2014-10-30. 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 Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values used in these fields do not have conflicting uses, and to promote interoperability, their allocation is often coordinated by a central authority. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given namespace prudently, IANA needs guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance given to IANA is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition, and obsoletes RFC 5226. The file can be obtained via http://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 191, RFC 7319 on IANA Considerations for Connectivity Fault Management (CFM) Code Points
A new Request for Comments is now available in online RFC libraries. BCP 191 RFC 7319 Title: IANA Considerations for Connectivity Fault Management (CFM) Code Points Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: July 2014 Mailbox:d3e...@gmail.com Pages: 5 Characters: 7759 See Also: BCP 191 I-D Tag:draft-eastlake-iana-cfm-considerations-02.txt URL:https://www.rfc-editor.org/rfc/rfc7319.txt IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks. 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://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
Protocol Action: 'IANA Considerations for CFM (Connectivity Fault Management) Code Points' to Best Current Practice (draft-eastlake-iana-cfm-considerations-02.txt)
The IESG has approved the following document: - 'IANA Considerations for CFM (Connectivity Fault Management) Code Points' (draft-eastlake-iana-cfm-considerations-02.txt) as Best Current Practice This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ Technical Summary: IEEE 802.1 has specified OAM facilities called Continuity Fault Management (CFM). CFM messages are structured with an Op-Code field and have provision for the inclusion of TLV (type, length, value) structured information. Subsequent to a request from the TRILL WG, IEEE 802.1 has allocated blocks of CFM Op-Codes and TLV Types to the IETF. This document specifies the IANA Consideration for the assignment of values from these blocks. Working Group Summary: This is not a Working Group document. The IEEE 802.1 allocation supported by this document is to the IETF, to be used by various WG's, not to any particular WG. Hence, it is inappropriate for this draft to be a WG draft. Document Quality: The document is short, simple, and of good quality. It has been reviewed by IANA, the sponsoring AD, and a four week IETF Last Call. It conforms to the IANA Considerations requested by IEEE 802.1. Personnel: Document Shepherd: Sam Aldrin Responsible Area Director: Ted Lemon
Last Call: draft-eastlake-iana-cfm-considerations-01.txt (IANA Considerations for CFM (Continuity Fault Management) Codepoints) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for CFM (Continuity Fault Management) Codepoints' draft-eastlake-iana-cfm-considerations-01.txt as Best Current Practice 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 2014-05-21. 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 IEEE 802.1 has specified Continuity Fault Management (CFM) OAM facilities. CFM messages are structured with an Op-Code field and have provision for the inclusion of TLV (type, length, value) structured information. IEEE 802.1 has allocated blocks of CFM Op- Codes and TLV Types to the IETF. This document specifies the IANA Considerations for the assignment of values from these blocks. INTERNET-DRAFTIANA Considerations for CFM Codepoints The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-eastlake-iana-cfm-considerations-01.txt (IANA Considerations for CFM (Continuity Fault Management) Codepoints) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for CFM (Continuity Fault Management) Codepoints' draft-eastlake-iana-cfm-considerations-01.txt as Best Current Practice 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 2014-05-21. 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 IEEE 802.1 has specified Continuity Fault Management (CFM) OAM facilities. CFM messages are structured with an Op-Code field and have provision for the inclusion of TLV (type, length, value) structured information. IEEE 802.1 has allocated blocks of CFM Op- Codes and TLV Types to the IETF. This document specifies the IANA Considerations for the assignment of values from these blocks. INTERNET-DRAFTIANA Considerations for CFM Codepoints The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ballot/ No IPR declarations have been submitted directly on this I-D.
RESEND: Last Call: draft-eastlake-iana-cfm-considerations-01.txt (IANA Considerations for CFM (Continuity Fault Management) Codepoints) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for CFM (Continuity Fault Management) Codepoints' draft-eastlake-iana-cfm-considerations-01.txt as Best Current Practice 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 2014-05-21. 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 IEEE 802.1 has specified Continuity Fault Management (CFM) OAM facilities. CFM messages are structured with an Op-Code field and have provision for the inclusion of TLV (type, length, value) structured information. IEEE 802.1 has allocated blocks of CFM Op- Codes and TLV Types to the IETF. This document specifies the IANA Considerations for the assignment of values from these blocks. INTERNET-DRAFTIANA Considerations for CFM Codepoints The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 141, RFC 7042 on IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
A new Request for Comments is now available in online RFC libraries. BCP 141 RFC 7042 Title: IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters Author: D. Eastlake 3rd, J. Abley Status: Best Current Practice Stream: IETF Date: October 2013 Mailbox:d3e...@gmail.com, jab...@dyn.com Pages: 27 Characters: 53488 Obsoletes: RFC 5342 Updates:RFC 2153 See Also: BCP 141 I-D Tag:draft-eastlake-rfc5342bis-05.txt URL:http://www.rfc-editor.org/rfc/rfc7042.txt Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. 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/search/rfc_search.php 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
Protocol Action: 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' to Best Current Practice (draft-eastlake-rfc5342bis-05.txt)
The IESG has approved the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' (draft-eastlake-rfc5342bis-05.txt) as Best Current Practice This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ Technical Summary Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. Working Group Summary As was the previous document, this version was prepared under the assumption that this would this would be AD sponsored. There is a not a logically good home for an IANA maintained registry of IETF assigned entries under the IANA OUI, for the previous RFC the sponsoring AD was also the IEEE liason. Document Quality The document makes small but important changes to RFC 5342 (Repeated from the document) Add MAC addresses and IANA OUI-based protocol and other values for use in documentation. Eliminate any requirements for parallel unicast and multicast assignment that are not requested. Such requirements had been included in [RFC5342] on the theory they would make bookkeeping easier for IANA but have proved to be problematic in practice. The document has been reviewed by the previously shepherding AD. The document has been throught IETF last call and has Addressed IANA review concerns. Personnel Joel Jaeggli is the Shepherding AD and Author of the Shepherding report.
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
At 04:07 07-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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 2013-06-04. Exceptionally, comments may be Sorry for the late comments. I'll defer to the authors on what to do about them. In Section 2.1.3: o must be for standards purposes (either for an IETF Standard or other standard related to IETF work), The above is not that clear. I suggest using IETF Review. BTW, the documentation requirement could also be fulfilled with Specification Required. Section 2.3.2.1 mentions changes to RFC 2153. I suggest having an Updates: for that RFC. In Section 3.1: o the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work), IETF Review (see previous comment about that) could be used. In Section 4: If different policies from those above are required for such a parameter, a BCP or Standards Track RFC must be adopted updating this BCP and specifying the new policy and parameter. Standards Action could be used for this. In Section 5.1 I suggest using IESG Approval. BTW, IESG Ratification of an Expert Review approval recommendation looks unusual to me. Regards, -sm
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
Hi SM, On Fri, Jun 7, 2013 at 6:24 AM, SM s...@resistor.net wrote: At 04:07 07-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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 2013-06-04. Exceptionally, comments may be Sorry for the late comments. I'll defer to the authors on what to do about them. In Section 2.1.3: o must be for standards purposes (either for an IETF Standard or other standard related to IETF work), The above is not that clear. I suggest using IETF Review. BTW, the documentation requirement could also be fulfilled with Specification Required. I agree that it is not a precise, perfectly clear, mechanical rule. That is why there is a Expert to make judgements. This part is unchanged from RFC 5342 and actual experience does not indicate any problem. I believe that, since RFC 5342 came out, seven code points have been allocated under these provisions, all for single MAC addresses, and the only request I am aware of that has not yet been submitted is also for a single MAC address. I think it is silly to bother the whole IETF (or even the whole IESG) for the allocation of a single value when over ten million are available. I think it is enough just to bother the Expert. Section 2.3.2.1 mentions changes to RFC 2153. I suggest having an Updates: for that RFC. OK. In Section 3.1: o the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work), IETF Review (see previous comment about that) could be used. See previous response. In Section 4: If different policies from those above are required for such a parameter, a BCP or Standards Track RFC must be adopted updating this BCP and specifying the new policy and parameter. Standards Action could be used for this. I believe the statement is brief, clear, and unambiguous and do not see any reason to change it. In Section 5.1 I suggest using IESG Approval. BTW, IESG Ratification of an Expert Review approval recommendation looks unusual to me. I believe the provisions of Section 5.1 are fine. In the extremely rare cases (perhaps once every five years or so?) where a request would require IESG Ratification, prior review by the Expert would be beneficial so the IESG would have the benefit of the Expert's opinion before they consider the request. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Regards, -sm
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
The first part of Section 2.1 should have a sentence added like An RRTYPE code has been assigned so 48-bit MAC addresses can be stored using the DNS protocol. with an appropriate reference. A similar sentence for 64-bit MAC addresses should be added to the first part of Section 2.2. The lists of Ethertypes in Appendix B should be brought up to date. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, May 7, 2013 at 7:07 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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 2013-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
On 5/7/13 12:07 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice Sponsoring AD here, Getting feedback on the 5342bis document is important since this is the primary consensus call. Thanks Joel 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 2013-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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 2013-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 42, RFC 6895 on Domain Name System (DNS) IANA Considerations
A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 6895 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox:d3e...@gmail.com Pages: 19 Characters: 38979 Obsoletes: RFC 6195 Updates:RFC 1183, RFC 2845, RFC 2930, RFC 3597 See Also: BCP 42 I-D Tag:draft-ietf-dnsext-rfc6195bis-05.txt URL:http://www.rfc-editor.org/rfc/rfc6895.txt This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. This document is a product of the DNS Extensions 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
Protocol Action: 'Domain Name System (DNS) IANA Considerations' to Best Current Practice (draft-ietf-dnsext-rfc6195bis-05.txt)
The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations' (draft-ietf-dnsext-rfc6195bis-05.txt) as Best Current Practice This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ Technical Summary This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. Working Group Summary This document is to a large extent the same as its predecessor, but the working group has made some simplifications in process and these were not controversial. There is strong consensus behind this document. Document Quality There are many DNS implementations. This document is high quality due to reviews by a number of strong reviewers/experts including Alfred Hoenes and Mark Andrews. Personnel The document Shepherd is Olafur Gudmundsson o...@ogud.com Ralph Droms is the Responsible Area Director.
Last Call: draft-ietf-dnsext-rfc6195bis-04.txt (Domain Name System (DNS) IANA Considerations) to Best Current Practice
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations' draft-ietf-dnsext-rfc6195bis-04.txt as Best Current Practice 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 2012-10-12. 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 This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/ballot/ No IPR declarations have been submitted directly on this I-D.
BCP 164, RFC 6328 on IANA Considerations for Network Layer Protocol Identifiers
A new Request for Comments is now available in online RFC libraries. BCP 164 RFC 6328 Title: IANA Considerations for Network Layer Protocol Identifiers Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: July 2011 Mailbox:d3e...@gmail.com Pages: 9 Characters: 16123 See Also: BCP0164 I-D Tag:draft-eastlake-nlpid-iana-considerations-04.txt URL:http://www.rfc-editor.org/rfc/rfc6328.txt Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations. This memo documents an Internet Best Current Practice. 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
BCP 42, RFC 6195 on Domain Name System (DNS) IANA Considerations
A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 6195 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox:d3e...@gmail.com Pages: 17 Characters: 33790 Obsoletes: RFC5395 Updates:RFC1183, RFC3597 See Also: BCP0042 I-D Tag:draft-ietf-dnsext-5395bis-03.txt URL:http://www.rfc-editor.org/rfc/rfc6195.txt This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice. This document is a product of the DNS Extensions 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
Protocol Action: 'Domain Name System (DNS) IANA Considerations' to BCP (draft-ietf-dnsext-5395bis-03.txt)
The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations' (draft-ietf-dnsext-5395bis-03.txt) as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-5395bis/ Technical Summary This RFC obsoletes [RFC5395]; however, the only significant change is the change is the public review mailing list to dns...@ietf.org. Working Group Summary There were no comments during an abbreviated working group last call. Document Quality The only significant action in this document is to change the public review mailing list to dns...@ietf.org Personnel Olafur Gudmundsson (o...@ogud.com) is the document shepherd. Ralph Droms (rdroms.i...@gmail.com) is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Draft Review Request - IRTP IANA Considerations
11.01.2011 13:28, t.petch wrote: - Original Message - From: Mykyta Yevstifeyevevniki...@gmail.com To: Joe Touchto...@isi.edu Cc: t.petchie...@btconnect.com;go...@erg.abdn.ac.uk Sent: Tuesday, January 11, 2011 10:24 AM Joe, 2011/1/10, Joe Touchto...@isi.edu: On 1/7/2011 9:16 PM, Mykyta Yevstifeyev wrote: ... You need to explain why these protocols *need* to be moved to Historic. Such actions are typically reserved for protocols in current use that are dangerous, or protocols that are in current use that are being replaced by other protocols. Neither is the case here. There is no need to move to Historic (i.e., deprecate, within the IETF process) such protocols. See my message in IETF Discussion list. For those not on that list: - there are many others who share my view that moving experimental protocols to historic isn't useful per se, especially these protocols in particular What 'these'? See that below. - your argument appears to be the definition of Historic is incorrect Maybe a bit. It is more narrow and unclear than incorrect. Given your argument, it's difficult to appreciate why you claim it is urgent to move these protocols to a status whose definition you explicitly disagree with. What protocols? Curently I'm speaking only about one - IRTP. Joe, Yes, and that is one of the three (IRTP, NETBLT, RDP) that you raised on the ietf list under 'Old transport-layer protocols to Historic?' It was to request the discussion on topics related with all these protocols. And as Joe has accurately pointed out, the ietf list has generated a lot of responses, from names I know well and have a high regard for, almost all of which say that this is a bad idea. It is true that for NETBLT and for RDP concrete reasons have been given why this is a very bad idea; doubtless we coud find similar reasons for IRTP. As well as I know, almost all responses concerned only RDP and NETBLT, and nearly nobody said anything about IRTP. So I want to ask that now - what was IRTP developed for? Is there any real reason it may be used? Mykyta So you have proposed moving protocols to Historic and practically no-one agrees with what you say. Tom Petch Mykyta Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-5395bis-02.txt (Domain Name System (DNS) IANA Considerations) to BCP
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations' draft-ietf-dnsext-5395bis-02.txt as a BCP 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-01-05. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-5395bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-5395bis/ 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
RFC 5457 on IANA Considerations for IAX: Inter-Asterisk eXchange Version 2
A new Request for Comments is now available in online RFC libraries. RFC 5457 Title: IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 Author: E. Guy, Ed. Status: Informational Date: February 2010 Mailbox:ed...@emcsw.com Pages: 21 Characters: 50952 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-guy-iaxiana-00.txt URL:http://www.rfc-editor.org/rfc/rfc5457.txt This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is an Independent Submission. 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
Forward: RFC 5719 on Updated IANA Considerations for Diameter Command Code Allocations
Greetings All, Please note that we are resending this RFC announcement because were notified that it did not appear in the ietf-announce archives. Please note that the date of publication is January 2010. Please let us know if you have any questions. Thank you. RFC Editor/sg On Thu, Jan 07, 2010 at 04:53:27PM -0800, RFC Editor wrote: A new Request for Comments is now available in online RFC libraries. RFC 5719 Title: Updated IANA Considerations for Diameter Command Code Allocations Author: D. Romascanu, H. Tschofenig Status: Standards Track Date: January 2010 Mailbox:droma...@avaya.com, hannes.tschofe...@gmx.net Pages: 5 Characters: 11268 Updates:RFC3588 I-D Tag:draft-ietf-dime-diameter-cmd-iana-01.txt URL:http://www.rfc-editor.org/rfc/rfc5719.txt The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 5665 on IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats
Resending. - Forwarded message from rfc-edi...@rfc-editor.org - To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Subject: RFC 5665 on IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats From: rfc-edi...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, nf...@ietf.org Date: Thu, 14 Jan 2010 23:08:01 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5665 Title: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats Author: M. Eisler Status: Standards Track Date: January 2010 Mailbox:m...@eisler.com Pages: 14 Characters: 28706 Updates:RFC1833 I-D Tag:draft-ietf-nfsv4-rpc-netid-06.txt URL:http://www.rfc-editor.org/rfc/rfc5665.txt This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS TRACK] This document is a product of the Network File System Version 4 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 - End forwarded message - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IANA Considerations for Network Layer Protocol Identifiers' to BCP
The IESG has approved the following document: - 'IANA Considerations for Network Layer Protocol Identifiers ' draft-eastlake-nlpid-iana-considerations-04.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-nlpid-iana-considerations-04.txt Technical Summary Network Layer Protcol IDs (NLPIDs) are used in a number of protocols that the IETF has specified or is extending. Examples include the NBMA Next Hop Resolution Protocol and the IS-IS Protocols Supported TLV. The registry of these values is maintained by ISO/IEC. This document provides the IANA Considerations procedures for originating and documenting the allocation of an NLPID from within the IETF. Working Group Summary This document was not produced by an IETF working group but is supported by a clear consensus of the community of interest. Document Quality The document has been reviewed by the IETF TRILL and IS-IS working group chairs, the Internet and Routing ADs, the IETF Chair, the Editor of IEEE P802.1aq, IANA, the IETF Liaison to ISO/IEC JTC1 SC6, and other technical experts. Document quality is high. Personnel Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. Please add the following to the first paragraph in Section 2.3 One byte code points are assigned to TRILL and IEEE 802.1aq as they are intended for use within the IS-IS Protocols Supported TLV [RFC1195]. 2. In Section 3: OLD: As long as code points are available, IANA will allocate additional values when required by an IETF Standards Action. NEW: As long as code points are available, IANA will allocate additional values when required by applying IETF Review policy as per [RFC5226]. 3. Move [TRILL] from Informative to Normative References ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5719 on Updated IANA Considerations for Diameter Command Code Allocations
A new Request for Comments is now available in online RFC libraries. RFC 5719 Title: Updated IANA Considerations for Diameter Command Code Allocations Author: D. Romascanu, H. Tschofenig Status: Standards Track Date: January 2010 Mailbox:droma...@avaya.com, hannes.tschofe...@gmx.net Pages: 5 Characters: 11268 Updates:RFC3588 I-D Tag:draft-ietf-dime-diameter-cmd-iana-01.txt URL:http://www.rfc-editor.org/rfc/rfc5719.txt The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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
Last Call: draft-eastlake-nlpid-iana-considerations (IANA Considerations for NLPIDs) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for NLPIDs ' draft-eastlake-nlpid-iana-considerations-03.txt as a BCP 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 2009-12-16. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eastlake-nlpid-iana-considerations-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18692rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard
The IESG has approved the following document: - 'Updated IANA Considerations for Diameter Command Code Allocations ' draft-ietf-dime-diameter-cmd-iana-01.txt as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt Technical Summary The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. Working Group Summary This document is the product of the DIME working group. The extensibility rules of Diameter have been investigated by a design team and the alignment of policy for extending Diameter applications and Diameter commands has been agreed. Document Quality This document focuses on the description of the allocation policy change in the IANA consideration section and has been discussed for some time. Personnel Victor Fajardo is the document shepherd for this document. Ron Bonica is the responsible AD. RFC Editor Note Section 3 content should be modified as follows: OLD This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that fewer security reviews are conducted and hence the quality of the resulting protocol document is weaker compared to the rather extensive reviews performed in the IETF. The members of the DIME working group are aware of the tradeoff between better specification quality and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. NEW This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that security reviews are conducted in different manner and the criteria and style of the reviews are different than the reviews performed in the IETF. The members of the DIME working group are aware of the risks involved in using different security and quality review processes and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dime-diameter-cmd-iana (Updated IANA Considerations for Diameter Command Code Allocations) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Updated IANA Considerations for Diameter Command Code Allocations ' draft-ietf-dime-diameter-cmd-iana-01.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 2009-09-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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18633rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard
Hello, Section 7.1 of draft-ietf-enum-3761bis-04 is about DNS Security. One sentence caught my attention: Because of these threats, a deployed ENUM service SHOULD include mechanisms to ameliorate these threats. My reading of that is that a deployed ENUM service should include mechanisms to make these threats better. :-) I suggest using mitigate (make less severe) instead of ameliorate. Repl sub-field is used throughout the document. There could be a reference to Section 3.2 of RFC 3402 to make that clearer. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard
On Tue, 26 May 2009, The IESG wrote: - 'IANA Registration of Enumservices: Guide, Template and IANA Considerations ' draft-ietf-enum-enumservices-guide-16.txt as a Proposed Standard This is an ops-dir review. I'm only superficially familiar with ENUM, so take the comments with a grain of salt. I did not see major issues with the document, but the document could be improved by a clarifying revision. Wrt. operational considerations, given that the document deals with IANA registrations, I do not see much that should be a cause for concern. Registration documents must include a section on DNS considerations, which could possibly discuss some operational aspects as well (some of this below). Personally identifiable information has already been highlighted in the document. Management-side of OM does not appear to be relevant in this case. The usability and control of enum from users' point of view is a possible issue but that goes beyond the scope of this document. Some specific comments below: substantial --- 5.7. DNS Considerations (MANDATORY) .. I note that exampe DNS considerations mostly relate to DNS protocol. I wonder about DNS operations related considerations. For example, is the usage expected to incur a significant (quantifiable?) load on the name server chain? Are there recommendations/restrictions/assumptions wrt TTL of the records (somewhat related to the previous)? Further I assume that DNS records related to the enum services are static in such a fashion that they can be protected if needed by DNSSEC signing. Is this a correct assumption? There is no clear prohibition of defining synthetic or synthethizing DNS records that would be generated on the fly. (I'm not sure if this would even be interesting to someone...) semi-editorial -- This document specifies a revision of the IANA Registry for Enumservices, which was originally described in [RFC3761]. This document obsoletes Section 3 of RFC 3761. .. yet in the header it says Obsoletes: 3761. What about the rest of 3761? I'd say it's best that the whole 3761 gets obsoleted in some manner. The IETF's ENUM Working Group has encountered an unnecessary amount of variation in the format of Enumservice Specifications. The ENUM Working Group's view of what particular information is required and/or recommended has also evolved, and capturing these best current practices is helpful in both the creation of new Enumservice Specifications, as well as the revision or refinement of existing Enumservice Specifications. .. yet the revision of existing Enumservices Specification is only touched upon in Section 8, which says doing the revision is a MAY. Is this sufficient? (After reading the whole doc, it appears that there is an effort in progress to revise these, but it is not clear if that process is exhaustive.) In Section 9, you describe extension of existing enumservices. If an enum service is extended, does the extended version need to comply with this document (Section 8 could be read to imply that but this is not 100% clear)? Types and Subtypes MUST conform to the ABNF specified in [I-D.ietf-enum-3761bis]. The ABNF specified in [I-D.ietf-enum-3761bis] allows the - (dash) character for Types and Subtypes . .. when I search for ABNF in I-D.ietf-enum-3761bis, I come up with one hit, and it seems to be in an irrelevant spot. I'm not sure if ABNF is defined clearly enough in I-D.ietf-enum-3761bis (and that document could be improved); in addition, given this is not very clear, I'd suggest a more specific reference in this document (e.g. pointing to specific sections of 3761bis one should conform to). 6.5.3. Outcome 3: Experts Reject the Registration Document The expert might reject the Registration, which means the Expert Review Process is discontinued. For appeals, see Section 7.3. .. I'm not sure in which case the result might be a rejection instead of changes needed, but should you also point to some other recourse other than the appeals process? For example, Go back to step 1 and reconsider whether a registration is needed. :-) 7.2. Review Guidelines .. one of the things that could perhaps be explicitly listed here is verifying that the type name does not conflict with any well-known other name (e.g. the example given in the document where imap was proposed for internet mapping service). 11.1.4.2. Published as generic Specification .. in S 11.1.2 you require IANA to escrow the specification, so I guess it should be stated in the required IANA steps in the last paragraph of this section as well. 13.1. Normative References [RFC2223] Postel, J. and J. Reynolds, Instructions to RFC Authors, RFC 2223, October 1997. .. this is a down-ref problem: BCP referring to an informational document. Is this critical for understanding this document? If not, it could be moved to an informative reference. editorial
Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard
The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'IANA Registration of Enumservices: Guide, Template and IANA Considerations ' draft-ietf-enum-enumservices-guide-16.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 2009-06-09. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14322rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5513 on IANA Considerations for Three Letter Acronyms
A new Request for Comments is now available in online RFC libraries. RFC 5513 Title: IANA Considerations for Three Letter Acronyms Author: A. Farrel Status: Informational Date: 1 April 2009 Mailbox:adr...@olddog.co.uk Pages: 7 Characters: 13931 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-farrel-iana-tla-registry-00.txt URL:http://www.rfc-editor.org/rfc/rfc5513.txt Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors. Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community. 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IANA Considerations for RPC Net Identifiers and Universal Address Formats' to Proposed Standard
The IESG has approved the following document: - 'IANA Considerations for RPC Net Identifiers and Universal Address Formats ' draft-ietf-nfsv4-rpc-netid-06.txt as a Proposed Standard This document is the product of the Network File System Version 4 Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpc-netid-06.txt Technical Summary This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. Working Group Summary In support of the RDMA Transport for ONC RPC Internet Draft and other users of ONC RPC based protocols, registries of netids and universal network addresses are described and the procedure established for future registration. This is a step forward in the support of varying transport types and protocol extensions. Document Quality This document captures current registrations and allows for equitable future extension such that established implementations are protected in an environment of integrating new transport types. Personnel Spencer Shepler (shep...@storspeed.com) is the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. RFC Editor Note Please make the following replacements to the document references: RFC1831 - draft-ietf-nfsv4-rfc1831bis ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 42, RFC 5395 on Domain Name System (DNS) IANA Considerations
A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 5395 Title: Domain Name System (DNS) IANA Considerations Author: D. Eastlake 3rd Status: Best Current Practice Date: November 2008 Mailbox:[EMAIL PROTECTED] Pages: 17 Characters: 33725 Obsoletes: RFC2929 Updates:RFC1183, RFC3597 See Also: BCP0042 I-D Tag:draft-ietf-dnsext-2929bis-07.txt URL:http://www.rfc-editor.org/rfc/rfc5395.txt Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the DNS Extensions 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-nfsv4-rpc-netid (IANA Considerations for RPC Net Identifiers and Universal Address Formats) to Proposed Standard
The IESG has received a request from the Network File System Version 4 WG (nfsv4) to consider the following document: - 'IANA Considerations for RPC Net Identifiers and Universal Address Formats ' draft-ietf-nfsv4-rpc-netid-03.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 [EMAIL PROTECTED] mailing lists by 2008-12-5. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpc-netid-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17646rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Domain Name System (DNS) IANA Considerations' to BCP
The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-07.txt as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-07.txt - Technical Summary The document updates rules for how certain DNS parameter values are allocated. In most cases this is a relaxation of the existing rules. The document is giving guidance to IANA on policies for allocation. The DNS community wants to simplify the rules for allocation of new RR types, and this document combined with the rules in RFC3597 makes this possible. For RR types that fit within the rules a simple template and review by WG and a designated expert is the new process. Most other changes from RFC2929 are insignificant. - Working Group Summary There is a broad consensus that this document is an improvement over its predecessor. - Protocol Quality This is document about IETF/IANA process so there are no implementations. The working group and sponsoring AD are running an experiment of the new RR type process concurrently with the publication request. see: http://psg.com/lists/namedroppers/namedroppers.2006/msg01601.html http://psg.com/lists/namedroppers/namedroppers.2006/msg01603.html http://psg.com/lists/namedroppers/namedroppers.2007/msg00068.html http://psg.com/lists/namedroppers/namedroppers.2007/msg00070.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5350 on IANA Considerations for the IPv4 and IPv6 Router Alert Options
A new Request for Comments is now available in online RFC libraries. RFC 5350 Title: IANA Considerations for the IPv4 and IPv6 Router Alert Options Author: J. Manner, A. McDonald Status: Standards Track Date: September 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 8 Characters: 17812 Updates:RFC2113, RFC3175 I-D Tag:draft-manner-router-alert-iana-03.txt URL:http://www.rfc-editor.org/rfc/rfc5350.txt This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 141, RFC 5342 on IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters
A new Request for Comments is now available in online RFC libraries. BCP 141 RFC 5342 Title: IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters Author: D. Eastlake 3rd. Status: Best Current Practice Date: September 2009 Mailbox:[EMAIL PROTECTED] Pages: 21 Characters: 42800 Updates:RFC2153 See Also: BCP0141 I-D Tag:draft-eastlake-ethernet-iana-considerations-08.txt URL:http://www.rfc-editor.org/rfc/rfc5342.txt Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IANA Considerations for the IPv4 and IPv6 Router Alert Option' to Proposed Standard
The IESG has approved the following document: - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option ' draft-manner-router-alert-iana-03.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manner-router-alert-iana-03.txt Technical Summary This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. It will also deprecate one of the values in the current IPv6 registry that seems to have been made in an error in RFC 3175. Working Group Summary This was discussed on the INTAREA list. Questions to possible implementation effects were posted to 6MAN; from what we know today this will not affect implementations negatively. Document Quality The document has been reviewed extensively. Personnel There is no document shepherd. Jari Arkko is the sponsoring AD. RFC Editor Note Please move [IANA-IPv6RAO] to be an informative reference. Section 1., paragraph 4: This document proposes updates to the IANA registry for managing IPv4 and IPv6 Router Alert Option Values, and proposes to remove one s/proposes updates to/updates/ s/proposes to remove/removes/ Section 3., paragraph 1: This section contains the proposed new procedures for managing IPv4 s/proposed// Section 3., paragraph 3: This should not change, as there has been seen little s/This should not change/This document does not change this/ s/has been seen/is/ Section 3.2., paragraph 1: The registry for IPv6 Router Alert Option Values should continue to s/should continue/continues/ Section 3.2., paragraph 2: In addition, the following value should be removed from the IANA s/should be removed/are removed/ Section 3.2., paragraph 5: The following IPv6 RAO values should be made available for s/should be made/are made/ OLD: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175]| | | [RFC3175] | | NEW: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175](*) | | | [RFC3175] | | OLD: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). NEW: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). Similarly, value 3 is duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value 1 assigned. Also note that nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Got it, thanks. Jukka On Thu, 14 Aug 2008, Jari Arkko wrote: Jukka, Both registries will use 32 values for the aggregation levels. For IPv6 RAO, value 3 is removed but value 35 is kept. Thus, IPv6 will have values 4-35 (=32 values) for the 32 levels. OK We can make this more clear, yet, I already answered a question from IANA about this a couple of weeks ago, so they are aware of how the registry should be changed. Which is good, but I was hoping the RFC itself would also be clear on this. How about this: OLD: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175]| | | [RFC3175] | | NEW: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175](*) | | | [RFC3175] | | OLD: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). NEW: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). Similarly, value 3 is duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value 1 assigned. Also note that nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Kre, authors, First (last sentence of section 2): It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). isn't the kind of sentence that belongs in a doc like this. If the authors are mystified, just omit the sentence, including it adds nothing. Better, of course, would be to ask, and discover, and provide an explanation. But, this doc deletes aggregation level 0 from IPv6 anyway, which makes all of this even stranger. There has been an effort to determine why the values do not match and why there's 33 instead of 32 values. We still do not know. I think it is valuable to point out problems (like the 33 values) and the fact that implementations have to use different values for v4 and v6. However, your question about level 0 deletion prompts me to ask the authors: given that you are doing this, does this restore both the alignment to both using the range 1-32 and exactly 32 values? Does that mean that in IPv6 the value 35 (3+32) is used? If yes, maybe that should be clearer from the doc. Or is the intent that IPv6 will use 1-31? Second (section 4, security considerations): It has been a long standing practice that we allocate experimental code points for different protocol fields. I agree that the security considerations section is largely about common sense. I do not necessarily agree that the considerations can be removed, however. The fact of the matter is that experiments can collide and it may even be possible that some equipment has interesting failure modes when it sees previously untested values. Worth the two paragraphs? I'd rather err on the side of stating the obvious. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Hi, About cutting most of the Security Considerations section, I don't personally have a preference, either is fine. Yet, I tend to agree with Jari that stating the obvious isn't such a big problem, it just reminds people that there are issues to consider. (Whether the use of an arbitrary RAO value kills routers, I don't know - if we ask router manufacturers surely they will not tell us. ;) ) Both registries will use 32 values for the aggregation levels. For IPv6 RAO, value 3 is removed but value 35 is kept. Thus, IPv6 will have values 4-35 (=32 values) for the 32 levels. We can make this more clear, yet, I already answered a question from IANA about this a couple of weeks ago, so they are aware of how the registry should be changed. Jukka Jari Arkko wrote: Kre, authors, First (last sentence of section 2): It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). isn't the kind of sentence that belongs in a doc like this. If the authors are mystified, just omit the sentence, including it adds nothing. Better, of course, would be to ask, and discover, and provide an explanation. But, this doc deletes aggregation level 0 from IPv6 anyway, which makes all of this even stranger. There has been an effort to determine why the values do not match and why there's 33 instead of 32 values. We still do not know. I think it is valuable to point out problems (like the 33 values) and the fact that implementations have to use different values for v4 and v6. However, your question about level 0 deletion prompts me to ask the authors: given that you are doing this, does this restore both the alignment to both using the range 1-32 and exactly 32 values? Does that mean that in IPv6 the value 35 (3+32) is used? If yes, maybe that should be clearer from the doc. Or is the intent that IPv6 will use 1-31? Second (section 4, security considerations): It has been a long standing practice that we allocate experimental code points for different protocol fields. I agree that the security considerations section is largely about common sense. I do not necessarily agree that the considerations can be removed, however. The fact of the matter is that experiments can collide and it may even be possible that some equipment has interesting failure modes when it sees previously untested values. Worth the two paragraphs? I'd rather err on the side of stating the obvious. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Jukka, Both registries will use 32 values for the aggregation levels. For IPv6 RAO, value 3 is removed but value 35 is kept. Thus, IPv6 will have values 4-35 (=32 values) for the 32 levels. OK We can make this more clear, yet, I already answered a question from IANA about this a couple of weeks ago, so they are aware of how the registry should be changed. Which is good, but I was hoping the RFC itself would also be clear on this. How about this: OLD: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175]| | | [RFC3175] | | NEW: | 3| Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175](*) | | | [RFC3175] | | OLD: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). NEW: Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and that is consequently reflected in the IANA registry. In that document the values 3-35 (i.e. 33 values) are defined for nesting levels 0-31 (i.e. 32 levels). Similarly, value 3 is duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value 1 assigned. Also note that nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters' to BCP
The IESG has approved the following document: - 'IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters ' draft-eastlake-ethernet-iana-considerations-08.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-ethernet-iana-considerations-08.txt Technical Summary Some IETF protocols make use of Ethernet frame formats and IEEE 802.1 parameters. This document discusses some uses of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). Working Group Summary The document is an individual submission. Document Quality The document secifies IANA considerations for the allocation of IEEE 802 parameters, based on current practices and past experience. The document was reviewed by several experts in the IETF and the IEEE including Geoff Thompson, Scott Bradner, Charlie Kauffman, Alfred Hoenes, Bob Hinden, Eric Gray, Ian Calder, Mark Townsley and their comments were reflected in the final version of the document. Personnel Eric Nordmark is the protocol shepherd. Dan Romascanu is the sponsoring Area Director. RFC Editor Note Please make the following change in Section 5.1 OLD: however, if the Expert believes the application should be approved or they are uncertain and believes that the circumstances warrant the attention of the IESG, the Expert will forward the application, together with their reasons for approval or uncertainty, to the IESG, which must approve for the allocation to be granted. This can be accomplished by a management item in an IESG telechat. NEW: however, if the Expert believes the application should be approved or they are uncertain and believes that the circumstances warrant the attention of the IESG, the Expert will inform IANA about their advice and IANA will forward the application, together with the reasons for approval or uncertainty, to the IESG, which must approve for the allocation to be granted. This can be accomplished by a management item in an IESG telechat as done for other types of requests. IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
Date:Wed, 9 Jul 2008 09:41:03 -0700 (PDT) From:The IESG [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | The IESG has received a request from an individual submitter to consider | the following document: | | - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option ' |draft-manner-router-alert-iana-03.txt as a Proposed Standard Two comments. First (last sentence of section 2): It is unclear why nesting levels begin at 1 for IPv4 (described in section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of [RFC3175]). isn't the kind of sentence that belongs in a doc like this. If the authors are mystified, just omit the sentence, including it adds nothing. Better, of course, would be to ask, and discover, and provide an explanation. But, this doc deletes aggregation level 0 from IPv6 anyway, which makes all of this even stranger. Second (section 4, security considerations): Yet, as discussed in RFC 4727 [RFC4727] production networks do not necessarily support the use of experimental code points in IP option headers. The network scope of support for experimental values should carefully be evaluated before deploying any experimental RAO value [...] This is the kind of thing we might have expected to see in a security considerations section 15-20 years ago, when the network was a nice kind friendly environment, where all the players would take great care not to do anything that might cause a problem. These days, if the use of unsupported experimental code points has the potential to disrupt the stable operation of the network then that would be something worthy of a CERT advisory and hasty code fixes by whatever vendors are supplying the systems that would be disrupted. It is never safe to assume that any random value won't appear in any random field of a packet, and for just the same reason, there's no reason for anyone to avoid using any particular value. This security consideration paragraph should simply be deleted. The following one is more just common sense, wrt general management, and also exposes no security issues, and should probably be deleted as well. All of this (except the first paragraph which is fine) smells very much like an attempt to provide some meaningful security considerations section just because meaningful security considerations sections are required (by someone, for something) even where it's absurd to imagine any security issues that can really apply. If real security considerations were to be discussed in a doc that just establishes an IANA registry, and does no more than that (doesn't create new values with meanings that didn't already exist, etc) then about all that could be really said would be abut spoofing messages to IANA causing bogus values to be allocated, and/or adequately protecting the registry content so it is known that what is observed there is in fact correct - but none of that is really worth having in every RFC that happens to create a new IANA object. Personally I'd prefer to simply see the meaningless security considerations section removed completely from this doc (but of course, there's a rule that says it must always be present, even when it is stupid, and obeying the rules is, of course, far more important than producing quality documents...) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
On Thu, Jul 10, 2008 at 12:08 PM, Robert Elz [EMAIL PROTECTED] wrote: This is the kind of thing we might have expected to see in a security considerations section 15-20 years ago, when the network was a nice kind friendly environment, where all the players would take great care not to do anything that might cause a problem. Those days are long gone. Unfortunately were stuck with that infrastructure. Its good infrastructure - but not well policed - and insecure as hell because too many people built a system that assumed trust was the default value. These days, if the use of unsupported experimental code points has the potential to disrupt the stable operation of the network then that would be something worthy of a CERT advisory and hasty code fixes by whatever vendors are supplying the systems that would be disrupted. Ya - I hear you - but this way its a good way to sell DNSSEC and put Verisign in charge of the DNS keys. No thank you. But its worth watching what happens. (but of course, there's a rule that says it must always be present, even when it is stupid, and obeying the rules is, of course, far more important than producing quality documents...) Yes - we are only human. Rules are good. That does not mean rules can not be questioned. And changes made by consensus. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option ' draft-manner-router-alert-iana-03.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 [EMAIL PROTECTED] mailing lists by 2008-08-06. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-manner-router-alert-iana-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16448rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 26, RFC 5226 on Guidelines for Writing an IANA Considerations Section in RFCs
A new Request for Comments is now available in online RFC libraries. BCP 26 RFC 5226 Title: Guidelines for Writing an IANA Considerations Section in RFCs Author: T. Narten, H. Alvestrand Status: Best Current Practice Date: May 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 27 Characters: 66160 Obsoletes: RFC2434 See Also: BCP0026 I-D Tag:draft-narten-iana-considerations-rfc2434bis-09.txt URL:http://www.rfc-editor.org/rfc/rfc5226.txt Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Guidelines for Writing an IANA Considerations Section in RFCs' to BCP
The IESG has approved the following document: - 'Guidelines for Writing an IANA Considerations Section in RFCs ' draft-narten-iana-considerations-rfc2434bis-09.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-09.txt Technical Summary Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. Working Group Summary This document is not the product of any IETF Working Group. Protocol Quality This document will obsolete RFC 2434 once it is approved. It incorporates lessons learned from using RFC 2434 for many years. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor The final word of the first paragraph on page 8 is missing. Please add the missing word as follows: OLD: responsibility of the pool's chair to resolve the issue and provide IANA with clear NEW: responsibility of the pool's chair to resolve the issue and provide IANA with clear instructions. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html While it may well the be case that MOST of the changes resulted from the experiment and were called out to the WG, the change I cited (re: creating IANA registries using templates) was neither a result of the experiment (having been made before the experiment), nor called out. As for the WG being fully aware of the changes resulting from the experiment, I note that between the end of WGLC in November 2006 and the start of IETF last call a year later (which included the time of the experiment), the namedroppers list appears to have seen fourteen posts about 2929bis. The post-experiment discussion of these changes was minimal at best. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I'm glad you agree that it is an excellent question. I suspect it's one of the things IANA plans to weigh in on. -- Sam ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-eastlake-ethernet-iana-considerations (IANA Ethernet Considerations) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Ethernet Considerations ' draft-eastlake-ethernet-iana-considerations-05.txt as a BCP 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 [EMAIL PROTECTED] mailing lists by 2008-01-30. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eastlake-ethernet-iana-considerations-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16252rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
At 11:50 04/12/2007, Sam Weiler wrote: This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. Yes this is an oversight on the editors part and mine as well, sorry. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. I hope there are not any more skeletons in the closet :-) On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. good. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam Olafur ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
Hi Sam, It appears that, somehow, I overlooked message [2] below when I was editing the document. Thanks for catching that. I'd be happy to make the two changes agreed to: changing who to whose in one case (an error a couple of other people have noticed) and changing IETF Consensus to IETF Review. I believe that other changes you suggested were found by the WG Chair not to have WG consensus. Thanks, Donald -Original Message- From: Sam Weiler [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 04, 2007 11:51 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
Hi, Thanks for your comment on 2929bis. See response below at @@@ -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 5:08 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG [EMAIL PROTECTED] wrote a message of 24 lines which said: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from IETF consensus to the new DNS RRTYPE Allocation Policy in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: a Meta-Type who processing is optional, I believe it should be whose processing). @@@ Thanks for finding this typo. But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), @@@ I do not see any reason to provide for extension of consideration or mid-stream modification to applications. The Expert is required by 2929bis to monitor namedroppers discussion of applications for an RR Type and applicants are encouraged by 2929bis to informally post applications to get feedback. So the applicant should normally have early feedback from the Expert. In cases where the formal application is rejected and the Expert provides suggested changes, it seems simpler and cleaner for the applicant to resubmit, rather than modify. This also fits with the DNSEXT WG consensus that the namedroppers community have three weeks to examine any application, to reduce the chance of someone missing something because they are on vacation or the like, rather than the more common IETF posting requirement of two weeks (which is used in 4646bis). @@@ I personally don't see why someone would think there is a time extension or mid-stream change facility for 2929bis when none is provided in the document; but I don't object to adding a few words to make this clear. * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, @@@ This is probably a good point. The addition of a specific requirement for the assigned Expert to post an acceptance or rejection (presumably to IANA, namedroppers, and the applicant) within a reasonable period of time, such as six weeks from the formal posting of the completed template to namedroppers, seems reasonable to me. * appeals to the IESG @@@ I see no need to include this. 2929bis normatively references RFC 2434 which says: @@@Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. May be such wording should appear in draft-ietf-dnsext-2929bis? @@@ How about adding the following to Section 3.1.1? @@@ After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. @@@ Thanks again, @@@ Donald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
On Thu, Nov 29, 2007 at 04:16:19PM -0500, Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote a message of 103 lines which said: How about adding the following to Section 3.1.1? After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. It seems fine to me. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG [EMAIL PROTECTED] wrote a message of 24 lines which said: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from IETF consensus to the new DNS RRTYPE Allocation Policy in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: a Meta-Type who processing is optional, I believe it should be whose processing). But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, * appeals to the IESG May be such wording should appear in draft-ietf-dnsext-2929bis? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP 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 [EMAIL PROTECTED] mailing lists by 2007-12-03. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13373rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-narten-iana-considerations-rfc2434bis (Guidelines for Writing an IANA Considerations Section in RFCs) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Guidelines for Writing an IANA Considerations Section in RFCs' draft-narten-iana-considerations-rfc2434bis-07.txt as a BCP 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 [EMAIL PROTECTED] mailing lists by 2007-08-17. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12190rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
BCP 130, RFC 4940 on IANA Considerations for OSPF
A new Request for Comments is now available in online RFC libraries. BCP 130 RFC 4940 Title: IANA Considerations for OSPF Author: K. Kompella, B. Fenner Status: Best Current Practice Date: July 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 27595 Updates: See-Also: BCP0130 I-D Tag:draft-ietf-ospf-iana-03.txt URL:http://www.rfc-editor.org/rfc/rfc4940.txt This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4937 on IANA Considerations for PPP over Ethernet (PPPoE)
A new Request for Comments is now available in online RFC libraries. RFC 4937 Title: IANA Considerations for PPP over Ethernet (PPPoE) Author: P. Arberg, V. Mammoliti Status: Informational Date: June 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 11070 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-arberg-pppoe-iana-03.txt URL:http://www.rfc-editor.org/rfc/rfc4937.txt This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IANA considerations concerns -- specific cases?
All, The ongoing thread has asked some pretty fundamental questions about how we deal with allocations. Many opinions have been expressed. The general discussion is one thing, but I also wanted to make an offer regarding specific cases where people feel that the current IANA rules for a specific number space are obviously wrong, need room for experimentation, etc. We frequently run into such cases. If you have trouble with a specific number space, I would be happy to be the sponsoring AD for a document that fixes that issue. (Or help you find another AD whose area it belongs, point you to an existing WG that could handle it, or help you find a willing author to write the document, whatever is most suitable for the case at hand.) Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA considerations and IETF Consensus
I also have the experience that a too strict policy can be harmful. I could cite numerous examples... On the other hand, Thomas and Pasi are also right that too loose policy can be harmful. You have to remember that interoperability can be hurt or improved in many ways. Secret code allocations, private specifications, etc. are indeed a problem. But so are incompatible extensions, multiple ways of doing the same thing, etc. My experience of the current number system is that it is actually working fairly well. There are exceptions, but by and large numbers are allocated and used as they should be. I know we do not have the IEPF (Internet Engineering Police Force) to send when someone uses a number against our approved RFCs, but at least in my experience in Internet layer matters such allocations are relatively rare. I would be interested in actual data about this, if anyone has some, however. I would like to see a model that has an appropriate level of strictness... and I have a model in mind. I do not like the idea of wholesale redefinition of who can allocate numbers or what the various RFC 2434 phrases mean. The different number spaces are different, and we need to apply different criteria for allocations in them. For instance, its a completely different thing to create new optional-to-recognize data attributes than new message types; IP protocol numbers are a scarce resource whereas some other resources are not, etc. And, appropriately, authors and working groups have been laying out the rules in the IANA Considerations section for years and years about what allocation policies are right. I think we need to respect the wisdom of the WG to decide on a policy issue in their protocol. We should continue to give the power to the working groups on this issue. At the same we need to recognize that we've made mistakes in this space in the past, either in the WGs or through IESG or AD requirements. In many cases, policies have been too strict. In some cases they have been not defined well enough to actually work. In yet other cases they have been too loose. Or silly, such as the policy in RFC 2780 about IPv4 protocol number allocations involving NDAs. So here's my proposal: 1) Design new protocols in a way that mere field size is not an issue. I think we've been mostly doing this since mid-90s. 2) Make sure WGs think hard about the various interoperability tradeoffs and other issues when they write their IANA considerations sections. 3) Involve the WG chairs and ADs in following what is happening in the real world, and to take action if what is deployed out there starts to differ too much from what either the IANA registry or the IETF RFCs describe. For instance, we had this situation in EAP WG a couple of years ago, and started a program to make sure all EAP methods were in the IANA table and described in RFCs, created a new WG, AD sponsored some specifications, offered reviewers and IESG support if people took their specifications to the RFC Editor, etc. 4) Make sure there is ample space for experimentation and research. Often there isn't. Consider publishing an update to make this happen. We did this for many IP layer numbers in RFC 4727, for instance. 5) Add sufficient mechanisms for vendor-specific or private numbers. 6) Periodically review the existing IANA rules for your protocols and consider revising them for the right balance. Again, all-strict and free-for-all are probably the wrong policies; different numbers need different treatment. Getting the balance right may not always be easy, but its worthwhile. Taking another example from EAP, we went from free-for-all to no-allocations-until- wg-revises-base-spec to expert-review in the EAP method space. The expert review model has worked well for this particular purposes, because it does not block allocation or make unreasonable requests, but it does ensure there's documentation about the method and that the documentation answers the right questions. 7) Keep relatively strict rules on number spaces that are scarce. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IANA considerations and IETF Consensus
At 5:22 PM +0200 6/12/07, Brian E Carpenter wrote: I'm not sure whether I agree with your proposal or not, but I think the most concrete way forward would be a proposal for specific wording for draft-narten-iana-considerations-rfc2434bis, which Harald left on my plate and I left for Russ. This goes beyond just rewording the IANA Considerations document. It requires WGs to actually understand the interoperability issues John brings up. There are plenty of places where a WG has required IETF Consensus where RFC published would be just fine, but they chose IETF Consensus because it sounded better and this related WG just used it in their spec so we should too. It would be great if WGs would start looking at the IANA registry as something that will promote interoperability of their specs, not as an enforcement mechanism for controlling extensions (except where the protocol was mis-designed to have too small of a namespace for robust extensibility). --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA considerations and IETF Consensus
At 12:25 PM -0700 6/12/07, Thomas Narten wrote: Some general comments on this thread. I understand the argument that some make that we should just give out code points in all cases, because otherwise we invite squatting. That is one reason to give out code points liberally, but not the only one. The reason that both John Klensin and I gave (and I think Dave Crocker echoed) is that giving out code points liberally increases interoperability. It gives developers stronger confidence that the registry is both correct (no overlapping values due to registration race conditions gated on RFC publication) and complete (no squatting). On the other hand, I do believe that withholding code points does prevent (in some, but not all cases) use of extensions that are potentially problematical. As one concrete example, other SDOs are generally hesitant to endorse/use protocols that have not been properly granted code points. This has been a carrot/stick in the past to get those SDOs to come to the IETF with the work rather than just having them embrace and extend our protocols. Doing so inherently causes lack of interoperability during the carrot-stick dance, and often for a long time after the dance is over. That probably helps the IETF leadership but hurts developers of our protocols. Do you think this is not useful/necessary or that it can be done in other ways? It is probably not necessary but it is probalby useful nonetheless. A different way to achieve the carrot-stick goal might be to use the registry to list the IETF's perceived soundness of the codepoint's registration. Stanards-track RFC, Informational RFC, Outside spec; see URL, Outside spec; believed to be unstable by the IESG on mm/dd/yy, Outside spec; believed to have serious technical issues; see http://www.iesg.org/comments/, and so on. Also, if one thinks that code points should just be given out in all cases, how do we deal with stuff like RFC 3427? That's a straw-man; no one on this thread said in all cases. There are at least two cases where liberal registration are not good: - A limited-size namespace (usually protocols written pre-1995) - A namespace where the names have significant semantic value (microsoft, better-auth, ...) And, does this also mean, for example, that anyone should be granted ICMP code points? Are you really calling for essentially granting code points to anyone who asks? No. In order to achieve interoperability, stable documentation of the definition of the codepoint should always be required. Additional commentary from the IESG and/or IAB might also be useful. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'IANA Considerations for OSPF' to BCP
The IESG has approved the following document: - 'IANA Considerations for OSPF ' draft-ietf-ospf-iana-03.txt as a BCP This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-iana-03.txt Technical Summary This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. Working Group Summary The WG Last Call raised no issues with this document. Protocol Quality Bill Fenner has reviewed the spec for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IANA Considerations for PPP over Ethernet (PPPoE)' to Informational RFC
The IESG has approved the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-03.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-03.txt Technical Summary This document provides for an IANA registry of PPPoE TAG and Code fields. Known existing usages are reserved, and a first come first served policy is established for future codes. Working Group Summary The PPPEXT working group reviewed the document and there are no known concerns with the work. PPPoE itself is not a standard protocol (L2TP and DHCP are standards-track alternatives), and future extensions are thus not encouraged. However, the new registry will help prevent possible conflicts that may develop before the standards-based solutions are adopted by PPPoE users. Protocol Quality This document does not specify any protocol. The registry established reflects current practice within the community. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Considerations for OSPF' to BCP (draft-ietf-ospf-iana)
The IESG has received a request from the Open Shortest Path First IGP WG to consider the following document: - 'IANA Considerations for OSPF ' draft-ietf-ospf-iana-01.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-iana-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
BCP 64 RFC 4520 on Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)
A new Request for Comments is now available in online RFC libraries. BCP 64 RFC 4520 Title: Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) Author: K. Zeilenga Status: Best Current Practice Date: June 2006 Mailbox:[EMAIL PROTECTED] Pages: 19 Characters: 34298 I-D Tag:draft-ietf-ldapbis-bcp64-07.txt URL:http://www.rfc-editor.org/rfc/rfc4520.txt This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the LDAP (v3) Revision Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Considerations for PPP over Ethernet (PPPoE)' to BCP (draft-arberg-pppoe-iana)
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-01.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Considerations for LDAP' to BCP
The IESG has received a request from the LDAP (v3) Revision WG to consider the following document: - 'IANA Considerations for LDAP ' draft-ietf-ldapbis-bcp64-05.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-bcp64-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
Paul, That seems like the most resonable approach to me. Are current requests archived now? John -- original message -- Subject:Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt From: Paul Hoffman [EMAIL PROTECTED] Date: 07/22/2005 11:03 pm At 3:51 PM -0400 7/22/05, Bill Sommerfeld wrote: On Fri, 2005-07-22 at 07:35, Sam Hartman wrote: BTW, this conversation and a side conversation with John has convinced me that IESG review should involve a call for comments phase. A call for comments requires having something for the community to comment on. Will an internet draft will be required from folks seeking IESG review of a proposed assignment, or will we invent yet another mechanism for circulating a description of the proposal to the community? It would make sense for the IESG to send to the community what was sent to them; that way, we can judge what they are judging. If it was a pointer to an Internet Draft, great; a pointer to some other document(s) works just as well. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
--On fredag, juli 22, 2005 00:27:25 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Sam, I would think that the purpose of a Last Call as part of IESG review would primarily be not to evaluate success or failure, but to be sure that the IESG has an opportunity to hear, from the community, about issues of which the IESG members might not be aware. Then I don't think it's a Last Call in the normal sense. It's what we might whimsically call a Request For Comments. Seriously, we could call it a Call for Comments. The IAB has a tradition of issuing impending publication notices on their architectural guidance documents. The resulting document is still labelled an IAB document, not an IETF consensus document, but I think the process improves the output (You'd have to ask the IAB what they think about the resulting feedback, however). If something works - copy it :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
BTW, this conversation and a side conversation with John has convinced me that IESG review should involve a call for comments phase. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
On Fri, 2005-07-22 at 07:35, Sam Hartman wrote: BTW, this conversation and a side conversation with John has convinced me that IESG review should involve a call for comments phase. A call for comments requires having something for the community to comment on. Will an internet draft will be required from folks seeking IESG review of a proposed assignment, or will we invent yet another mechanism for circulating a description of the proposal to the community? - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
At 3:51 PM -0400 7/22/05, Bill Sommerfeld wrote: On Fri, 2005-07-22 at 07:35, Sam Hartman wrote: BTW, this conversation and a side conversation with John has convinced me that IESG review should involve a call for comments phase. A call for comments requires having something for the community to comment on. Will an internet draft will be required from folks seeking IESG review of a proposed assignment, or will we invent yet another mechanism for circulating a description of the proposal to the community? It would make sense for the IESG to send to the community what was sent to them; that way, we can judge what they are judging. If it was a pointer to an Internet Draft, great; a pointer to some other document(s) works just as well. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
John == John C Klensin [EMAIL PROTECTED] writes: John --On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman John [EMAIL PROTECTED] wrote: No, I was not intending to imply IESG review would gain a last call. I was only speaking to IETF review. I don't think IESG review gaining a last call is all that benefical. It's not clear how you would interpret the results or what the success/failure criteria is. I think interpreting IESG review last calls would be significantly more difficult than IETF review last calls. We have a lot of experience publishing documents and even dealing with last calls on documents that end up generating a lot of messages. But IESG review would be different enough that it would be highly problematic. John Sam, I would think that the purpose of a Last Call as part John of IESG review would primarily be not to evaluate success or John failure, but to be sure that the IESG has an opportunity to John hear, from the community, about issues of which the IESG John members might not be aware. I hope I can say this without John sound insulting, because insult is certainly not my intent-- John but having the IESG make a decision after soliciting John comments from the community is a safer situation and process John than having the IESG members talk only with each other or John people whom they pick, and then decide. As I'm sure you John will agree, no one around here is omniscient; the way we get John quality decisions is to get input from as broad a population John as possible. I think you have convinced me that a last call for IESg review is valuable provided that we understand it is one way to seek input. Instead, I recommend viewing IESG review as a short circuit process that can be used when a request successfully convinces the IESG that it should be approved. I think it is important that IETF review always exist as an alternative when IESG review is available. If your IESG review is not sufficiently convincing, then you can either pursue IETF review or drop the proposal depending on whether you found the IESG's arguments convincing. John Right. And that is another key point, IMO: the main point John of IESG review is to have a fairly quick, low-impact process John for registrations that can be approved. If the IESG John concludes that, for any reason, it cannot approve a John particular request, then that request should --at the option John of the requester-- be taken up with the community, through John an IETF process Agreed. John and without any prejudice from the IESG John review. If you mean that the IESG should treat the process fairly, I agree. If you mean that the IESG should not express an opinion I disagree. John Put differently, if the IESG is asked to look at John these things, you should, IMO, ask the community for comment John and then decide either yes, register or decline to make a John decision on the community's behalf. No, go away, Agreed. John and John even no, and we recommend that you go away and not pursue John this should not be options unless there really is evidence John of community consensus. Strongly disagreed. If you do choose to have a last call for IESG review, you need to have some text explaining what the IESG is evaluating and how the IESG should balance its own opinion against comments made in the last call. John I hope that issue is reasonably well covered in John draft-klensin-iana-reg-policy-01.txt. If it is not, I guess John I've got another rev in my future. I do not believe that John document is incompatible with the rfc2434bis document, just John that each raises some issues that should inform the other. John The iana-reg-policy doc is also intended to contain some key John details, such as a discussion of evaluation criteria, that John the other document omits. I agree that your draft addresses most of these issues. It happens to do so in a manner I believe I disagree with and hope to convince the community is at least significantly wrong. However I do agree that if the community approves of your draft, it would establish the criteria I'm asking for. Next week before getting on the plane I have catching up on newtrk and reading your document scheduled. I will make detailed comments. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
--On Thursday, 21 July, 2005 13:59 -0400 Sam Hartman [EMAIL PROTECTED] wrote: John and without any prejudice from the IESG John review. If you mean that the IESG should treat the process fairly, I agree. If you mean that the IESG should not express an opinion I disagree. I am not opposed to the IESG expressing opinions. However, I think the IESG needs to be _extremely_ careful --both internally and in public-- to not reach a conclusion on one of these things and lock it in, especially if that conclusion is reached without significant community input. This is, to me, part of the judge and jury issue that Brian mentioned some time ago. If you have the opinion that pursuing something through an IETF process would be a bad idea, you are, IMO, welcome to say so. But you are then, again IMO, absolutely obligated to facilitate such an effort procedurally if it is proposed to see if IETF support is really out there... possibly even facilitating it more strongly than if you had not expressed a collective opinion. If, by contract, you (collectively) discourage someone from pursuing something that the IESG concluded that it didn't like sufficiently to approve it during the IETG review cycle, and then use the IESG's considerable procedural discretion to block an effort by the requestors to get IETF review or to starve such a review for resources, then you set up the appearance of an abuse of authority and, perhaps worse, create a situation in which an attempt to get IETF review of an allocation request must be managed by either intimidation or appeal (or by repetitive discussions on the IETF list :-( ). Several people have observed of late that they would prefer to see IESG service viewed as rather more like jury duty with its sense of short-term obligations to the community, rather than as a role similar to either career judicial appointments or of anointed kings. It seems to me that, to some extent, this is another aspect of that distinction. Yes, it is reasonable that the IESG be able to make quick affirmative decisions when those are clearly in order because it saves everyone time. But, when we get to the point where something requires community consensus, I believe that you are obligated to take on that jury role, soliciting community input as fairly as possible and then interpreting it equally fairly, without letting your personal or collective prior views intrude except insofar as they inform the questions you ask of the community. If, instead or in addition to that jury-role, you start influencing the community process by controlling resources or input to support your prior opinions, then we are at high risk. And, if I were forced to choose between a fair, open, and balanced community process if one is initiated and the IESG expressing an opinion, I would suggest that the IESG should not even be permitted to _have_ an opinion and that anyone on the IESG who expresses one should recuse him or herself from all further discussions on the matter. But I don't think we need to make that choice: I think you folks are more than capable of having and expressing opinions and then coordinating a fair and balanced process. The issue may well have had more to do with how the opinion was expressed than what was intended, but the statement about the Roberts allocation request that started these threads seemed to go a bit over the line in that regard and I think we are now in the process of the community clarifying what it wants and expects. John even no, and we recommend that you go away and not pursue John this should not be options unless there really is evidence John of community consensus. Strongly disagreed. See above. I have no problem with your saying the above if you are _absolutely_ sure, and can convince onlookers, that, if the applicant then goes ahead and tries to pursue it, the IESG will do absolutely nothing to block that course of action, even by passive resistance. Put differently, if you make a statement that strong, I believe you actually take on more responsibility for facilitating an effort to pursue the request with the community than you would have had if you didn't have an opinion on the subject of whether it should be pursued (note didn't have not just didn't express). When the IESG (or its members) get to say * no, we won't approve this. * you can pursue it with the community but we recommend that you not do that. And * if you do pursue it, we will (or may) starve you for resources or anything that sounds vaguely like that, then the IESG is essentially making final decisions not declining one particular type of approval option. And I don't think that is acceptable, even if somehow thinly disguisted. I agree that your draft addresses most of these issues. It happens to do so in a manner I believe I disagree with and hope to convince the community is at least
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
John C Klensin wrote: --On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman [EMAIL PROTECTED] wrote: No, I was not intending to imply IESG review would gain a last call. I was only speaking to IETF review. I don't think IESG review gaining a last call is all that benefical. It's not clear how you would interpret the results or what the success/failure criteria is. I think interpreting IESG review last calls would be significantly more difficult than IETF review last calls. We have a lot of experience publishing documents and even dealing with last calls on documents that end up generating a lot of messages. But IESG review would be different enough that it would be highly problematic. Sam, I would think that the purpose of a Last Call as part of IESG review would primarily be not to evaluate success or failure, but to be sure that the IESG has an opportunity to hear, from the community, about issues of which the IESG members might not be aware. Then I don't think it's a Last Call in the normal sense. It's what we might whimsically call a Request For Comments. Seriously, we could call it a Call for Comments. The IESG has been asked to assign a new Foobar codepoint to support the Barfoo protocol specified by the Splat Consortium. See http://splat.org/barfoo for details. The IESG solicits comments on this request by February 29, 2007. That seems reasonable to me. Brian I hope I can say this without sound insulting, because insult is certainly not my intent-- but having the IESG make a decision after soliciting comments from the community is a safer situation and process than having the IESG members talk only with each other or people whom they pick, and then decide. As I'm sure you will agree, no one around here is omniscient; the way we get quality decisions is to get input from as broad a population as possible. Instead, I recommend viewing IESG review as a short circuit process that can be used when a request successfully convinces the IESG that it should be approved. I think it is important that IETF review always exist as an alternative when IESG review is available. If your IESG review is not sufficiently convincing, then you can either pursue IETF review or drop the proposal depending on whether you found the IESG's arguments convincing. Right. And that is another key point, IMO: the main point of IESG review is to have a fairly quick, low-impact process for registrations that can be approved. If the IESG concludes that, for any reason, it cannot approve a particular request, then that request should --at the option of the requester-- be taken up with the community, through an IETF process and without any prejudice from the IESG review. Put differently, if the IESG is asked to look at these things, you should, IMO, ask the community for comment and then decide either yes, register or decline to make a decision on the community's behalf. No, go away, and even no, and we recommend that you go away and not pursue this should not be options unless there really is evidence of community consensus. If you do choose to have a last call for IESG review, you need to have some text explaining what the IESG is evaluating and how the IESG should balance its own opinion against comments made in the last call. I hope that issue is reasonably well covered in draft-klensin-iana-reg-policy-01.txt. If it is not, I guess I've got another rev in my future. I do not believe that document is incompatible with the rfc2434bis document, just that each raises some issues that should inform the other. The iana-reg-policy doc is also intended to contain some key details, such as a discussion of evaluation criteria, that the other document omits. regards, john john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
No, I was not intending to imply IESG review would gain a last call. I was only speaking to IETF review. I don't think IESG review gaining a last call is all that benefical. It's not clear how you would interpret the results or what the success/failure criteria is. I think interpreting IESG review last calls would be significantly more difficult than IETF review last calls. We have a lot of experience publishing documents and even dealing with last calls on documents that end up generating a lot of messages. But IESG review would be different enough that it would be highly problematic. Instead, I recommend viewing IESG review as a short circuit process that can be used when a request successfully convinces the IESG that it should be approved. I think it is important that IETF review always exist as an alternative when IESG review is available. If your IESG review is not sufficiently convincing, then you can either pursue IETF review or drop the proposal depending on whether you found the IESG's arguments convincing. If you do choose to have a last call for IESG review, you need to have some text explaining what the IESG is evaluating and how the IESG should balance its own opinion against comments made in the last call. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
--On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman [EMAIL PROTECTED] wrote: No, I was not intending to imply IESG review would gain a last call. I was only speaking to IETF review. I don't think IESG review gaining a last call is all that benefical. It's not clear how you would interpret the results or what the success/failure criteria is. I think interpreting IESG review last calls would be significantly more difficult than IETF review last calls. We have a lot of experience publishing documents and even dealing with last calls on documents that end up generating a lot of messages. But IESG review would be different enough that it would be highly problematic. Sam, I would think that the purpose of a Last Call as part of IESG review would primarily be not to evaluate success or failure, but to be sure that the IESG has an opportunity to hear, from the community, about issues of which the IESG members might not be aware. I hope I can say this without sound insulting, because insult is certainly not my intent-- but having the IESG make a decision after soliciting comments from the community is a safer situation and process than having the IESG members talk only with each other or people whom they pick, and then decide. As I'm sure you will agree, no one around here is omniscient; the way we get quality decisions is to get input from as broad a population as possible. Instead, I recommend viewing IESG review as a short circuit process that can be used when a request successfully convinces the IESG that it should be approved. I think it is important that IETF review always exist as an alternative when IESG review is available. If your IESG review is not sufficiently convincing, then you can either pursue IETF review or drop the proposal depending on whether you found the IESG's arguments convincing. Right. And that is another key point, IMO: the main point of IESG review is to have a fairly quick, low-impact process for registrations that can be approved. If the IESG concludes that, for any reason, it cannot approve a particular request, then that request should --at the option of the requester-- be taken up with the community, through an IETF process and without any prejudice from the IESG review. Put differently, if the IESG is asked to look at these things, you should, IMO, ask the community for comment and then decide either yes, register or decline to make a decision on the community's behalf. No, go away, and even no, and we recommend that you go away and not pursue this should not be options unless there really is evidence of community consensus. If you do choose to have a last call for IESG review, you need to have some text explaining what the IESG is evaluating and how the IESG should balance its own opinion against comments made in the last call. I hope that issue is reasonably well covered in draft-klensin-iana-reg-policy-01.txt. If it is not, I guess I've got another rev in my future. I do not believe that document is incompatible with the rfc2434bis document, just that each raises some issues that should inform the other. The iana-reg-policy doc is also intended to contain some key details, such as a discussion of evaluation criteria, that the other document omits. regards, john john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
Scott Bradner wrote: works for me (assuming that you include non-IETF documents when you say IETF review documents) In which case, what you last call is not the document itself but what the IETF intends to say about it, and do about the related IANA action. That being so, I think we now have running code proof that this is what the community wants. Brian Scott From [EMAIL PROTECTED] Thu Jul 14 18:12:46 2005 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott Bradner) Cc: ietf@ietf.org Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt References: [EMAIL PROTECTED] From: Sam Hartman [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 18:12:40 -0400 In-Reply-To: [EMAIL PROTECTED] (Scott Bradner's message of Thu, 14 Jul 2005 12:52:38 -0400 (EDT)) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
In which case, what you last call is not the document itself but what the IETF intends to say about it, and do about the related IANA action. just so Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
On Fri, 15 Jul 2005, Brian E Carpenter wrote: Scott Bradner wrote: Sam Hartman wrote: would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. works for me (assuming that you include non-IETF documents when you say IETF review documents) In which case, what you last call is not the document itself but what the IETF intends to say about it, and do about the related IANA action. That being so, I think we now have running code proof that this is what the community wants. To make sure I understand what is being said here, is the proposal that a Last Call would be required for the policies labelled IETF Review and IESG Approval? That seems reasonable to me. And if a last call requirement is added, I don't think there is a reaon any more to change the name to IETF Review from IETF Consensus. I would be less supportive of a proposal to require Last Call in connection with the Specification Required and RFC Required assignment policies. That seems too heavyweight. However, I do think that it would be reasonable to require that the supporting documents be reviewed by a designated expert to verify that it they are sufficiently clear to make possible interoperability between independent implementations. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
imo this update is much needed - there has been considerable confusion about some of the processes in RFC 2434 and it would be good to clear up the confusion one specific area of confusion was what used to be called IETF Consensus - renaming it to IETF Review may help but I'm not sure I think there should be a IANA evaluation process that includes a required IETF-wide Last-Call and evaluatiopn of the results of that Last-Call by the IESG - the current text for IETF Review does not make a Last-Call manditory (this is seperate from IETF Standards action because it should not require a standards-track RFC - an info or exp RFC should be fine) it would be my suggestion to use a very specific term such as IETF Last-Call Consensus for a process that includes the following requires a public document (not limited to IDs RFCs) requires an IETF-wide Last-Call includes IESG evaluation of results of Last-Call IESG permitted to do own evaluation but if results differ from results of Last-Call then IESG has to specifically justify difference in public message to IETF list also concerning the IESG Approval process I'm fine with having such a process but considering the mess we have been going through I would like to add a step to the IESG Approval process if the IESG decides to turn down a request it must document the reason(s) for the reject in a message to the IETF list and run a Last-Call like request for opinions on the proposed IESG rejection - if the responses to the comment requested process clearly do not support the proposed IESG rejection the IESG must withdraw its proposed rejection. The IESG can publish a RFC listing its issues with the proposed use but can not block the assignment if the responses to the comment requested process do not clearly object to the proposed IESG rejection then the IESG recommendation for rejection can be forwarded to the IANA Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
works for me (assuming that you include non-IETF documents when you say IETF review documents) Scott From [EMAIL PROTECTED] Thu Jul 14 18:12:46 2005 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Scott Bradner) Cc: ietf@ietf.org Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt References: [EMAIL PROTECTED] From: Sam Hartman [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 18:12:40 -0400 In-Reply-To: [EMAIL PROTECTED] (Scott Bradner's message of Thu, 14 Jul 2005 12:52:38 -0400 (EDT)) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii would it be reasonable to just say that we are going to always last call IETF review documents? Personally I'd approve of this option unless people think it is too restrictive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
