STD 69, RFC 5734 on Extensible Provisioning Protocol (EPP) Transport over TCP
A new Request for Comments is now available in online RFC libraries. STD 69 RFC 5734 Title: Extensible Provisioning Protocol (EPP) Transport over TCP Author: S. Hollenbeck Status: Standards Track Date: August 2009 Mailbox:shollenb...@verisign.com Pages: 13 Characters: 27887 Obsoletes: RFC4934 See Also: STD0069 I-D Tag:draft-hollenbeck-rfc4934bis-01.txt URL:http://www.rfc-editor.org/rfc/rfc5734.txt This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS TRACK] This is now a 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
RFC 69, RFC 5733 on Extensible Provisioning Protocol (EPP) Contact Mapping
A new Request for Comments is now available in online RFC libraries. RFC 69 RFC 5733 Title: Extensible Provisioning Protocol (EPP) Contact Mapping Author: S. Hollenbeck Status: Standards Track Date: August 2009 Mailbox:shollenb...@verisign.com Pages: 41 Characters: 80698 Obsoletes: RFC4933 See Also: RFC0069 I-D Tag:draft-hollenbeck-rfc4933bis-02.txt URL:http://www.rfc-editor.org/rfc/rfc5733.txt This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS TRACK] This is now a 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
STD 69, RFC 5732 on Extensible Provisioning Protocol (EPP) Host Mapping
A new Request for Comments is now available in online RFC libraries. STD 69 RFC 5732 Title: Extensible Provisioning Protocol (EPP) Host Mapping Author: S. Hollenbeck Status: Standards Track Date: August 2009 Mailbox:shollenb...@verisign.com Pages: 29 Characters: 56219 Obsoletes: RFC4932 See Also: STD0069 I-D Tag:draft-hollenbeck-rfc4932bis-01.txt URL:http://www.rfc-editor.org/rfc/rfc5732.txt This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS TRACK] This is now a 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
STD 69, RFC 5731 on Extensible Provisioning Protocol (EPP) Domain Name Mapping
A new Request for Comments is now available in online RFC libraries. STD 69 RFC 5731 Title: Extensible Provisioning Protocol (EPP) Domain Name Mapping Author: S. Hollenbeck Status: Standards Track Date: August 2009 Mailbox:shollenb...@verisign.com Pages: 44 Characters: 87764 Obsoletes: RFC4931 See Also: STD0069 I-D Tag:draft-hollenbeck-rfc4931bis-01.txt URL:http://www.rfc-editor.org/rfc/rfc5731.txt This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS TRACK] This is now a 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
STD 69, RFC 5730 on Extensible Provisioning Protocol (EPP)
A new Request for Comments is now available in online RFC libraries. STD 69 RFC 5730 Title: Extensible Provisioning Protocol (EPP) Author: S. Hollenbeck Status: Standards Track Date: August 2009 Mailbox:shollenb...@verisign.com Pages: 67 Characters: 134464 Obsoletes: RFC4930 See Also: STD0069 I-D Tag:draft-hollenbeck-rfc4930bis-02.txt URL:http://www.rfc-editor.org/rfc/rfc5730.txt This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS TRACK] This is now a 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
RFC 5647 on AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
A new Request for Comments is now available in online RFC libraries. RFC 5647 Title: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol Author: K. Igoe, J. Solinas Status: Informational Date: August 2009 Mailbox:kmi...@nsa.gov, jaso...@orion.ncsc.mil Pages: 10 Characters: 20990 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-igoe-secsh-aes-gcm-03.txt URL:http://www.rfc-editor.org/rfc/rfc5647.txt Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer 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-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
RFC 5643 on Management Information Base for OSPFv3
A new Request for Comments is now available in online RFC libraries. RFC 5643 Title: Management Information Base for OSPFv3 Author: D. Joyal, Ed., V. Manral, Ed. Status: Standards Track Date: August 2009 Mailbox:djo...@nortel.com, vish...@ipinfusion.com Pages: 95 Characters: 192945 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ospf-ospfv3-mib-15.txt URL:http://www.rfc-editor.org/rfc/rfc5643.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP 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
RFC 5641 on Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values
A new Request for Comments is now available in online RFC libraries. RFC 5641 Title: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values Author: N. McGill, C. Pignataro Status: Standards Track Date: August 2009 Mailbox:nmcg...@cisco.com, cpign...@cisco.com Pages: 11 Characters: 23133 Updates:RFC3931, RFC4349, RFC4454, RFC4591, RFC4719 I-D Tag:draft-ietf-l2tpext-circuit-status-extensions-05.txt URL:http://www.rfc-editor.org/rfc/rfc5641.txt This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS TRACK] This document is a product of the Layer Two Tunneling Protocol 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5640 on Load-Balancing for Mesh Softwires
A new Request for Comments is now available in online RFC libraries. RFC 5640 Title: Load-Balancing for Mesh Softwires Author: C. Filsfils, P. Mohapatra, C. Pignataro Status: Standards Track Date: August 2009 Mailbox:cfils...@cisco.com, pmoha...@cisco.com, cpign...@cisco.com Pages: 6 Characters: 12250 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-lb-03.txt URL:http://www.rfc-editor.org/rfc/rfc5640.txt Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS TRACK] This document is a product of the Softwires 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
RFC 5616 on Streaming Internet Messaging Attachments
A new Request for Comments is now available in online RFC libraries. RFC 5616 Title: Streaming Internet Messaging Attachments Author: N. Cook Status: Informational Date: August 2009 Mailbox:neil.c...@noware.co.uk Pages: 28 Characters: 65579 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lemonade-streaming-13.txt URL:http://www.rfc-editor.org/rfc/rfc5616.txt This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content. The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community. This document is a product of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available
Hi all, This email covers 3 topics: 1) Reminder: Call for Nominations 2) New: Local Office Hours 3) New: Questionnaires available for nominees Best Regards, Mary Barnes nomcom-ch...@ietf.org mary.h.bar...@gmail.com mary.bar...@nortel.com === 1) Call for Nominations The nomination period ends in less than 3 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours --- In order to facilitate additional feedback, the Nomcom is planning to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - k...@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhad...@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.bar...@gmail.com Lucy Yong - lucyy...@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolai...@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.b...@gmail.com Montevideo, Uruguay: Roque Gagliano - ro...@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhad...@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+i...@qualcomm.com Dave Crocker - dcroc...@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcroc...@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - dorothy.gell...@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders before the deadline. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 76 - Registration Now Open
76th IETF Meeting Hiroshima, Japan November 8-13, 2009 Host: WIDE Registration is now open! Note: while we stated earlier that we would be moving to a new registration system, we have postponed that transition to IETF 77. If you have attended a recent IETF meeting, the IETF 76 registration system will be quite familiar. Register online at: http://www.ietf.org/meetings/76/ 1. Registration Categories 2. RFID Tagging Experiment 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information Changes from daylight savings to standard time are noted below. 1) Registration Categories A. Early-Bird Registration - USD 635.00 Register and pay before Friday, 30 October 2009 at 17:00 PDT (24:00 UTC/GMT) for Early-Bird rate. B. After Early-Bird cutoff - USD 785.00 C. Full-time Student Registrations - USD 150.00 Full-time students with proper ID are eligible to receive a special USD 150.00 student rate. Student rate is not subject to any late-fees. Students will also be able to register on-site at the special student rate. Failure to provide valid student ID on-site will revoke the special student status. D. NEW: One Day Pass Registration - USD 200.00 For IETF 76 we are also experimenting with a one-day pass for $200. Benefits are: 1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks 2. You select which day to attend when you show up onsite to check-in 3. Payments may be made onsite without a late fee 4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial one-day payment not made before Early Bird deadline 5. Attend Sunday Tutorials at no additional charge 6. Attend Sunday Welcome Reception at no additional charge 7. Attend Wednesday and Thursday Plenaries at no additional charge 8. If available, you may purchase a ticket between 4-5pm on Tuesday to attend the Host's social event that evening CANCELLATION The cut-off for registration cancellation is Monday, 2 November 2009 at 17:00 PST (01:00 Tuesday, November 3 UTC/GMT). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. Online Registration ends: Friday, 6 November, 2009 at 17:00 local Hiroshima time (00:00 Pacific, 08:00 UTC/GMT). On-site Registration You can register onsite at the meeting in Hiroshima, Japan starting Sunday, 8 November at 12:00 noon PST (local Hiroshima time). Meeting Schedule: Start Monday morning and run through Friday at 15:15 local Hiroshima time. Most training sessions will take place on Sunday afternoon 13 November 2009. Participants should plan their travel accordingly. 2) RFID Tagging Experiment The hosts for IETF 76 are organizing an RFID tag experiment for the meeting. The tag will be affixed to the underside of your meeting badge, as a sticker, and will contain only your full name and any listed affiliation. The experiment will allow us to explore the possibility of electronic blue sheets (though we are still using paper blue sheets as the official blue sheets of record for this meeting). We also hope that the RFID tag will improve the experience for remote participants, since speakers will be identified through the RFID tags. While you will be given the option to "opt out" of this experiment when you register for the meeting, we sincerely hope you will participate. More information is available here: http://www.ietf.org/EbluesheetInformation.html 3) Visas and Letters of Invitation Please check the Japanese MOFA site (http://www.mofa.go.jp/j_info/visit/visa/02.html ) for list of countries with visa exemptions. If you travel on a passport issued by a country NOT on this list, you will require documents issued in Japanese by the local host. An English language letter of invitation from the IETF Secretariat WILL NOT suffice to obtain a visa. We recommend at least one month to complete the visa process. To begin the process: 1) please complete Meeting registration and payment of registration fees, 2) reserve accommodation, 3) complete and return the visa information form, which are available in either xls or PDF format on the host site here: http://www.ietf76.jp/ In addition, if you would also like to receive the official IETF letter of invitation, you will be given the option of requesting one after you have completed your meeting registration. Please note that this letter will not assist with the visa process. 4) Accommodations & Breakfast Information Information on IETF 76 accommodations can be found here: http://www.ietf.org/meeting/76/hotel.html . Please note that breakfast will NOT be provided as part of the on- site meeting services. If you reserve a sleeping room at the ANA Crown Plaza Hotel or at any of the IETF overflow properties, breakfast is included with your room. If you choose to
Document Action: 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks' to Informational RFC
The IESG has approved the following document: - 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks ' as an Informational RFC This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-04.txt Technical Summary This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. Working Group Summary This is product of the MEXT WG. Document Quality Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies. Personnel The Document Shepherd is Marcelo Braun, and the responsible Area Director is Jari Arkko. RFC Editor Note Please change the following: OLD: (e.g. the Gatelink system) NEW: (e.g. local networks available while on a gate) OLD: (currently on the surface when connected to a wired Gatelink system) NEW: (currently on the surface when connected to a wired link at a gate) OLD: (link technologies and acronyms are briefly defined in Appendix A. NEW: (link technologies and acronyms are briefly defined in Appendix A). OLD: rouge NEW rogue ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Extended MKCOL for WebDAV' to Proposed Standard
The IESG has approved the following document: - 'Extended MKCOL for WebDAV ' as a Proposed Standard This document is the product of the vCard and CardDAV Working Group. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-webdav-mkcol-06.txt Technical Summary This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. It avoids minting new MK* methods (such as MKCALENDAR) for each new type of collection. Working Group Summary Process was smooth; the only early disagreement was about the scope of this document (whether it should apply to non-collection resources as well, and whether it should also setting ACLs). In the end, the WG converged on the minimal functionality needed to resolve the issue. Document Quality This protocol extension defined in this document is used by the VCARDDAV protocol (another deliverable of the Working Group), for which several vendors have announced support (for instance, Apple, and Viagenie). Personnel The Document Shepherd for this document was Julian Reschke, and the responsible Area Director is Alexey Melnikov. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer' to Proposed Standard
The IESG has approved the following document: - 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer ' 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 Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-09.txt Technical Summary This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. Working Group Summary This document is the result an individual submission by members of the community interested in seeing support for use of ECC algorithms in the SSH protocol. While there is no active working group behind this work, it was extensively reviewed and discussed on the ietf-ssh mailing list, which was the home of the Secure Shell Working Group before that group concluded and still counts many of the participants of that working group among its members. Document Quality While there are no existing implementations of this protocol, there has been indication of interest from SSH implementors. Personnel The document shepherd for this document is Jeffrey Hutzelman The responsible Area Director is Tim Polk. RFC Editor Note Section 12.1 Please remove the URL from the reference [FIPS-180-3]. Section 12.2 Please remove the URLs from references [NIST-800-57] and [NIST-CURVES]. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Alarms in SYSLOG' to Proposed Standard
The IESG has approved the following document: - 'Alarms in SYSLOG ' as a Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-alarm-02.txt Technical Summary This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields and a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. Working Group Summary The document was revised based on WG feedback & the result meets the issues that were raised. Document Quality SYSLOG is widely implemented and deployed, and the ITU severities are used by a number of protocols and alarm models including the IETF Alarm MIB. Personnel Scott Bradner is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note Please insert the following edits in the published version: 1. In section 1, Old:Alarm related terminology is defined in [RFC3877]. New:Alarm related terminology is defined in [RFC3877]. SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424] 2. In section 3 Old: the SD-PARARMS are mandatory. New: the SD-PARAMS are mandatory. 3. In section 3.6 Old: [RFC1738] and its updates. In the case of an SNMP resource, the New: [RFC3986] and its updates. In the case of an SNMP resource, the 4. In section 4 Old: In this example, extended from [Syslog], the VERSION is 1 and the New: In this example, extended from [RFC5424], the VERSION is 1 and the OLD: 'APP-NAME is "su"' NEW: 'APP-NAME is "evntslog"' OLD: 'examples...@0' NEW: 'examples...@32473' OLD: 'resourceURI =' NEW: 'resourceURI=' 5. In section 6 Old: IANA is requested to register the SD-IDs New: IANA is requested to register the syslog Structured Data ID Values 6. In section 8.1 Old:[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. New:[RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", RFC RFC3986, January 2005. 7. In Section 3.1: OLD: If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "resource" SD-PARAM MUST be included. 8. In Section 3.2: OLD: If the "alarm" SD-ID is supported, the "probableCause" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "probableCause" SD-PARAM MUST be included. 9. In Section 3.3: OLD: If the "alarm" SD-ID is supported, the "perceivedSeverity" SD-PARAM MUST be supported. NEW: If the "alarm" SD-ID is included, the "perceivedSeverity" SD-PARAM MUST be included. 10. In Section 3.4: OLD: If the "alarm" SD-ID is supported, the "eventType" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "eventType" SD-PARAM SHOULD be included. 11. In Section 3.5: OLD: If the "alarm" SD-ID is supported, the "trendIndication" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "trendIndication" SD-PARAM SHOULD be included. 12. In Section 3.6: OLD: If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD be supported. NEW: If the "alarm" SD-ID is included, the "resourceURI" SD-PARAM SHOULD be included. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard
The IESG has received a request from the Calendaring and Scheduling Standards Simplification WG (calsify) to consider the following document: - 'iCalendar Transport-Independent Interoperability Protocol (iTIP) ' 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-14. 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-calsify-2446bis-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13952&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages' to Proposed Standard
The IESG has approved the following document: - 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages ' as a Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-05.txt Technical Summary This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. Working Group Summary There was consensus in the working group to publish this document. Document Quality SYSLOG and SNMP are widely implemented and deployed. The document was reviewed in the Working Group and by the MIB DOctors. Personnel Scott Bradner is the Document Shepherd. Dan Romascanu is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard
The IESG has approved the following document: - 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications ' as a Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-06.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. Working Group Summary There was consensus in the working group to publish these documents. Document Quality SNMP and SYSLOG are widely used and deployed. The document was reviewed in the Working Group and by MIB DOctors. Personnel Scott Bradner is the Document Shepherd. Dan Romascanu is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Session Resumption ' 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-14. 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-ipsecme-ikev2-resumption-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17990&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
