Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic
There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to [EMAIL PROTECTED] The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4798 on Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)
A new Request for Comments is now available in online RFC libraries. RFC 4798 Title: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) Author: J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur Status: Standards Track Date: February 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 31381 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ooms-v6ops-bgp-tunnel-07.txt URL:http://www.rfc-editor.org/rfc/rfc4798.txt This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS TRACK] This document is a product of the Inter-Domain Routing 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
RFC 4793 on The EAP Protected One-Time Password Protocol (EAP-POTP)
A new Request for Comments is now available in online RFC libraries. RFC 4793 Title: The EAP Protected One-Time Password Protocol (EAP-POTP) Author: M. Nystroem Status: Informational Date: February 2007 Mailbox:[EMAIL PROTECTED] Pages: 82 Characters: 172575 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-nystrom-eap-potp-07.txt URL:http://www.rfc-editor.org/rfc/rfc4793.txt This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4728 on The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4
A new Request for Comments is now available in online RFC libraries. RFC 4728 Title: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 Author: D. Johnson, Y. Hu, D. Maltz Status: Experimental Date: February 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 107 Characters: 265706 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-manet-dsr-10.txt URL:http://www.rfc-editor.org/rfc/rfc4728.txt The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4796 on The Session Description Protocol (SDP) Content Attribute
A new Request for Comments is now available in online RFC libraries. RFC 4796 Title: The Session Description Protocol (SDP) Content Attribute Author: J. Hautakorpi, G. Camarillo Status: Standards Track Date: February 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 11 Characters: 22886 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-sdp-media-content-06.txt URL:http://www.rfc-editor.org/rfc/rfc4796.txt This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control 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
Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Language Tag MIB ' 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 ietf@ietf.org mailing lists by 2007-03-08. Exceptionally, comments may be sent to iesg@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-mcwalter-langtag-mib-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15469&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI) MIB ' 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 ietf@ietf.org mailing lists by 2007-03-08. Exceptionally, comments may be sent to iesg@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-mcwalter-uri-mib-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15468&rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'MIKEY General Extension Payload for OMA BCAST LTKM/STKM Transport' to Informational RFC
The IESG has approved the following document: - 'MIKEY General Extension Payload for OMA BCAST LTKM/STKM Transport ' 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 Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dondeti-msec-mikey-genext-oma-04.txt Technical Summary This document requests IANA registration of a new type of General Extension Payload of MIKEY (RFC 3830) for use by OMA BCAST. The request is for a type value for a payload where the Payload Data is specified in an OMA BCAST technical Specifications, allowing OMA BCAST to have change control. This approach also permits the definition of multiple types of subpayloads within the MIKEY General Extension Payload. For interoperability, one has to implement a combination of RFC 3830, 3GPP MBMS specification (optional), and OMA BCAST specification. Working Group Summary This is not a WG document. The document was discussed on the MSEC mail list. The document was also submitted for review in OMA BCAST. All of the comments from both sources have been addressed. With a liaison statement, OMA BCAST requests publication of this document and requests IANA assignment. Protocol Quality This document was reviewed by Russ Housley for the IESG. Note to the RFC Editor: This document has a dependency to be resolved before publication. This document is to be published in synchronization with the OMA BCAST 1.0 Service and Content Protection Technical Specification: Open Mobile Alliance, "Service and Content Protection for Mobile Broadcast Services", OMA TS-BCAST-SvcCntProtection-V1_0-20060412-D, 2006. Please coordinate with the OMA Release planning group Chair: Peter Arnby +46 70 39 66 395 [EMAIL PROTECTED] And the OMA BCAST Chair: Sungoh Hwang +82 16 9530 5106 [EMAIL PROTECTED] ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Important: Remember to use latest boilerplate in drafts
Hi, With the submission deadlines before the Prague meeting coming up, please remember that all drafts need to use the latest boilerplate text (see below for details). February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) March 5, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 UTC/GMT) Thanks Brian Carpenter Original Message Subject: Internet-Draft Boilerplate Reminder Date: Mon, 15 Jan 2007 11:51:16 -0500 From: IETF Secretariat <[EMAIL PROTECTED]> To: IETF Announcement list CC: iesg@ietf.org This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC ; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC ; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that
