RFC 8331 on RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data
A new Request for Comments is now available in online RFC libraries. RFC 8331 Title: RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data Author: T. Edwards Status: Standards Track Stream: IETF Date: February 2018 Mailbox:thomas.edwa...@fox.com Pages: 20 Characters: 47110 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-payload-rtp-ancillary-14.txt URL:https://www.rfc-editor.org/info/rfc8331 DOI:10.17487/RFC8331 This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). This document is a product of the Audio/Video Transport Payloads 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
Last Call: (TRILL: Vendor Specific TRILL Channel Protocol) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Vendor Specific TRILL Channel Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor specific messages over the RBridge Channel facility. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (TRILL (Transparent Interconnection of Lots of Links) Over IP Transport) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL (Transparent Interconnection of Lots of Links) Over IP Transport' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The TRILL (Transparent Interconnection of Lots of Links) protocol supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between TRILL switch ports. This document specifies transmission of encapsulated TRILL data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP network as a TRILL link in a unified TRILL campus. This document updates RFC 7177 and updates RFC 7178. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream) draft-ietf-tsvwg-le-phb: A Lower Effort Per-Hop Behavior (LE PHB) (None - IETF stream)
Last Call: (Conveying path setup type in PCEP messages) to Proposed Standard
The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Conveying path setup type in PCEP messages' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A Path Computation Element can compute Traffic Engineering (TE) paths through a network that are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Framework for Scheduled Use of Resources) to Informational RFC
The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Framework for Scheduled Use of Resources' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Time-scheduled reservation of traffic engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time including future planned network usage. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-scheduled-resources/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-scheduled-resources/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3081/ https://datatracker.ietf.org/ipr/3083/ https://datatracker.ietf.org/ipr/2893/
Last Call: (An Update to 6LoWPAN ND) to Proposed Standard
The IESG has received a request from the IPv6 over Networks of Resource-constrained Nodes WG (6lo) to consider the following document: - 'An Update to 6LoWPAN ND' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (IPv6 ND PIO Flags IANA considerations) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 ND PIO Flags IANA considerations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. This document updates RFC 4861. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6man-ndpioiana/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Negotiating Human Language in Real-Time Communications' to Proposed Standard (draft-ietf-slim-negotiating-human-language-24.txt)
The IESG has approved the following document: - 'Negotiating Human Language in Real-Time Communications' (draft-ietf-slim-negotiating-human-language-24.txt) as Proposed Standard This document is the product of the Selection of Language for Internet Media Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ Technical Summary: In establishing a multi-media communications session, it can be important to ensure that the caller's language and media needs match the capabilities of the called party. This is important in non-emergency uses (such as when calling a company call center) or in emergencies where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup. This document describes the problem of negotiating human (natural) language needs, abilities and preferences in spoken, written and signed languages. It also provides a solution using new stream attributes within the Session Description Protocol (SDP). Working Group Summary: This draft has undergone 13 revisions since its initial IETF last call (which occurred on draft -06). These revisions were required to address issues raised by the IETF community, such as: 1. The meaning of the "*" in language negotiation. The SDP directorate review in the initial IETF last call expressed concern over the handling of the asterisk, which had the properties of a session attribute while being included within individual m-lines. WG consensus was to remove the asterisk, whose role had been advisory. 2. Routing of calls. The SDP directorate review in the initial IETF last call expressed concern about whether the document intended the use of SDP for routing of SIP traffic. Language was added to indicate clearly that call routing was out of scope. 3. Combining of hlang-send/hlang-recv. In IETF last call, a reviewer suggested that the document allow combining the hlang-send and recv indications so as to allow more efficient representation in cases where language preference is symmetrical. This suggestion was not accepted by the WG since it was not clear that the efficiency was worth the additional complexity. In addition to issues brought up in IETF last call, there was substantial WG discussion on the following points: 4. Undefined language/modality combinations. Language tags do not always distinguish spoken from written language, so some combinations of languages and media are not well defined. The text in Section 5.4 resulted from WG discussion of several scenarios: a. Captioning. While the document supports negotiation of sign language in a video stream, it does not define how to indicate that captioning (e.g. placement of text within the video stream) is desired. WG Consensus did not support use of suppressed script tags for this purpose. b. SignWriting (communicating sign language in written form). Currently only a single language tag has been defined for SignWriting so that written communication of sign language in a text stream (or in captioning) is also not defined. c. Lipreading (spoken language within video). There was not WG consensus for explicitly indicating the desire for spoken language in a video stream (e.g. by use of the -Zxxx script subtag), since the ability to negotiate "lip sync" is already provided in RFC 5888. As a result of these discussions, Section 5.4 leaves a number of potential combinations of language and media undefined. Assuming that implementation experience shows a need to define these scenarios, they can be addressed in future work. 5. Preferences between media. As an example, an individual might be able to understand written English communicated using Realtime Text, but might prefer spoken English audio. The current draft enables all modes of communication to be negotiated, but does not indicate a preference between them. WG consensus was that it was acceptable and possibly more reliable for mutually supported media to be negotiated and brought up, then let the conversants decide which media to use, rather than taking on the additional complexity of negotiating media preference beforehand. During discussion, it was pointed out that quality issues could influence media preferences during a call. For example, on a call where audio, video and text are all available, sending video may interfere with audio quality so that video sending needs to be disabled. Alternatively, audio quality could be poor so that the conversants need to resort to text. So media quality issues can negate the "best laid plans" of media preference negotiation. Document Quality: There are no current implementations of draft-ietf-slim-negotiating-language. However, the
Last Call: (TRILL Multilevel Using Unique Nicknames) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Multilevel Using Unique Nicknames' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract TRILL routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (TRILL: Multi-Topology) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Multi-Topology' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFC 6325 and RFC 7177. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-multi-topology/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-multi-topology/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Directory Assisted TRILL Encapsulation) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'Directory Assisted TRILL Encapsulation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes how data center networks can benefit from non- RBridge nodes performing TRILL encapsulation with assistance from a directory service. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3045/
Last Call: (A YANG Data Model for Routing Information Base (RIB)) to Proposed Standard
The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'A YANG Data Model for Routing Information Base (RIB)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (TRILL Transparent Transport over MPLS) to Informational RFC
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Transparent Transport over MPLS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies methods to interconnect multiple Transparent Interconnection of Lots of links (TRILL) sites with an intervening MPLS network using existing TRILL and VPLS standards. This draft addresses two problems as follows: 1) Providing connection between more than two TRILL sites that are separated by an MPLS provider network. 2) Providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (TRILL Smart Endnodes) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL Smart Endnodes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft addresses the problem of the size and freshness of the endnode learning table in edge RBridges, by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The smart endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables Fine Grained Label aware endnodes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2069/ https://datatracker.ietf.org/ipr/2054/
Last Call: (RTP Payload Format Restrictions) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'RTP Payload Format Restrictions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (CBOR Web Token (CWT)) to Proposed Standard
The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'CBOR Web Token (CWT)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/ No IPR declarations have been submitted directly on this I-D.
