Subject: Deadline Extended! Call for nominations: IETF Liaison to ICANN Board of Directors
On 2024-06-11, the IAB issued a call for nominations for the IETF Liaison to the ICANN Board of Directors. The IAB desires to have a diverse pool of candidates for the appointments it makes. Since there was only a very small pool of accepted nominations for this appointment, the IAB has decided to extend the nominations deadline until 23:59 UTC on 2024-07-26. If you are interested in this position, or know of someone who may be a good fit for this position, please send the name and email address to iab-ch...@iab.org with a copy to ex...@iab.org by 23:59 UTC on 2024-07-26. The liaison normally serves a two-year renewable term. The IAB plans to name the liaison to serve for the 2024-2026 period by the end of August with the seating of the liaison to be completed by ICANN 81 in November. Harald Alvestrand has served as the IETF Liaison to the ICANN Board of Directors since 2018, and has indicated that he is willing to continue in the role. The ICANN Mission and the role of the Board of Directors are outlined in the Board Governance Guidelines [1]: The Mission of ICANN is to ensure the stable and secure operation of the Internet's unique identifier systems. The fundamental responsibility of Directors (as defined below) is to exercise their business judgment to act in what they reasonably believe to be the best interests of ICANN and for the benefit of the Internet community as a whole. Actions of the Board should reflect the Board's collective action after taking due reflection. It is the duty of the Board to oversee management's performance to ensure that ICANN in accordance with law efficiency and effectiveness, in a fiscally responsible and accountable manner. The Board is also responsible for overseeing the development of ICANN's Operating Plan and Strategic Plan (each as defined in the Bylaws). The position for an IETF liaison to the board is non-voting. The IETF liaison to the ICANN Board is responsible for staying up-to- date on ICANN operations and developments and informing the IAB and the relevant parts of the IETF community of their potential impact on IETF work and Internet protocols. The IETF liaison is also responsible for informing ICANN of any IETF matters relevant to ICANN. The IAB expects the selected person to effectively communicate between the two organizations. The IETF liaison must have a sufficient understanding of the Internet protocols, DNS, and assigned number management to identify where potential problems might occur or where coordination is needed. When needed, the liaison should be able to identify and call on experts on specific issues on both sides. The IAB expects the IETF liaison to: • be constructive in framing new approaches, technically or in terms of communication. • be willing and able to work well with others. • understand the role and purpose of the relationship the IETF has with ICANN. • be willing and able to commit the time to work in the board, and follow the related discussions. • attend and participate in ICANN meetings as well as any additional board meetings. Generally, there are 3 ICANN meetings and 3 board workshops per year. ICANN typically covers travel costs for board members. • attend and participate in IETF meetings, particularly the working group meetings relevant to work at ICANN. Generally, there are 3 face-to-face IETF meetings per year. • abide by all ICANN Board policies, including confidentiality and conflict of interest policies. The IETF liaison should be unlikely to have conflicts of interest related to typical board discussion topics. The necessary time commitment varies with the extent of work that the liaison is interested in taking on within the board, but just the travel and meeting time alone can be substantial. Typically, there are three ICANN meetings and three additional board meetings per year. For context, the governance documents for the ICANN board can be found here: https://www.icann.org/resources/pages/governance/governance-en These include, for instance, overall governance guidelines, the ICANN bylaws, conflict of interest policies, and travel support: https://www.icann.org/resources/pages/governance/guidelines-en https://www.icann.org/resources/pages/governance/bylaws-en https://www.icann.org/resources/pages/governance/coi-en https://www.icann.org/resources/pages/revised-procedure-2008-08-11-en Note that as per Section 7.22.h of the ICANN Bylaws [2], this position may be entitled to receive compensation from ICANN for services as a non-voting liaison; however, as per the IAB statement on Liaison Compensation [3], the IAB generally believes that the guiding principle should be that individuals serve without expectation of direct compensation from the bodies to which they are appointed, so as to avoid any appearance of conflict of interest. As a result, apart from reasonable travel expenses,
RFC 9493 on Subject Identifiers for Security Event Tokens
A new Request for Comments is now available in online RFC libraries. RFC 9493 Title: Subject Identifiers for Security Event Tokens Author: A. Backman, Ed., M. Scurtescu, P. Jain Status: Standards Track Stream: IETF Date: December 2023 Mailbox:richa...@amazon.com, marius.scurte...@coinbase.com, prachi.jain1...@gmail.com Pages: 18 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-secevent-subject-identifiers-18.txt URL:https://www.rfc-editor.org/info/rfc9493 DOI:10.17487/RFC9493 Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim. This document is a product of the Security Events 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: 'Subject Identifiers for Security Event Tokens' to Proposed Standard (draft-ietf-secevent-subject-identifiers-18.txt)
The IESG has approved the following document: - 'Subject Identifiers for Security Event Tokens' (draft-ietf-secevent-subject-identifiers-18.txt) as Proposed Standard This document is the product of the Security Events Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/ Technical Summary Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the sub_id JSON Web Token (JWT) claim. Working Group Summary There was nothing notable in the WG process beyond the long dormancy this document had. Document Quality This is a dependency of the GNAP WG, and GNAP participants have been involved in the later development stages of this draft. Personnel - Document Shepherd: Yaron Sheffer - Responsible AD: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Subject Identifiers for Security Event Tokens) to Proposed Standard
The IESG has received a request from the Security Events WG (secevent) to consider the following document: - 'Subject Identifiers for Security Event Tokens' 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 2022-11-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 Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the sub_id JSON Web Token (JWT) claim. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/ 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
Subject: NomCom 2021-2022: Composition of IETF Nominating Committee
Please welcome NomCom 2021-2022! The challenge period has ended with no challenges following the update posted on July 8, 2021: https://datatracker.ietf.org/nomcom/ann/326222/ I'd like to thank the following individuals who have prioritized this service to the IETF Community. Voting Members: Name Affiliation Marc Petit-HugueninImpedance Mismatch LLC Christian Huitema Private Octopus Inc. Toerless EckertFuturewei USA LucAndré BurdetCisco Loganaden Velvindron cyberstorm.mu Martin Thomson Mozilla Dhruv DhodyHuawei Mary BarnesIndependent Shraddha Hegde Juniper Networks Chris Box BT Non-Voting Members: Chair: Gabriel Montenegro Past chair: Barbara Stark IAB Liaison: Deborah Brungard IESG Liaison: Roman Danyliw ISOC Board Liaison: Brian Haberman (to be confirmed) IETF LLC Liaison: Sean Turner IETF Trust Liaison: Stephan Wenger Details on how we got here are found in Announcements at https://datatracker.ietf.org/nomcom/ann/#2021 I also wish to inform the community that as of July 12 (last week) my affiliation is no longer "Independent" as I am now working as a consultant for Samsung. Even though affiliation is only tracked for voting members (per RFC8713) I am adding this note in the interest of transparency. Gabriel Montenegro NomCom Chair 2021-2022 nomcom-chair-2021 at ietf dot org ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8813 on Clarifications for Elliptic Curve Cryptography Subject Public Key Information
A new Request for Comments is now available in online RFC libraries. RFC 8813 Title: Clarifications for Elliptic Curve Cryptography Subject Public Key Information Author: T. Ito, S. Turner Status: Standards Track Stream: IETF Date: August 2020 Mailbox:tadahiko.ito.pub...@gmail.com, s...@sn3rd.com Pages: 3 Updates:RFC 5480 I-D Tag:draft-ietf-lamps-5480-ku-clarifications-03.txt URL:https://www.rfc-editor.org/info/rfc8813 DOI:10.17487/RFC8813 This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME 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: 'Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information' to Proposed Standard (draft-ietf-lamps-5480-ku-clarifications-03.txt)
The IESG has approved the following document: - 'Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information' (draft-ietf-lamps-5480-ku-clarifications-03.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ Technical Summary This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality The information in this mail list posting shows that this guidance is needed: https://mailarchive.ietf.org/arch/msg/spasm/mSDS2rOYWoX6jb-d9TmXug3OgPo Personnel Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information) to Proposed Standard
The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information' 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 2020-02-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 This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ballot/ 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
Subject: NomCom 2015-2016 Call for Volunteers
DRAFT - points with XX need to be updated! Subject: NomCom 2015-2016 Call for Volunteers The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas)/ If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. 255 people volunteered by ticking the box on the IETF 92 registration form. 149 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2...@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: ___ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: ___ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag RESEND added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Harald Alvestrand hta+nom...@alvestrand.no nomcom-chair-2...@ietf.org
SUBJECT: UPDATED I2RS Working Group Interim Meeting April 22-23, 2013
A note from the I2RS Chairs regarding the Interim Meeting being held April 22-23, 2013 in Sunnyvale, CA: We've put up a registration page for the I2RS interim meeting at: http://i2rs-interim.eventbrite.com You must register in order to be able to attend. The cut off date for registration will be on April 17, 2013. Cheers all, and hope to see you there. best, -Ed and Alia On Mar 25, 2013, at 5:30 AM, IESG Secretary wrote: I2RS WG Interim Details Dates/Times: 22-23 April 2013 (9:00 am - 5:00 pm PDT) Location: Mountainview or Sunnyvale, California (hosted by Google or Juniper) Registration: For planning purposes only. Remote Participation: via Webex Please see the I2RS mailing list for further details and agenda.
Subject: New Non-WG Mailing List: coma -- Management of Constrained Networks and Devices
A new IETF non-working group email list has been created. List address: c...@ietf.org Archive: http://www.ietf.org/mail-archive/web/coma/ To subscribe: https://www.ietf.org/mailman/listinfo/coma Purpose: This list is for the discussion related to the management of constrained networks and devices. The IETF so far has not developed specific technologies for the management of constrained networks. There is a need to understand the requirements for the management of such a constrained network and its devices. For additional information, please contact the list administrators.
RFC 6495 on Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
A new Request for Comments is now available in online RFC libraries. RFC 6495 Title: Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields Author: R. Gagliano, S. Krishnan, A. Kukec Status: Standards Track Stream: IETF Date: February 2012 Mailbox:rogag...@cisco.com, suresh.krish...@ericsson.com, ana.ku...@enterprisearchitects.com Pages: 5 Characters: 10575 Updates:RFC3971 I-D Tag:draft-ietf-csi-send-name-type-registry-06.txt URL:http://www.rfc-editor.org/rfc/rfc6495.txt SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK] This document is a product of the Cga Send maIntenance 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
[no subject]
rfc-...@rfc-editor.org Subject: Re: Experimental RFC to be: draft-dzis-nwg-nttdm-04.txt The IESG has no problem with the publication of 'The Network Trouble Ticket Data Model' draft-dzis-nwg-nttdm-04.txt as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18533rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dzis-nwg-nttdm-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document defines an experimental XML format for communication of trouble tickets among network operation centers (NOCs). This format enables NOCs to automate the collection, communication, and synchronization of trouble tickets across multiple interconnected networks, such as those forming the Grid. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). Working Group Summary This document is an independent submission and is not the product of (nor has it been reviewed by) any IETF working group. Document Quality The document appears to accurately document the experimental XML format in use. Personnel The responsible Area Director is Peter Saint-Andre. RFC Editor Note This specification documents an XML format that solves a problem similar to those addressed by the INCH and MARF working groups. However, the format serves a somewhat different purpose and thus the IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Subject Key Identifier (SKI) SEND Name Type fields.' to Proposed Standard
The IESG has approved the following document: - 'Subject Key Identifier (SKI) SEND Name Type fields. ' draft-ietf-csi-send-name-type-registry-06.txt as a Proposed Standard This document is the product of the Cga Send maIntenance Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-csi-send-name-type-registry-06.txt Technical Summary SEcure Neighbor Discovery (SEND) defines the Name Type field in the Trust Anchor option. This document requests to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). Working Group Summary Working Group Summary Nothing special that worth noting. Not a controversial document. Document Quality The document is the creation of a registry that was missing on RFC3971. The need for it was identified as part of the work on SEND cert profiles. Personnel Marcelo Bagnulo (marc...@it.uc3m.es) 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
RFC 5480 on Elliptic Curve Cryptography Subject Public Key Information
A new Request for Comments is now available in online RFC libraries. RFC 5480 Title: Elliptic Curve Cryptography Subject Public Key Information Author: S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk Status: Standards Track Date: March 2009 Mailbox:turn...@ieca.com, kelv...@microsoft.com, dbr...@certicom.com, hous...@vigilsec.com, wp...@nist.gov Pages: 20 Characters: 36209 Updates:RFC3279 I-D Tag:draft-ietf-pkix-ecc-subpubkeyinfo-11.txt URL:http://www.rfc-editor.org/rfc/rfc5480.txt This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve Cryptography Subject Public Key Information) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Elliptic Curve Cryptography Subject Public Key Information ' draft-ietf-pkix-ecc-subpubkeyinfo-10.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-09. 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-pkix-ecc-subpubkeyinfo-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16782rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Subject: interim meeting on the topic of ipv4-ipv6 co-existence
An interim meeting will be organized on October 1 - 2 in Montreal, Canada to continue discussions about the IPv4 and IPv6 co-existence, NAT-PT replacement, and new tunneling or translation solutions to address needs in this space. This is a meeting that affects work happening in a number of WGs (SOFTWIRE, V6OPS, BEHAVE, INTAREA). A wiki page containing more information about the meeting has been set up at http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim We are currently working to provide hotel recommendations and other details. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
[no subject]
draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard Reply-to: [EMAIL PROTECTED] The IESG has received a request from an individual submitter to consider the following document: - 'Simple Mail Transfer Protocol ' draft-klensin-rfc2821bis-08.txt as a Draft Standard Because of the comments received in the Last Call on the -06 version, we request a *limited* Last Call on the -08 version. A diff between -08 and the IETF Last Call version -06 can be seen by using: http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl1=http://tools.ietf.org/id/draft-klensin-rfc2821bis-06.txturl2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-08.txt or http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-klensin-rfc2821bis-06.txturl2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-08.txt The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. But please limit your comments to areas that have been discussed since the last call was issued for -06. Almost all of the issues that were raised have been dealt with in some fashion within -07 and -08. New topics should be avoided. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-03-14. 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-klensin-rfc2821bis-08.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13354rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 4985 on Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name
A new Request for Comments is now available in online RFC libraries. RFC 4985 Title: Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name Author: S. Santesson Status: Standards Track Date: August 2007 Mailbox:[EMAIL PROTECTED] Pages: 10 Characters: 17868 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pkix-srvsan-05.txt URL:http://www.rfc-editor.org/rfc/rfc4985.txt This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) 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 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
Protocol Action: 'Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name' to Proposed Standard
The IESG has approved the following document: - 'Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name ' draft-ietf-pkix-srvsan-05.txt as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-05.txt Technical Summary This document specifies how to use the existing X.509 certificate Subject Alternative Name extension (with the otherName syntax) to carry a reference to a DNS SRV record. The intent is to link a certificate to the service named in the DNS record. The document notes that the problem being solved here is not the typical server authentication problem. Instead, an authorization problem is being solved. The question being answered here is whether the server that holds the private key is authorized to provide a particular service. This mechanism fills a gap that otherwise would exist if the server is provisioned with typical server certificate that attests just to the name of the server. A server holding a certificate with this extension has been certified by the issuer of the certificate to offer the service expressed in the corresponding SRV RR record. The cited example in the document is that of a Kerberos server (e.g., a KDC). When DNSSEC is fully deployed, this extension may not be needed, as signed DNS records (SRV RR and others) should be able to provide the same form of authentic authorization information. (This extension does not represent competition with DNSSEC as the only binding provided is to SRV RR records, a subset of overall DNSSEC functionality.) Working Group Summary The PKIX WG expressed consensus to advance the draft to Proposed Standard. Protocol Quality This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4683 on Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
A new Request for Comments is now available in online RFC libraries. RFC 4683 Title: Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) Author: J. Park, J. Lee, H.. Lee, S. Park, T. Polk Status: Standards Track Date: October 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 20 Characters: 41285 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pkix-sim-08.txt URL:http://www.rfc-editor.org/rfc/rfc4683.txt This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate. The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS TRACK] This document is a product of the Public-Key Infrastructure (X.509) 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 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
Protocol Action: 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)' to Proposed Standard
The IESG has approved the following document: - 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) ' draft-ietf-pkix-sim-08.txt as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-08.txt Technical Summary To distinguish among multiple individuals with the same name, it may be necessary to include in a certificate some personal data that may be considered sensitive. Examples of such personal ID data are U.S. social security numbers and similar national ID numbers in other countries. A certificate subject may be willing to disclose this data to some relying parties (RPs), but not to everyone who may have access to his/her certificate. Recall that certificates are often passed over the Internet without encryption, stored in repositories that may allow public access, and so on. Thus a wide range of possible adversaries will have an opportunity to conduct offline attacks that seek to reveal sensitive ID data if it is part of a certificate. SIM is a technique for managing this problem of selective disclosure of such sensitive (though not secret) ID data in the context of X.509 certificates. The SIM data is carried as a subject alternative name (SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format, also defined in this document. Because this data is carried in the SAN, the subject name must itself be unique without the further qualification provided by this other data, consistent with X.509 and PKIX certificate requirements. The PEPSI value is the result of applying a two-pass hash function to the SIM data, employing a user-supplied password and a Registration Authority supplied random number. An attacker trying to confirm a guessed SIM value cannot employ a pre-computed dictionary attack, due to the use of the random number. Nonetheless, selection of a poor password by a user does allow an attacker to mount a focused, offline guessing attack on a PEPSI value. Three scenarios for use of SIM are described: - If a relying party knows the user's SIM value, and uses it to uniquely identify the user, the RP can confirm the user's identify through processing of the certificate and user disclosure of the password to the RP via a secure channel. - If the RP does not know the SIM value, it can be disclosed to the RP via secure transfer of the password, and processing of the certificate by the RP, e.g., so that the RP can acquire the SIM value for future use. - Finally, knowledge of the password by the user can be employed as a secondary authentication mechanism, in addition to the user's knowledge of his private key, without exposing the SIM data to an RP. Working Group Summary The PKIX working group expressed consensus to advance the document to Proposed Standard. Protocol Quality This document has been reviewed by PKIX working group and by the PKIX working group chairs. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor Please expand the first use of RA. OLD: R The random number value generated by an RA. NEW: R The random number value generated by a Registration Authority (RA). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)' to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)' draft-ietf-pkix-sim-07.txt as a Proposed Standard To distinguish among multiple individuals with the same name, it may be necessary to include in a certificate some personal data that may be considered sensitive. Examples of such personal ID data are U.S. social security numbers and similar national ID numbers in other countries. A certificate subject may be willing to disclose this data to some relying parties (RPs), but not to everyone who may have access to his/her certificate. Recall that certificates are often passed over the Internet without encryption, stored in repositories that may allow public access, and so on. Thus a wide range of possible adversaries will have an opportunity to conduct offline attacks that seek to reveal sensitive ID data if it is part of a certificate. SIM is a technique for managing this problem of selective disclosure of such sensitive (though not secret) ID data in the context of X.509 certificates. The SIM data is carried as a subject alternative name (SAN) using the Privacy-Enhanced Personal Identifier (PEPSI) format, also defined in this document. Because this data is carried in the SAN, the subject name must itself be unique without the further qualification provided by this other data, consistent with X.509 and PKIX certificate requirements. The PEPSI value is the result of applying a two-pass hash function to the SIM data, employing a user-supplied password and a Registration Authority supplied random number. An attacker trying to confirm a guessed SIM value cannot employ a pre-computed dictionary attack, due to the use of the random number. Nonetheless, selection of a poor password by a user does allow an attacker to mount a focused, offline guessing attack on a PEPSI value. Three scenarios for use of SIM are described: - If a relying party knows the user's SIM value, and uses it to uniquely identify the user, the RP can confirm the user's identify through processing of the certificate and user disclosure of the password to the RP via a secure channel. - If the RP does not know the SIM value, it can be disclosed to the RP via secure transfer of the password, and processing of the certificate by the RP, e.g., so that the RP can acquire the SIM value for future use. - Finally, knowledge of the password by the user can be employed as a secondary authentication mechanism, in addition to the user's knowledge of his private key, without exposing the SIM data to an RP. 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-03-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Subject: IETF Last Call under RFC 3683 concerning Dean Anderson (reissued)
[NOTE: It has come to the attention of the IESG that the original Last Call message was posted to the IETF announcements mail list while RFC 3683 specifies that it should have been posted to the general IETF discussion list. To correct for this oversight, this Last Call message is reissued with a new expiry date and posted to the correct mail list as prescribed by RFC 3683.] --- The IESG received a request from Dave Crocker to take action under RFC 3683 against Dean Anderson. Mr Crocker alleged disruption of the IETF and DNSEXT lists and provided sample emails [4]. In addition, Dean Anderson was recently warned by David Kessens [2], Operations Management Area Director, that a recent posting on the DNSOP working group mail list was not acceptable after which he responded to the DNSOP list by sending a brief message but with a similar accusation as the one he was warned not to repeat. While these messages alone might not suffice to justify action, Mr Anderson has repeatedly posted, before and since, on these and other IETF lists, messages that refer offensively to individuals or organizations [1]. For a small sample of such messages, we refer to the urls provided at the bottom of this Last Call message. Many of them are off topic for the IETF, since the IETF can only produce general technical recommendations for operators; it may not criticise individual operators or tell them how to conduct their business. We wish to make it clear that quarrels and disagreements between software suppliers, operators and the like have no place in the IETF and must be discussed and settled elsewhere. Although sometimes Mr Anderson's messages address technical topics, this is not enough to excuse the frequent offensiveness. He has been warned to desist from offensive postings multiple times and has often ignored such warnings [2,3]. The IESG therefore proposes to ban Dean Anderson from posting to the main IETF list and to authorize all WG chairs to ban him from posting to their working group lists. This message calls for comments on this proposed action from the IETF, which should be sent to iesg@ietf.org (or ietf@ietf.org) by 12 November 2005. For the IESG, David Kessens Operations Management Area Director --- Please see below for a sample of abusive behavior on maillists: [1] Personal attack on Bill Strahm and alleges that Rob Austein defames av8 Internet: http://www1.ietf.org/mail-archive/web/ietf/current/msg37889.html IETF management is accused of harassment and it is stated that Stephen Sprunk is untrustworthy (end of message). In addition, the message implies that David Kessens is the responsible Area Director for dnsext, while this working group is part of the INT area: http://www1.ietf.org/mail-archive/web/ietf/current/msg37931.html Dean uses a very unpleasant tone to make it clear to David Kessens that he doesn't agree with him and adds another attack by twisting Steven Bellovin's own words and smearing Steven Bellovin's reputation: http://www1.ietf.org/mail-archive/web/ietf/current/msg37873.html (Dean apperently referred to: http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html) Please see below for a sample of messages that ignore requests to Dean Anderson to stop his disruptive behavior: [2] Example of an attack on a well known organization on the dnsop list: Dean Anderson attacks a well known root name server operator and talks about uncontrolled corruption in the IETF: http://darkwing.uoregon.edu/~llynch/dnsop/msg03551.html Message by David Kessens to Dean Anderson that warns him not to bring up any issues he apparently has with a well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03552.html Dean's response in which he reaffirms his accusations towards the well known root name server operator: http://darkwing.uoregon.edu/~llynch/dnsop/msg03553.html [3] Dean alleges that some IETF participants are liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36027.html Brian Carpenter warns not to continue allegations about liars http://www1.ietf.org/mail-archive/web/ietf/current/msg36034.html Dean continues discussion on the list http://www1.ietf.org/mail-archive/web/ietf/current/msg36087.html [4] Materials provided by Dave Crocker to support his request (IETF and dnsext list): Dean continues to discuss topic that was declared off-topic by working group chair: http://www1.ietf.org/mail-archive/web/ietf/current/msg37550.html Dave's response on part of Dean's mail: http://www1.ietf.org/mail-archive/web/ietf/current/msg37554.html Two messages by other participants who continue to discuss Dean's point: http://www1.ietf.org/mail-archive/web/ietf/current/msg37555.html http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html Personal attack on Dave Crocker (and attack on Paul Vixie) by Dean. In addition his message does not substantiate his earlier claims about
RFC 4096 on Policy-Mandated Labels Such as Adv: in Email Subject Headers Considered Ineffective At Best
A new Request for Comments is now available in online RFC libraries. RFC 4096 Title: Policy-Mandated Labels Such as Adv: in Email Subject Headers Considered Ineffective At Best Author(s): C. Malamud Status: Informational Date: May 2005 Mailbox:[EMAIL PROTECTED] Pages: 14 Characters: 31618 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-draft-malamud-subject-line-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4096.txt This memo discusses policies that require certain labels to be inserted in the Subject: header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4096.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Policy-Mandated Labels Such as Adv: in Email Subject Headers Considered Ineffective At Best' to Informational RFC
The IESG has approved the following document: - 'Policy-Mandated Labels Such as Adv: in Email Subject Headers Considered Ineffective At Best ' draft-malamud-subject-line-05.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 Scott Hollenbeck. Technical Summary This memo discusses policies that require certain labels to be inserted in the Subject: header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. Working Group Summary This document is the work of an individual submitter. It has not been reviewed by an IETF working group. Protocol Quality Scott Hollenbeck has reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Labels in Subject Headers Considered Ineffective At Best' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Labels in Subject Headers Considered Ineffective At Best ' draft-malamud-subject-line-02.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-malamud-subject-line-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
