RFC 4175 on RTP Payload Format for Uncompressed Video
A new Request for Comments is now available in online RFC libraries. RFC 4175 Title: RTP Payload Format for Uncompressed Video Author(s): L. Gharai, C. Perkins Status: Standards Track Date: September 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 18 Characters: 39431 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-avt-uncomp-video-06.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4175.txt This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4192 on Procedures for Renumbering an IPv6 Network without a Flag Day
A new Request for Comments is now available in online RFC libraries. RFC 4192 Title: Procedures for Renumbering an IPv6 Network without a Flag Day Author(s): F. Baker, E. Lear, R. Droms Status: Informational Date: September 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 22 Characters: 52110 Updates:2072 I-D Tag:draft-ietf-v6ops-renumbering-procedure-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4192.txt This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This document is a product of the IPv6 Operations Working Group of the IETF. 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. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4183 on A Suggested Scheme for DNS Resolution of Networks and Gateways
A new Request for Comments is now available in online RFC libraries. RFC 4183 Title: A Suggested Scheme for DNS Resolution of Networks and Gateways Author(s): E. Warnicke Status: Informational Date: September 2005 Mailbox:[EMAIL PROTECTED] Pages: 9 Characters: 18357 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-warnicke-network-dns-resolution-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4183.txt This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. 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. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'HDLC Frames over L2TPv3' to Proposed Standard
The IESG has approved the following document: - 'HDLC Frames over L2TPv3 ' as a Proposed Standard This document is the product of the Layer Two Tunneling Protocol Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-pwe3-hdlc-07.txt Technical Summary L2TPv3 is an evolution to the "Layer 2 Tunneling Protocol" defined in RFC2661. L2TP was originally designed to carry more than one link-type if needed; however, since its origin resided in the pppext WG, the focus of L2TP was PPP only. After the formation of the L2TPEXT WG, multiple proposals were submitted to carry various link-types over L2TP (circa 2000). L2TPv3 was created as a way to consolidate these ideas into a common protocol. The WG decided to organize the documents hierarchically, with one base L2TPv3 specification comprised of the vast majority of the protocol and encapsulation definition to be followed by specific documents for describing each specific link-type. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. Working Group Summary The most challenging task this WG faced with respect to L2TPv3 was extracting the base document from RFC2661. The "follow-on" documents were relatively simple after that task was completed. There has been cross-wg contention with respect to L2TPv3, largely in that it is sometimes postulated as an IP-based alternative to some of the VPN functionality being put into MPLS (e.g., with L2TPv3 you can setup pseudo wires without an MPLS-enabled core network). Protocol Quality Protocol quality has been assured through detail WG and individual review by Ignacio Goyret and Ron da Silva. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'NNTP Extension for Authentication' to Proposed Standard
The IESG has approved the following documents: - 'Using TLS with NNTP ' as a Proposed Standard - 'NNTP Extension for Authentication ' as a Proposed Standard These documents are products of the NNTP Extensions Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nntpext-authinfo-10.txt Technical Summary The TLS extension document defines an extension to the Network News Transport Protocol (NNTP) to provide connection-based security (via Transport Layer Security). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. The authinfo extension document defines an extension to NNTP which allows a client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session. The authinfo document also updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. Working Group Summary Both the AUTHINFO and TLS drafts were written based on the standard SASL and STARTTLS specifications for other protocols. The working group then hammered out reasonable status codes, interaction with other portions of the NNTP protocol, and the documentation of the legacy AUTHINFO USER command. Both documents are believed to be generic and straightforward implementations of the standard SASL and STARTTLS protocols, copying where possible what was done for POP, IMAP, and SMTP. The NNTPEXT WG achieved consensus on both documents. Protocol Quality Scott Hollenbeck has reviewed these specifications for the IESG. The TLS protocol has been implemented in the Cyrus IMAP server and will be implemented in INN. The AUTHINFO USER/PASS authentication method specified here was previously defined less formally in RFC 2980 and is in widespread, interoperable use by existing NNTP implementations. AUTHINFO SASL has been implemented for INN and the Cyrus IMAP server. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Monthly Report for the IAOC for August, 2005
(Sent on behalf of Lucy Lynch, IAOC Chair) Monthly Report for the IAOC for August, 2005. The IETF Administrative Oversight Committee (IAOC) was formed to provide appropriate direction to the IAD [IETF Administrative Director], to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met." The IAOC is charged by BCP 101 with providing regular reports to the IETF community; this monthly report is intended to serve as part of this reporting requirement. The current membership is (in alphabetical order): Brian Carpenter, IETF Chair, ex officio. Steve Crocker, appointed by the ISOC Board of Trustees for two years. Leslie Daigle, IAB Chair, ex officio. Ed Juskevicius, 1 Year NomCom Selection. Kurtis Lindqvist, appointed by the IESG for one year. Lucy Lynch, appointed by the IAB for two years. Lynn St Amour, ISOC President/CEO, ex officio. Jonne Soininen, 2 Year NomCom Selection. In addition, Marshall Eubanks serves as the Secretary and scribe. The IAOC conducts regular (presently weekly) teleconferences, for which minutes are currently available at http://koi.uoregon.edu/~iaoc/. The work conducted by the IAOC during the month of August centered on the following areas : IETF meetings, establishment of a Trust for IETF Intellectual Property Rights (IPR), establishment of a contract for Secretariat Services, and various housekeeping details. IETF-63 in Paris, France : The IAOC had Office Hours during the Paris IETF from 3:45 to 4:45 (local time), Tuesday-Wednesday-Thursday, and presented during the Wednesday plenary. The slides from the presentation are available at http://koi.uoregon.edu/~iaoc/docs/ietf-63-iaoc.pdf . Preparations for upcoming IETF Meetings : Registration for IETF-64 was opened on August 31st. The IAOC and Neustar intend to use this meeting as a template to better understand financial flows and expenses associated with an IETF meeting. Possible locations for meetings after IETF-64 were discussed at length in August, and the IAD, along with IETF volunteers and personnel from Foretec and NeuStar, made a site visit to evaluate possible locations for IETF-65 during the week of August 22nd. The IAD and the IETF Chair worked together to develop a survey questionnaire aimed at IETF 63 meeting attendees to evaluate the meeting itself and suggest changes to future meetings. The survey was released publicly on August 17th, and responses closed on August 26th; a total of 373 responses were received. Survey results are available at http://geneva.isoc.org/surveys/results/IETF63/ . IETF Trust : The IAOC met with Robert Kahn of CNRI and Patrice Lyons, CNRI Counsel, on August 3rd to discuss the the proposed IETF Trust for IPR. Based on comments from this and other meetings, and their internal review, the IOAC prepared a new draft Trust agreement during August. After discussion, the IAOC concluded that this draft would benefit from additional legal review and asked the IETF Counsel to forward it and the associated License documents for review by other counsel at Wilmer Cutler Pickering Hale and Dorr. In addition, during the August 3rd meeting it was agreed that some of the text in BCP 101 is based on assumptions that the IASA has moved beyond. The final version of BCP 101, i.e., RFC 4071, assumed that the vehicle for certain IETF-related Intellectual Property Rights (IPR) would be the Internet Society (ISOC). Since the publication of RFC 4071, the IAOC has been working define and create the IETF Trust to hold such IPR. Since this Trust is not described in BCP 101, the IAOC decided that a new BCP, to include the IETF Trust in the definition of the IASA structure, would be of value, and Brian Carpenter prepared a draft, draft-carpenter-bcp101-update-00.txt, with the IAOC's assistance, to address this. This draft was submitted on August 17th. Contract for Secretariat Services : At present, there is no outstanding contract for the services provided by the IETF Secretariat. The IAOC is empowered by the BCP 101 to execute such a contract and is pursuing this matter vigorously. The IETF Secretariat is hosted by Foretec Seminars Inc., a subsidiary of the Corporation for National Research Initiatives (CNRI). Foretec is currently in the process of being sold to NeuStar, Inc. Assuming that this sale is completed, the IAOC intends to contract with NeuStar, if mutually acceptable terms can be reached, to provide these services for a term not to exceed 2 years, with subsequent terms being contracted under a formal Request for Proposals. On August 1st, in Paris, the IAOC met with Mark Foster, Jeff Neuman and Alan Khalili from Neustar to discuss issues related to the shift of Secretariat services, include the draft Statement of Work, IPR License, and the IEFT Trust. The IAOC agreed that the IAD and the IETF Counsel, Jorge Contreras, should prepare a draft IPR License bas
