RFC 8686 on Application-Layer Traffic Optimization (ALTO) Cross‑Domain Server Discovery
A new Request for Comments is now available in online RFC libraries. RFC 8686 Title: Application-Layer Traffic Optimization (ALTO) Cross‑Domain Server Discovery Author: S. Kiesel, M. Stiemerling Status: Standards Track Stream: IETF Date: February 2020 Mailbox:ietf-a...@skiesel.de, mls.i...@gmail.com Pages: 34 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-alto-xdom-disc-06.txt URL:https://www.rfc-editor.org/info/rfc8686 DOI:10.17487/RFC8686 The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix. This document is a product of the Application-Layer Traffic Optimization Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8698 on Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media
A new Request for Comments is now available in online RFC libraries. RFC 8698 Title: Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media Author: X. Zhu, R. Pan, M. Ramalho, S. Mena Status: Experimental Stream: IETF Date: February 2020 Mailbox:xiaoq...@cisco.com, rong@intel.com, ma...@cornell.edu, sem...@cisco.com Pages: 26 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-nada-13.txt URL:https://www.rfc-editor.org/info/rfc8698 DOI:10.17487/RFC8698 This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. This document is a product of the RTP Media Congestion Avoidance Techniques 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Guidelines for Defining Packet Timestamps) to Informational RFC
The IESG has received a request from the Network Time Protocol WG (ntp) to consider the following document: - 'Guidelines for Defining Packet Timestamps' 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 last-c...@ietf.org mailing lists by 2020-02-20. 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 Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as packet timestamps for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this memo includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. The rationale behind defining a relatively small set of recommended formats is that it enables significant reuse; network protocols can typically reuse the timestamp format of the Network Time Protocol (NTP) or the Precision Time Protocol (PTP), allowing a straightforward integration with an NTP or a PTP-based timer. Moreover, since accurate timestamping mechanisms are often implemented in hardware, a new network protocol that reuses an existing timestamp format can be quickly deployed using existing hardware timestamping capabilities. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (LPWAN Static Context Header Compression (SCHC) for CoAP) to Proposed Standard
The IESG has received a request from the IPv6 over Low Power Wide-Area Networks WG (lpwan) to consider the following document: - 'LPWAN Static Context Header Compression (SCHC) for CoAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-02-20. 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 defines the way SCHC header compression can be applied to CoAP headers. The CoAP header structure differs from IPv6 and UDP protocols since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP protocol messages format is asymmetric: the request messages have a header format different from the one in the response messages. This document explains how to use the SCHC compression mechanism for CoAP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/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: rfc7967: Constrained Application Protocol (CoAP) Option for No Server Response (Informational - Independent Submission Editor stream) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
The Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) working group in the Applications and Real-Time Area has concluded. The IESG contact persons are Adam Roach, Alexey Melnikov, and Barry Leiba. The MODERN working group will be closed after having completed a framework document (RFC 8396). After producing this initial document, the MODERN working group has struggled to attract sufficient activity to remain open. The proponents of this work believe that it may become relevant at some point in the future. If this occurs and sufficient support exists at the time, it is anticipated that a successor working group will be chartered to develop solutions that satisfy the framework. Thanks to all who participated in the MODERN discussions and the creation of the framework RFC, and to the working group chairs for shepherding that work. Thanks as well to Jon Peterson and Chris Wendt for their work on MODERN-related drafts. The MODERN mailing list (mod...@ietf.org) will be closed. It is anticipated that any future discussions around chartering a new group in this space will take place on the ART and/or DISPATCH (a...@ietf.org and dispa...@ietf.org) mailing lists, as appropriate. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-02-28
The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-02-28 from 08:00 to 09:00 America/New_York. Agenda: * chairs slides * status / progress of the current drafts * draft-ietf-ace-pusub * A more detailed agenda will be provided Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m6d4d2bbc3dece1e868ab501cc801b271 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Transport Area Working Group (tsvwg) WG Virtual Meeting: 2020-02-20 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Transport Area Working Group (tsvwg) Working Group will hold a virtual interim meeting on 2020-02-20 from 09:00 to 11:00 America/New_York. Agenda: 1. Agenda bashing (chairs - 5 min) 2. Update on status and near-term plans for the set of L4S drafts (Bob? - 5 min) - Chair request: Think about adding an explicit "Open Issues / Future Work" type of section in the architecture draft to consolidate a list of things still being worked in the context of TCP Prague and/or caveats and unknowns people should be aware of when deploying this Experimental work. 3. Update on L4S & TCP Prague implementation, test, evaluation (Greg/Bob/Koen? - 15 min) 4. L4S Issues List Discussion (goal is to see if we can agree on what more needs to be done on each issue to suffice for Experimental/Informational RFCs): 4.1 Discuss status on (Bob - ~30 min): #16 on classic ECN interaction #21 CE codepoint semantics (closely related to #16) #20 ECT(1) codepoint usage 4.2 Discuss plans forward to address (Bob - ~15 min): #26 on admission control #27 on terminology #22 on deployment feasibility #24 on evaluation & testing results 4.3 (We will try to handle the issues below by mailing list prior to the meeting) If needed, discuss close-out of (~15 min): #25 on IPR #18 on loss detection in time-units #23 on implementation status #19 on the single codepoint #17 on FQ interaction 5. SCE Update (Morton/Heist/etc. - ~30 min) Information about remote participation: Remote participation information will be obtained at the time of approval. Plan to use IETF WebEx. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
