Current Internet-Drafts

This summary sheet provides a short synopsis of each Internet-Draft

available within the "internet-drafts" directory at the shadow
sites directory. These drafts are listed alphabetically by working
group acronym and start date. Generated 2022-09-04 21:05:36 UTC.

IPv6 over Networks of Resource-constrained Nodes (6lo)

------------------------------------------------------

"Transmission of IPv6 Packets over Near Field Communication", Younghwan

Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi,
2020-08-23, <draft-ietf-6lo-nfc-17.txt>

Near Field Communication (NFC) is a set of standards for smartphones

and portable devices to establish radio communication with each other
by touching them together or bringing them into proximity, usually no
more than 10 cm apart. NFC standards cover communications protocols
and data exchange formats, and are based on existing radio-frequency
identification (RFID) standards including ISO/IEC 14443 and FeliCa.
The standards include ISO/IEC 18092 and those defined by the NFC
Forum. The NFC technology has been widely implemented and available
in mobile phones, laptop computers, and many other devices. This
document describes how IPv6 is transmitted over NFC using 6LoWPAN
techniques.

"IPv6 over Constrained Node Networks (6lo) Applicability & Use cases",
Yong-Geun Hong, Carles Gomez, Abdur Sangi, Samita Chakrabarti, 2022-07-11,
<draft-ietf-6lo-use-cases-13.txt>

This document describes the applicability of IPv6 over constrained

node networks (6lo) and provides practical deployment examples. In
addition to IEEE Std 802.15.4, various link layer technologies such
as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy, DECT-ULE, MS/TP, NFC,
and PLC are used as examples. The document targets an audience who
would like to understand and evaluate running end-to-end IPv6 over
the constrained node networks for local or Internet connectivity.

"Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu,
Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2022-05-18,
<draft-ietf-6lo-plc-11.txt>

Power Line Communication (PLC), namely using the electric-power lines

for indoor and outdoor communications, has been widely applied to
support Advanced Metering Infrastructure (AMI), especially smart
meters for electricity. The existing electricity infrastructure
facilitates the expansion of PLC deployments due to its potential
advantages in terms of cost and convenience. Moreover, a wide
variety of accessible devices raises the potential demand of IPv6 for
future applications. This document describes how IPv6 packets are
transported over constrained PLC networks, such as ITU-T G.9903, IEEE
1901.1 and IEEE 1901.2.

"IPv6 Neighbor Discovery Multicast Address Listener Subscription", Pascal

Thubert, 2022-08-16, <draft-ietf-6lo-multicast-registration-09.txt>

This document updates RFC 8505 to enable a listener to subscribe an

IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
 updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
new support for anycast addresses in Storing and Non-Storing Modes.
This document extends RFC 9010 to enable the 6LR to inject the
anycast and multicast addresses in RPL.

IPv6 Maintenance (6man)

-----------------------

"IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola,

Tianran Zhou, Mauro Cociglio, Fengwei Qin, Ran Pang, 2022-07-01,
<draft-ietf-6man-ipv6-alt-mark-16.txt>

This document describes how the Alternate Marking Method can be used
as a passive performance measurement tool in an IPv6 domain. It
defines an Extension Header Option to encode Alternate Marking
information in both the Hop-by-Hop Options Header and Destination
Options Header.

"Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to

Flash Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson,
2022-08-12, <draft-ietf-6man-slaac-renum-04.txt>

In renumbering scenarios where an IPv6 prefix suddenly becomes

invalid, hosts on the local network will continue using stale
prefixes for an unacceptably long period of time, thus resulting in
connectivity problems. This document improves the reaction of IPv6
Stateless Address Autoconfiguration to such renumbering scenarios.

"IPv6 Hop-by-Hop Options Processing Procedures", Robert Hinden, Gorry

Fairhurst, 2022-08-23, <draft-ietf-6man-hbh-processing-02.txt>

This document specifies procedures for how IPv6 Hop-by-Hop options

are processed. It modifies the procedures specified in the IPv6
Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-
Hop options practical with the goal of making IPv6 Hop-by-Hop options
useful to deploy and use in the Internet. When published, this
document updates RFC8200.

"Carrying Virtual Transport Network (VTN) Information in IPv6 Extension

Header", Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma, Gyan Mishra,
2022-07-11, <draft-ietf-6man-enhanced-vpn-vtn-id-01.txt>

Virtual Private Networks (VPNs) provide different customers with

logically separated connectivity over a common network
infrastructure. With the introduction and evolvement of 5G and other
network scenarios, some existing or new customers may require
connectivity services with advanced characteristics comparing to
traditional VPNs. Such kind of network service is called enhanced
VPNs (VPN+). VPN+ can be used to deliver IETF network slices, and
could also be used for other application scenarios.

A Virtual Transport Network (VTN) is a virtual underlay network which

consists of a set of dedicated or shared network resources allocated
from the physical underlay network, and is associated with a
customized logical network topology. VPN+ services can be delivered
by mapping one or a group of overlay VPNs to the appropriate VTNs as
the virtual underlay. In packet forwarding, some fields in the data
packet needs to be used to identify the VTN the packet belongs to, so
that the VTN-specific processing can be performed on each node the
 packet traverses.

This document proposes a new Hop-by-Hop option of IPv6 extension

header to carry the VTN related information, which could used to
identify the set of network resources allocated to a VTN and the
rules for packet processing. The procedure for processing the VTN
option is also specified.

"Representing IPv6 Zone Identifiers in Address Literals and Uniform

Resource Identifiers", Brian Carpenter, Stuart Cheshire, Robert Hinden,
2022-07-05, <draft-ietf-6man-rfc6874bis-02.txt>

This document describes how the zone identifier of an IPv6 scoped

address, defined as <zone_id> in the IPv6 Scoped Address Architecture
(RFC 4007), can be represented in a literal IPv6 address and in a
Uniform Resource Identifier that includes such a literal address. It
updates the URI Generic Syntax and Internationalized Resource
Identifier specifications (RFC 3986, RFC 3987) accordingly, and
obsoletes RFC 6874.

"Segment Identifiers in SRv6", Suresh Krishnan, 2022-05-17,

<draft-ietf-6man-sids-01.txt>

The data plane for Segment Routing over IPv6 (SRv6) [RFC8754] is
built using IPv6 as the underlying forwarding plane. Due to this
underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can
resemble IPv6 addresses and behave like them [RFC8754][RFC8986] while
exhibiting slightly different behaviors in some situations. This
document intends to explore the characteristics of SRv6 SIDs and to
clarify the relationship of SRv6 SIDs to the IPv6 Addressing
Architecture [RFC4291].

Authentication and Authorization for Constrained Environments (ace)

-------------------------------------------------------------------

"Key Provisioning for Group Communication using ACE", Francesca Palombini,

Marco Tiloca, 2021-12-23, <draft-ietf-ace-key-groupcomm-15.txt>

This document defines how to use the Authentication and Authorization

for Constrained Environments (ACE) framework to distribute keying
material and configuration parameters for secure group communication.
Candidate group members acting as Clients and authorized to join a
group can do so by interacting with a Key Distribution Center (KDC)
acting as Resource Server, from which they obtain the keying material
to communicate with other group members. While defining general
message formats as well as the interface and operations available at
the KDC, this document supports different approaches and protocols
for secure group communication. Therefore, details are delegated to
separate application profiles of this document, as specialized
instances that target a particular group communication approach and
define how communications in the group are protected. Compliance
requirements for such application profiles are also specified.

"Key Management for OSCORE Groups in ACE", Marco Tiloca, Jiye Park,
Francesca Palombini, 2022-04-28,
<draft-ietf-ace-key-groupcomm-oscore-14.txt>

This document defines an application profile of the ACE framework for

Authentication and Authorization, to request and provision keying
 material in group communication scenarios that are based on CoAP and
are secured with Group Object Security for Constrained RESTful
Environments (Group OSCORE). This application profile delegates the
authentication and authorization of Clients, that join an OSCORE
group through a Resource Server acting as Group Manager for that
group. This application profile leverages protocol-specific
transport profiles of ACE to achieve communication security, server
authentication and proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 Access Token.

"Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication

and Authorization for Constrained Environments (ACE) Framework", Cigdem
Sengul, Anthony Kirby, 2022-03-23, <draft-ietf-ace-mqtt-tls-profile-17.txt>

This document specifies a profile for the ACE (Authentication and

Authorization for Constrained Environments) framework to enable
authorization in a Message Queuing Telemetry Transport (MQTT)-based
publish-subscribe messaging system. Proof-of-possession keys, bound
to OAuth2.0 access tokens, are used to authenticate and authorize
MQTT Clients. The protocol relies on TLS for confidentiality and
MQTT server (Broker) authentication.

"Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard
Hoeglund, Peter van der Stok, Francesca Palombini, 2022-07-11,
<draft-ietf-ace-oscore-gm-admin-06.txt>

Group communication for CoAP can be secured using Group Object

Security for Constrained RESTful Environments (Group OSCORE). A
Group Manager is responsible to handle the joining of new group
members, as well as to manage and distribute the group keying
material. This document defines a RESTful admin interface at the
Group Manager, that allows an Administrator entity to create and
delete OSCORE groups, as well as to retrieve and update their
configuration. The ACE framework for Authentication and
Authorization is used to enforce authentication and authorization of
the Administrator at the Group Manager. Protocol-specific transport
profiles of ACE are used to achieve communication security, proof-of-
possession and server authentication.

"CoAP Transfer for the Certificate Management Protocol", Mohit Sahni,

Saurabh Tripathi, 2021-11-08, <draft-ietf-ace-cmpv2-coap-transport-04.txt>

This document specifies the use of Constrained Application Protocol

(CoAP) as a transfer mechanism for the Certificate Management
Protocol (CMP). purpose of certificate creation and management.
CoAP is an HTTP like client-server protocol used by various
constrained devices in the IoT space.

"EAP-based Authentication Service for CoAP", Rafael Marin-Lopez, Dan

Garcia-Carrillo, 2022-06-23, <draft-ietf-ace-wg-coap-eap-08.txt>

This document specifies an authentication service that uses the

Extensible Authentication Protocol (EAP) transported employing
Constrained Application Protocol (CoAP) messages. As such, it
defines an EAP lower layer based on CoAP called CoAP-EAP. One of the
main goals is to authenticate a CoAP-enabled IoT device (EAP peer)
that intends to join a security domain managed by a Controller (EAP
authenticator). Secondly, it allows deriving key material to protect
CoAP messages exchanged between them based on Object Security for
 Constrained RESTful Environments (OSCORE), enable the establishment
of a security association between them.

"Notification of Revoked Access Tokens in the Authentication and

Authorization for Constrained Environments (ACE) Framework", Marco Tiloca,
Ludwig Seitz, Francesca Palombini, Sebastian Echeverria, Grace Lewis,
2022-07-11, <draft-ietf-ace-revoked-token-notification-02.txt>

This document specifies a method of the Authentication and

Authorization for Constrained Environments (ACE) framework, which
allows an Authorization Server to notify Clients and Resource Servers
(i.e., registered devices) about revoked Access Tokens. The method
allows Clients and Resource Servers to access a Token Revocation List
on the Authorization Server, with the possible additional use of
resource observation for the Constrained Application Protocol (CoAP).
Resulting (unsolicited) notifications of revoked Access Tokens
complement alternative approaches such as token introspection, while
not requiring additional endpoints on Clients and Resource Servers.

"Extension of the CoAP-DTLS Profile for ACE to TLS", Olaf Bergmann, John
Mattsson, Goeran Selander, 2022-09-02,
<draft-ietf-ace-extend-dtls-authorize-03.txt>

This document updates the CoAP-DTLS profile for ACE [RFC9202] by

specifying that the profile applies to TLS as well as DTLS.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Authentication and

Authorization for Constrained Environments Working Group mailing list
(ace@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ace/.

Source for this draft and an issue tracker can be found at

https://github.com/ace-wg/ace-extend-dtls-authorize.

Automated Certificate Management Environment (acme)

---------------------------------------------------

"TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock,

Mary Barnes, Jon Peterson, 2022-08-23,
<draft-ietf-acme-authority-token-tnauthlist-09.txt>

This document defines a profile of the Automated Certificate

Management Environment (ACME) Authority Token for the automated and
authorized creation of certificates for VoIP Telephone Providers to
support Secure Telephony Identity (STI) using the TNAuthList defined
by STI certificates.

"ACME Challenges Using an Authority Token", Jon Peterson, Mary Barnes,

David Hancock, Chris Wendt, 2022-07-11,
<draft-ietf-acme-authority-token-08.txt>

Some proposed extensions to the Automated Certificate Management

Environment (ACME) rely on proving eligibility for certificates
through consulting an external authority that issues a token
according to a particular policy. This document specifies a generic
 Authority Token challenge for ACME which supports subtype claims for
different identifiers or namespaces that can be defined separately
for specific applications.

"ACME End User Client and Code Signing Certificates", Kathleen Moriarty,
2022-04-02, <draft-ietf-acme-client-05.txt>

Automated Certificate Management Environment (ACME) core protocol

addresses the use case of web server certificates for TLS. This
document extends the ACME protocol to support end user client, device
client, and code signing certificates.

"ACME Integrations", Owen Friel, Richard Barnes, Rifaat Shekh-Yusef,

Michael Richardson, 2022-07-04, <draft-ietf-acme-integrations-08.txt>

This document outlines multiple advanced use cases and integrations

that ACME facilitates without any modifications or enhancements
required to the base ACME specification. The use cases include ACME
integration with EST, BRSKI and TEAP.

"Automated Certificate Management Environment (ACME) Delay-Tolerant

Networking (DTN) Node ID Validation Extension", Brian Sipos, 2022-03-02,
<draft-ietf-acme-dtnnodeid-09.txt>

This document specifies an extension to the Automated Certificate

Management Environment (ACME) protocol which allows an ACME server to
validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
client. The DTN Node ID is encoded as a certificate Subject
Alternative Name (SAN) of type otherName with a name form of
BundleEID and as an ACME Identifier type "bundleEID".

"ACME for Subdomains", Owen Friel, Richard Barnes, Tim Hollebeek, Michael
Richardson, 2022-06-29, <draft-ietf-acme-subdomains-04.txt>

This document outlines how ACME can be used by a client to obtain a

certificate for a subdomain identifier from a certification
authority. The client has fulfilled a challenge against a parent
domain but does not need to fulfill a challenge against the explicit
subdomain as certification authority policy allows issuance of the
subdomain certificate without explicit subdomain ownership proof.

"Automated Certificate Management Environment (ACME) Renewal Information

(ARI) Extension", Aaron Gable, 2022-08-25, <draft-ietf-acme-ari-00.txt>

This document specifies how an ACME server may provide suggestions to

ACME clients as to when they should attempt to renew their
certificates. This allows servers to mitigate load spikes, and
ensures clients do not make false assumptions about appropriate
certificate renewal periods.

Current Implementations

Draft note: this section will be removed by the editor before final
publication.

Let's Encrypt's Staging environment (available at [lestaging], source

at [boulder]) implements this draft specification.

Adaptive DNS Discovery (add)

----------------------------

"Discovery of Designated Resolvers", Tommy Pauly, Eric Kinnear, Christopher

Wood, Patrick McManus, Tommy Jensen, 2022-08-05, <draft-ietf-add-ddr-10.txt>

This document defines Discovery of Designated Resolvers (DDR), a

mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration. An encrypted DNS resolver discovered in
this manner is referred to as a "Designated Resolver". This
mechanism can be used to move from unencrypted DNS to encrypted DNS
when only the IP address of a resolver is known. This mechanism is
designed to be limited to cases where unencrypted DNS resolvers and
their designated resolvers are operated by the same entity or
cooperating entities. It can also be used to discover support for
encrypted DNS protocols when the name of an encrypted DNS resolver is
known.

"DHCP and Router Advertisement Options for the Discovery of

Network-designated Resolvers (DNR)", Mohamed Boucadair, Tirumaleswar
Reddy.K, Dan Wing, Neil Cook, Tommy Jensen, 2022-08-13,
<draft-ietf-add-dnr-13.txt>

The document specifies new DHCP and IPv6 Router Advertisement options
to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-
TLS, DNS-over-QUIC). Particularly, it allows a host to learn an
authentication domain name together with a list of IP addresses and a
set of service parameters to reach such encrypted DNS resolvers.

"Service Binding Mapping for DNS Servers", Benjamin Schwartz, 2022-08-11,

<draft-ietf-add-svcb-dns-07.txt>

The SVCB DNS resource record type expresses a bound collection of

endpoint metadata, for use when establishing a connection to a named
service. DNS itself can be such a service, when the server is
identified by a domain name. This document provides the SVCB mapping
for named DNS servers, allowing them to indicate support for
encrypted transport protocols.

"Establishing Local DNS Authority in Split-Horizon Environments",

Tirumaleswar Reddy.K, Dan Wing, Kevin Smith, Benjamin Schwartz, 2022-08-22,
<draft-ietf-add-split-horizon-authority-01.txt>

When split-horizon DNS is deployed by a network, certain domains can

be resolved authoritatively by the network-provided DNS resolver.
DNS clients that don't always use this resolver might wish to do so
for these domains. This specification describes how clients can
confirm the local resolver's authority over these domains.

Application-Layer Traffic Optimization (alto)

---------------------------------------------

"ALTO Performance Cost Metrics", Qin WU, Y. Yang, Young Lee, Dhruv Dhody,
Sabine Randriamasy, Luis Contreras, 2022-03-21,
<draft-ietf-alto-performance-metrics-28.txt>

The cost metric is a basic concept in Application-Layer Traffic

Optimization (ALTO), and different applications may use different
types of cost metrics. Since the ALTO base protocol (RFC 7285)
defines only a single cost metric (namely, the generic "routingcost"
 metric), if an application wants to issue a cost map or an endpoint
cost request in order to identify a resource provider that offers
better performance metrics (e.g., lower delay or loss rate), the base
protocol does not define the cost metric to be used.

This document addresses this issue by extending the specification to

provide a variety of network performance metrics, including network
delay, delay variation (a.k.a, jitter), packet loss rate, hop count,
and bandwidth.

There are multiple sources (e.g., estimation based on measurements or

service-level agreement) to derive a performance metric. This
document introduces an additional "cost-context" field to the ALTO
"cost-type" field to convey the source of a performance metric.

"An ALTO Extension: Path Vector", Kai Gao, Young Lee, Sabine Randriamasy,
Y. Yang, Jingxuan Zhang, 2022-03-20, <draft-ietf-alto-path-vector-25.txt>

This document is an extension to the base Application-Layer Traffic

Optimization (ALTO) protocol. It extends the ALTO Cost Map and ALTO
Property Map services so that an application can decide which
endpoint(s) to connect based on not only numerical/ordinal cost
values but also fine-grained abstract information of the paths. This
is useful for applications whose performance is impacted by specified
components of a network on the end-to-end paths, e.g., they may infer
that several paths share common links and prevent traffic bottlenecks
by avoiding such paths. This extension introduces a new abstraction
called Abstract Network Element (ANE) to represent these components
and encodes a network path as a vector of ANEs. Thus, it provides a
more complete but still abstract graph representation of the
underlying network(s) for informed traffic optimization among
endpoints.

"A Yang Data Model for OAM and Management of ALTO Protocol", Jingxuan
Zhang, Dhruv Dhody, Kai Gao, Roland Schott, 2022-07-11,
<draft-ietf-alto-oam-yang-01.txt>

This document defines a YANG data model for Operations,

Administration, and Maintenance (OAM) & Management of Application-
Layer Traffic Optimization (ALTO) Protocol. The operator can use the
data model to create and update ALTO information resources, manage
the access control, configure server-to-server communication and
server discovery, and collect statistical data.

"ALTO/H2: The ALTO Protocol using HTTP/2", Roland Schott, Y. Yang, Kai Gao,
Jingxuan Zhang, 2022-07-11, <draft-ietf-alto-new-transport-01.txt>

The ALTO base protocol [RFC7285] uses HTTP/1.x as the transport

protocol and hence ALTO transport includes the limitations of
HTTP/1.x. ALTO/SSE [RFC8895] addresses some of the limitations, but
is still based on HTTP/1.x. This document introduces ALTO new
transport, which provides the transport functions of ALTO/SSE on top
of HTTP/2, for more efficient ALTO transport.

Autonomic Networking Integrated Model and Approach (anima)

----------------------------------------------------------

"Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)",

Michael Richardson, Peter van der Stok, Panos Kampanakis, Esko Dijk,
2022-07-11, <draft-ietf-anima-constrained-voucher-18.txt>

This document defines the Constrained Bootstrapping Remote Secure Key

Infrastructure (Constrained BRSKI) protocol, which provides a
solution for secure zero-touch bootstrapping of resource-constrained
(IoT) devices into the network of a domain owner. This protocol is
designed for constrained networks, which may have limited data
throughput or may experience frequent packet loss. Constrained BRSKI
is a variant of the BRSKI protocol, which uses an artifact signed by
the device manufacturer called the "voucher" which enables a new
device and the owner's network to mutually authenticate. While the
BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines
a compact CBOR-encoded voucher. The BRSKI voucher is extended with
new data types that allow for smaller voucher sizes. The Enrollment
over Secure Transport (EST) protocol, used in BRSKI, is replaced with
EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.

"Information Distribution over GRASP", Xun Xiao, Bing Liu, Artur Hecker,
Sheng Jiang, 2022-07-10, <draft-ietf-anima-grasp-distribution-05.txt>

Autonomic network infrastructure (ANI) is a generic platform for

tenant applications (i.e. AFs). As we will see in some examplery
use cases, AFs may not only require communication capability
supported from the infrastructure side, but also the capability the
infrastructure can hold and re-distribute information on-demand.
This document proposes a set of solutions for information
distribution in the ANI. Information distribution is categorized
into two different modes: 1) instantaneous distribution and 2)
publishing for retrieval. In the former case, the information is
sent, propagated and disposed of after reception. In the latter
case, information needs to be stored in the network; additionally,
conflict resolution is also needed when information stored in the
network is updated with proposals from two different AFs.

The capability of information distribution is a fundamental need for

an autonomous network ([RFC7575]). This document describes typical
use cases of information distribution in ANI and requirements to ANI,
such that abundant ways of information distribution can be natively
supported. This draft proposes a series of extensions to the
autonomic nodes and suggests an implementation based on GRASP
([RFC8990]) extensions as a protocol on the wire.

"Constrained Join Proxy for Bootstrapping Protocols", Michael Richardson,

Peter van der Stok, Panos Kampanakis, 2022-08-16,
<draft-ietf-anima-constrained-join-proxy-12.txt>

This document extends the work of Bootstrapping Remote Secure Key

Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge
and Registrar by a stateless/stateful constrained Join Proxy. The
constrained Join Proxy is a mesh neighbor of the Pledge and can relay
a DTLS session originating from a Pledge with only link-local
addresses to a Registrar which is not a mesh neighbor of the Pledge.

This document defines a protocol to securely assign a Pledge to a

domain, represented by a Registrar, using an intermediary node
between Pledge and Registrar. This intermediary node is known as a
"constrained Join Proxy". An enrolled Pledge can act as a
constrained Join Proxy.
"Delegated Authority for Bootstrap Voucher Artifacts", Michael Richardson,
Wei Pan, 2022-07-11, <draft-ietf-anima-voucher-delegation-02.txt>

This document describes an extension of the RFC8366 Voucher Artifact

in order to support delegation of signing authority. The initial
voucher pins a public identity, and that public indentity can then
issue additional vouchers. This chain of authorization can support
permission-less resale of devices, as well as guarding against
business failure of the BRSKI Manufacturer Authorized Signing
Authority (MASA).

"BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael

Richardson, 2022-05-24, <draft-ietf-anima-brski-cloud-04.txt>

This document specifies the behavior of a BRSKI Cloud Registrar, and

how a pledge can interact with a BRSKI Cloud Registrar when
bootstrapping.

RFCED REMOVE: It is being actively worked on at https://github.com/

anima-wg/brski-cloud

"JWS signed Voucher Artifacts for Bootstrapping Protocols", Thomas Werner,

Michael Richardson, 2022-07-11, <draft-ietf-anima-jws-voucher-04.txt>

[RFC8366] defines a digital artifact called voucher as a YANG-defined

JSON document that has been signed using a Cryptographic Message
Syntax (CMS) structure. This memo introduces a variant of the
voucher structure in which CMS is replaced by the JSON Object Signing
and Encryption (JOSE) mechanism described in RFC7515 to better
support use-cases in which JOSE is preferred over CMS.

In addition to explaining how the format is created, MIME types are

registered and examples are provided.

"BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Steffen Fries, Thomas

Werner, Eliot Lear, Michael Richardson, 2022-07-08,
<draft-ietf-anima-brski-prm-04.txt>

This document defines enhancements to bootstrapping a remote secure

key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
domains featuring no or only timely limited connectivity between a
pledge and the domain registrar. It specifically targets situations,
in which the interaction model changes from a pledge-initiator-mode,
as used in BRSKI, to a pledge-responder-mode as described in this
document. To support both, BRSKI-PRM introduces a new registrar-
agent component, which facilitates the communication between pledge
and registrar during the bootstrapping phase. For the establishment
of a trust relation between pledge and domain registrar, BRSKI-PRM
relies on the exchange of authenticated self-contained objects
(signature-wrapped objects). The defined approach is agnostic
regarding the utilized enrollment protocol, deployed by the domain
registrar to communicate with the Domain CA.

"An Autonomic Mechanism for Resource-based Network Services

Auto-deployment", Joanna Dang, Sheng Jiang, Zongpeng Du, Yujing Zhou,
2022-07-07, <draft-ietf-anima-network-service-auto-deployment-02.txt>

This document specifies an autonomic mechanism for resource-based

network services deployment through the Autonomic Control Plane (ACP)
 in a network. This mechanism uses the GeneRic Autonomic Signaling
Protocol (GRASP) in [RFC8990] to exchange the information among the
autonomic nodes so that the resource along the service path can be
coordinated.

"BRSKI-AE: Alternative Enrollment Protocols in BRSKI", David von Oheimb,

Steffen Fries, Hendrik Brockhaus, Eliot Lear, 2022-06-03,
<draft-ietf-anima-brski-ae-02.txt>

This document enhances Bootstrapping Remote Secure Key Infrastructure

(BRSKI, RFC 8995) to allow employing alternative enrollment
protocols, such as CMP.

Using self-contained signed objects, the origin of enrollment

requests and responses can be authenticated independently of message
transfer. This supports end-to-end security and asynchronous
operation of certificate enrollment and provides flexibility where to
authenticate and authorize certification requests.

Applications and Real-Time Area (art)

-------------------------------------

"Internationalized Domain Names in Applications (IDNA): Registry

Restrictions and Recommendations", John Klensin, Asmus Freytag, 2020-07-13,
<draft-klensin-idna-rfc5891bis-06.txt>

The IDNA specifications for internationalized domain names combine

rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFCs
5890 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.

"Robots Exclusion Protocol", Martijn Koster, Gary Illyes, Henner Zeller,

Lizzi Sassman, 2022-07-06, <draft-koster-rep-12.txt>

This document specifies and extends the "Robots Exclusion Protocol"

method originally defined by Martijn Koster in 1996 for service
owners to control how content served by their services may be
accessed, if at all, by automatic clients known as crawlers.
Specifically, it adds definition language for the protocol and
instructions for handling errors and caching.

"WebP Image Format Media Type Registration", James Zern, Pascal Massimino,
Jyrki Alakuijala, 2022-08-03, <draft-zern-webp-09.txt>

This document provides the Media Type Registration for the subtype
image/webp.

Automatic SIP trunking And Peering (asap)

-----------------------------------------
 "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan,
Cullen Jennings, 2022-04-21, <draft-ietf-asap-sip-auto-peer-05.txt>

This draft specifies a configuration workflow to enable enterprise

Session Initiation Protocol (SIP) networks to solicit the capability
set of a SIP service provider network. The capability set can
subsequently be used to configure features and services on the
enterprise edge element, such as a Session Border Controller (SBC),
to ensure smooth peering between enterprise and service provider
networks.

A Semantic Definition Format for Data and Interactions of Things (asdf)

-----------------------------------------------------------------------

"Semantic Definition Format (SDF) for Data and Interactions of Things",

Michael Koster, Carsten Bormann, 2022-06-30, <draft-ietf-asdf-sdf-12.txt>

The Semantic Definition Format (SDF) is a format for domain experts

to use in the creation and maintenance of data and interaction models
in the Internet of Things. An SDF specification describes
definitions of SDF Objects and their associated interactions (Events,
Actions, Properties), as well as the Data types for the information
exchanged in those interactions. Tools convert this format to
database formats and other serializations as needed.

// A JSON format representation of SDF 1.0 was defined in version

// (-00) of this document; version (-05) was designated as an
// _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of
// the ASDF WG (2021-03-11). The present version (-12) collects
// smaller changes up to 2022-06-30. It also removes deprecated
// elements from SDF 1.0.

Audio/Video Transport Core Maintenance (avtcore)

------------------------------------------------

"RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus
Flodman, Danny Hong, Jonathan Lennox, 2021-06-10,
<draft-ietf-payload-vp9-16.txt>

This specification describes an RTP payload format for the VP9 video
codec. The payload format has wide applicability, as it supports
applications from low bit-rate peer-to-peer usage, to high bit-rate
video conferences. It includes provisions for temporal and spatial
scalability.

"Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas

Nandakumar, 2021-11-11, <draft-ietf-avtext-framemarking-13.txt>

This document describes a Frame Marking RTP header extension used to

convey information about video frames that is critical for error
recovery and packet forwarding in RTP middleboxes or network nodes.
It is most useful when media is encrypted, and essential when the
middlebox or node has no access to the media decryption keys. It is
also useful for codec-agnostic processing of encrypted or unencrypted
media, while it also supports extensions for codec-specific
information.
"RTP Payload Format for Versatile Video Coding (VVC)", Shuai Zhao, Stephan
Wenger, Yago Sanchez, Ye-Kui Wang, Miska Hannuksela, 2022-08-04,
<draft-ietf-avtcore-rtp-vvc-18.txt>

This memo describes an RTP payload format for the video coding
standard ITU-T Recommendation H.266 and ISO/IEC International
Standard 23090-3, both also known as Versatile Video Coding (VVC) and
developed by the Joint Video Experts Team (JVET). The RTP payload
format allows for packetization of one or more Network Abstraction
Layer (NAL) units in each RTP packet payload as well as fragmentation
of a NAL unit into multiple RTP packets. The payload format has wide
applicability in videoconferencing, Internet video streaming, and
high-bitrate entertainment-quality video, among other applications.

"Multiplexing Scheme Updates for QUIC", Bernard Aboba, Gonzalo Salgueiro,

Colin Perkins, 2022-08-05, <draft-ietf-avtcore-rfc7983bis-06.txt>

This document defines how QUIC, Datagram Transport Layer Security

(DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol
(RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using
Relays around NAT (TURN), and ZRTP packets are multiplexed on a
single receiving socket.

This document updates RFC 7983 and RFC 5764.

"Completely Encrypting RTP Header Extensions and Contributing Sources",

Justin Uberti, Cullen Jennings, Sergio Murillo, 2022-08-04,
<draft-ietf-avtcore-cryptex-08.txt>

While the Secure Real-time Transport Protocol (SRTP) provides

confidentiality for the contents of a media packet, a significant
amount of metadata is left unprotected, including RTP header
extensions and contributing sources (CSRCs). However, this data can
be moderately sensitive in many applications. While there have been
previous attempts to protect this data, they have had limited
deployment, due to complexity as well as technical limitations.

This document updates RFC 3711, the SRTP specification, and defines
Cryptex as a new mechanism that completely encrypts header extensions
and CSRCs and uses simpler Session Description Protocol (SDP)
signaling with the goal of facilitating deployment.

"RTP over QUIC", Joerg Ott, Mathis Engelbart, 2022-06-24,

<draft-engelbart-rtp-over-quic-04.txt>

This document specifies a minimal mapping for encapsulating RTP and

RTCP packets within QUIC. It also discusses how to leverage state
from the QUIC implementation in the endpoints to reduce the exchange
of RTCP packets and how to implement congestion control.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/mengelbart/rtp-over-quic-draft.

"RTP Payload Format for the SCIP Codec", Daniel Hanson, MikeFaller, Keith
Maver, 2022-08-02, <draft-ietf-avtcore-rtp-scip-02.txt>
 This document describes the RTP payload format of the Secure
Communication Interoperability Protocol (SCIP) as audio and
video media subtypes. It provides RFC 6838 compliant media
subtype definitions. SCIP-210 describes the protocols that
comprise the content of the SCIP RTP packet payload. This
document follows the registration for related media types
called "audio/scip" and "video/scip" with IANA and formatted
according to RFC 4855.

"RTP over QUIC", Joerg Ott, Mathis Engelbart, 2022-07-26,

<draft-ietf-avtcore-rtp-over-quic-00.txt>

This document specifies a minimal mapping for encapsulating RTP and

RTCP packets within QUIC. It also discusses how to leverage state
from the QUIC implementation in the endpoints to reduce the exchange
of RTCP packets and how to implement congestion control.

Audio/Video Transport Extensions (avtext)

-----------------------------------------

"The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox,
Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2017-07-02,
<draft-ietf-avtext-lrr-07.txt>

This memo describes the RTCP Payload-Specific Feedback Message "Layer

Refresh Request" (LRR), which can be used to request a state refresh
of one or more substreams of a layered media stream. It also defines
its use with several RTP payloads for scalable media formats.

Babel routing protocol (babel)

------------------------------

"YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark,

2021-09-20, <draft-ietf-babel-yang-model-13.txt>

This document defines a data model for the Babel routing protocol.
The data model is defined using the YANG data modeling language.

"Relaxed Packet Counter Verification for Babel MAC Authentication", Juliusz

Chroboczek, Toke Hoeiland-Joergensen, 2022-08-29,
<draft-ietf-babel-mac-relaxed-02.txt>

This document relaxes packet verification rules defined in the Babel

MAC Authentication protocol in order to make it more robust in the
presence of packet reordering.

BGP Enabled ServiceS (bess)

---------------------------

"Optimized Ingress Replication Solution for Ethernet VPN (EVPN)", Jorge

Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi,
2022-01-25, <draft-ietf-bess-evpn-optimized-ir-12.txt>

Network Virtualization Overlay networks using Ethernet VPN (EVPN) as

their control plane may use Ingress Replication or PIM (Protocol
Independent Multicast)-based trees to convey the overlay Broadcast,
Unknown unicast and Multicast (BUM) traffic. PIM provides an
efficient solution to avoid sending multiple copies of the same
 packet over the same physical link, however it may not always be
deployed in the Network Virtualization Overlay core network. Ingress
Replication avoids the dependency on PIM in the Network
Virtualization Overlay network core. While Ingress Replication
provides a simple multicast transport, some Network Virtualization
Overlay networks with demanding multicast applications require a more
efficient solution without PIM in the core. This document describes
a solution to optimize the efficiency of Ingress Replication trees.

"Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan,
Keyur Patel, Ali Sajassi, 2021-11-18,
<draft-ietf-bess-evpn-bum-procedure-updates-14.txt>

This document specifies updated procedures for handling broadcast,

unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
including selective multicast, and provider tunnel segmentation.
This document updates RFC 7432.

"Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Wen

Lin, John Drake, Ali Sajassi, 2022-09-02,
<draft-ietf-bess-evpn-pref-df-10.txt>

The Designated Forwarder (DF) in Ethernet Virtual Private Networks

(EVPN) is defined as the PE responsible for sending Broadcast,
Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/
network in the case of an all-active multi-homing Ethernet Segment
(ES), or BUM and unicast in the case of single-active multi-homing.
The Designated Forwarder is selected out of a candidate list of PEs
that advertise the same Ethernet Segment Identifier (ESI) to the EVPN
network, according to the Default Designated Forwarder Election
algorithm. While the Default Algorithm provides an efficient and
automated way of selecting the Designated Forwarder across different
Ethernet Tags in the Ethernet Segment, there are some use cases where
a more 'deterministic' and user-controlled method is required. At
the same time, Service Providers require an easy way to force an on-
demand Designated Forwarder switchover in order to carry out some
maintenance tasks on the existing Designated Forwarder or control
whether a new active PE can preempt the existing Designated Forwarder
PE.

This document proposes a Designated Forwarder Election algorithm that

meets the requirements of determinism and operation control.

"EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui

Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2022-06-23,
<draft-ietf-bess-evpn-irb-mcast-07.txt>

Ethernet VPN (EVPN) provides a service that allows a single Local

Area Network (LAN), comprising a single IP subnet, to be divided into
multiple "segments". Each segment may be located at a different
site, and the segments are interconnected by an IP or MPLS backbone.
Intra-subnet traffic (either unicast or multicast) always appears to
the endusers to be bridged, even when it is actually carried over the
IP or MPLS backbone. When a single "tenant" owns multiple such LANs,
EVPN also allows IP unicast traffic to be routed between those LANs.
This document specifies new procedures that allow inter-subnet IP
multicast traffic to be routed among the LANs of a given tenant,
while still making intra-subnet IP multicast traffic appear to be
bridged. These procedures can provide optimal routing of the inter-
 subnet multicast traffic, and do not require any such traffic to
leave a given router and then reenter that same router. These
procedures also accommodate IP multicast traffic that needs to travel
to or from systems that are outside the EVPN domain.

"EVPN VPWS Flexible Cross-Connect Service", Ali Sajassi, Patrice Brissette,

Jim Uttaro, John Drake, Sami Boutros, Jorge Rabadan, 2022-06-16,
<draft-ietf-bess-evpn-vpws-fxc-07.txt>

This document describes a new EVPN VPWS service type specifically for
multiplexing multiple attachment circuits across different Ethernet
Segments and physical interfaces into a single EVPN VPWS service
tunnel and still providing Single-Active and All-Active multi-homing.
This new service is referred to as flexible cross-connect service.
After a description of the rationale for this new service type, the
solution to deliver such service is detailed.

"Fast Recovery for EVPN Designated Forwarder Election", Patrice Brissette,

Ali Sajassi, Luc Burdet, John Drake, Jorge Rabadan, 2022-08-24,
<draft-ietf-bess-evpn-fast-df-recovery-06.txt>

The Ethernet Virtual Private Network (EVPN) solution provides

Designated Forwarder election procedures for multihomed Ethernet
Segments. These procedures have been enhanced further by applying
Highest Random Weight (HRW) Algorithm for Designated Forwarded
election in order to avoid unnecessary DF status changes upon a
failure. This document improves these procedures by providing a fast
Designated Forwarder (DF) election upon recovery of the failed link
or node associated with the multihomed Ethernet Segment. The
solution is independent of the number of EVIs associated with that
Ethernet Segment and it is performed via a simple signaling between
the recovered PE and each of the other PEs in the multihoming group.

"EVPN Virtual Ethernet Segment", Ali Sajassi, Patrice Brissette, Rick

Schell, John Drake, Jorge Rabadan, 2021-07-06,
<draft-ietf-bess-evpn-virtual-eth-segment-07.txt>

EVPN and PBB-EVPN introduce a family of solutions for multipoint

Ethernet services over MPLS/IP network with many advanced features
among which their multi-homing capabilities. These solutions
introduce Single-Active and All-Active for an Ethernet Segment (ES),
itself defined as a set of physical links between the multi-homed
device/network and a set of PE devices that they are connected to.
This document extends the Ethernet Segment concept so that an ES can
be associated to a set of EVCs (e.g., VLANs) or other objects such as
MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as
Virtual Ethernet Segments (vES). This draft describes the
requirements and the extensions needed to support vES in EVPN and
PBB-EVPN.

"Weighted Multi-Path Procedures for EVPN Multi-Homing", Neeraj Malhotra,

Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria,
2022-06-01, <draft-ietf-bess-evpn-unequal-lb-16.txt>

EVPN enables all-active multi-homing for a CE device connected to two

or more PEs via a LAG, such that bridged and routed traffic from
remote PEs to hosts attached to the Ethernet Segment can be equally
load balanced (it uses Equal Cost Multi Path) across the multi-homing
PEs. EVPN also enables multi-homing for IP subnets advertised in IP
 Prefix routes, so that routed traffic from remote PEs to those IP
subnets can be load balanced. This document defines extensions to
EVPN procedures to optimally handle unequal access bandwidth
distribution across a set of multi-homing PEs in order to:

* provide greater flexibility, with respect to adding or removing

individual multi-homed PE-CE links.

* handle multi-homed PE-CE link failures that can result in unequal

PE-CE access bandwidth across a set of multi-homing PEs.

"MVPN/EVPN Tunnel Aggregation with Common Labels", Zhaohui Zhang, Eric

Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands, 2022-01-20,
<draft-ietf-bess-mvpn-evpn-aggregation-label-08.txt>

The MVPN specifications allow a single Point-to-Multipoint (P2MP)

tunnel to carry traffic of multiple VPNs. The EVPN specifications
allow a single P2MP tunnel to carry traffic of multiple Broadcast
Domains (BDs). These features require the ingress router of the P2MP
tunnel to allocate an upstream-assigned MPLS label for each VPN or
for each BD. A packet sent on a P2MP tunnel then carries the label
that is mapped to its VPN or BD (in some cases, a distinct upstream-
assigned label is needed for each flow.) Since each ingress router
allocates labels independently, with no coordination among the
ingress routers, the egress routers may need to keep track of a large
number of labels. The number of labels may need to be as large (or
larger) than the product of the number of ingress routers times the
number of VPNs or BDs. However, the number of labels can be greatly
reduced if the association between a label and a VPN or BD is made by
provisioning, so that all ingress routers assign the same label to a
particular VPN or BD. New procedures are needed in order to take
advantage of such provisioned labels. These new procedures also
apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document
updates RFCs 6514, 7432 and 7582 by specifying the necessary
procedures.

"EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, Eric Rosen,
John Drake, Wen Lin, Jim Uttaro, Adam Simpson, 2022-07-06,
<draft-ietf-bess-evpn-ipvpn-interworking-07.txt>

EVPN is used as a unified control plane for tenant network intra and
inter-subnet forwarding. When a tenant network spans not only EVPN
domains but also domains where BGP VPN-IP or IP families provide
inter-subnet forwarding, there is a need to specify the interworking
aspects between BGP domains of type EVPN, VPN-IP and IP, so that the
end to end tenant connectivity can be accomplished. This document
specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6
BGP families for inter-subnet forwarding. The document also
addresses the interconnect of EVPN domains for Inter-Subnet
Forwarding routes. In addition, this specification defines a new BGP
Path Attribute called D-PATH (Domain PATH) that protects gateways
against control plane loops. D-PATH modifies the BGP best path
selection for multiprotocol BGP routes of SAFI 1, 128 and EVPN IP
Prefix routes, and therefore this document updates [RFC4271].

"Extended Mobility Procedures for EVPN-IRB", Neeraj Malhotra, Ali Sajassi,

Aparna Pattekar, Jorge Rabadan, Avinash Lingala, John Drake, 2022-04-19,
<draft-ietf-bess-evpn-irb-extended-mobility-08.txt>
 Procedure to handle host mobility in a layer 2 Network with EVPN
control plane is defined as part of RFC 7432. EVPN has since evolved
to find wider applicability across various IRB use cases that include
distributing both MAC and IP reachability via a common EVPN control
plane. MAC Mobility procedures defined in RFC 7432 are extensible to
IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed
across VM moves. Generic mobility support for IP and MAC that allows
these bindings to change across moves is required to support a
broader set of EVPN IRB use cases, and requires further
consideration. EVPN all-active multi-homing further introduces
scenarios that require additional consideration from mobility
perspective. This document enumerates a set of design considerations
applicable to mobility across these EVPN IRB use cases and defines
generic sequence number assignment procedures to address these IRB
use cases.

"LSP-Ping Mechanisms for EVPN and PBB-EVPN", Parag Jain, Ali Sajassi, Samer
Salam, Sami Boutros, Greg Mirsky, 2022-07-08,
<draft-ietf-bess-evpn-lsp-ping-08.txt>

LSP Ping is a widely deployed Operation, Administration, and

Maintenance mechanism in MPLS networks. This document describes
mechanisms for detecting data plane failures using LSP Ping in MPLS
based EVPN and PBB-EVPN networks.

"EVPN control plane for Geneve", Sami Boutros, Ali Sajassi, John Drake,
Jorge Rabadan, Sam Aldrin, 2022-05-23, <draft-ietf-bess-evpn-geneve-04.txt>

This document describes how Ethernet VPN (EVPN) control plane can be
used with Network Virtualization Overlay over Layer 3 (NVO3) Generic
Network Virtualization Encapsulation (Geneve) encapsulation for NVO3
solutions.

EVPN control plane can also be used by Network Virtualization Edges

(NVEs) to express Geneve tunnel option TLV(s) supported in the
transmission and/or reception of Geneve encapsulated data packets.

"PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran

Nagaraj, Masahiro Miyake, Taku Matsuda, 2022-06-23,
<draft-ietf-bess-pbb-evpn-isid-cmacflush-05.txt>

Provider Backbone Bridging (PBB) can be combined with Ethernet VPN

(EVPN) to deploy Ethernet Local Area Network (ELAN) services in large
Multi-Protocol Label Switching (MPLS) networks (PBB-EVPN). Single-
Active Multi-homing and per-I-SID (per Service Instance Identifier)
Load-Balancing can be provided to access devices and aggregation
networks. In order to speed up the network convergence in case of
failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN
defines a flush mechanism for Customer MACs (CMAC-flush) that works
for different Ethernet Segment Backbone MAC (BMAC) address allocation
models. This document complements those CMAC-flush procedures for
cases in which no PBB-EVPN Ethernet Segments are defined (the
attachment circuit is associated to a zero Ethernet Segment
Identifier) and a Service Instance Identifier based (I-SID-based)
CMAC-flush granularity is required.

"Seamless Multicast Interoperability between EVPN and MVPN PEs", Ali

Sajassi, Kesavan Thiruvenkatasamy, Samir Thoria, Ashutosh Gupta, Luay
Jalil, 2022-06-28, <draft-ietf-bess-evpn-mvpn-seamless-interop-04.txt>
 Ethernet Virtual Private Network (EVPN) solution is becoming
pervasive for Network Virtualization Overlay (NVO) services in data
center (DC) networks and as the next generation VPN services in
service provider (SP) networks.

As service providers transform their networks in their Central

Offices (COs) towards the next generation data center with Software
Defined Networking (SDN) based fabric and Network Function
Virtualization (NFV), they want to be able to maintain their offered
services including Multicast VPN (MVPN) service between their
existing network and their new Service Provider Data Center (SPDC)
network seamlessly without the use of gateway devices. They want to
have such seamless interoperability between their new SPDCs and their
existing networks for a) reducing cost, b) having optimum forwarding,
and c) reducing provisioning. This document describes a unified
solution based on RFCs 6513 & 6514 for seamless interoperability of
Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes
how the proposed solution can be used as a routed multicast solution
in data centers with only EVPN PEs.

"Controller Based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk,

Dante Pacella, Arkadiy Gulko, 2022-04-11,
<draft-ietf-bess-bgp-multicast-controller-09.txt>

This document specifies a way that one or more centralized

controllers can use BGP to set up multicast distribution trees
(identified by either IP source/destination address pair, mLDP FEC,
or SR-P2MP Tree-ID) in a network. Since the controllers calculate
the trees, they can use sophisticated algorithms and constraints to
achieve traffic engineering. The controllers directly signal dynamic
replication state to tree nodes, leading to very simple multicast
control plane on the tree nodes, as if they were using static routes.
This can be used for both underlay and overlay multicast trees,
including replacing BGP-MVPN signaling.

"EVPN multi-homing port-active load-balancing", Patrice Brissette, Ali

Sajassi, Luc Burdet, Samir Thoria, Bin Wen, Eddie Leyton, Jorge Rabadan,
2022-06-10, <draft-ietf-bess-evpn-mh-pa-06.txt>

The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables

establishing a logical link-aggregation connection with a redundant
group of independent nodes. The purpose of multi-chassis LAG is to
provide a solution to achieve higher network availability, while
providing different modes of sharing/balancing of traffic. RFC7432
defines EVPN based MC-LAG with single-active and all-active
multi-homing load-balancing mode. The current draft expands on
existing redundancy mechanisms supported by EVPN and introduces
support for port-active load-balancing mode.

"Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin,

Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2022-07-08,
<draft-ietf-bess-extended-evpn-optimized-ir-02.txt>

[EVPN-AR] specifies an optimized ingress replication solution for

more efficient multicast and broadcast delivery in a Network
Virtualization Overlay (NVO) network for EVPN.

This document extends the optimized ingress replication procedures

 specified in [EVPN-AR] to overcome the limitation that an AR-
REPLICATOR may have. An AR-REPLICATOR may be unable to retain the
source IP address or include the expected ESI label that is required
for EVPN split horizon filtering when replicating the packet on
behalf of its multihomed AR-LEAF. Under this circumstance, the
extended procedures specified in this document allows the support of
EVPN multihoming on the AR-LEAFs as well as optimized ingress
replication for the rest of the EVPN overlay network.

"BGP Usage for SDWAN Overlay Networks", Linda Dunbar, Jim Guichard, Ali
Sajassi, John Drake, Basil Najem, David Carrel, 2022-04-18,
<draft-ietf-bess-bgp-sdwan-usage-05.txt>

The document discusses the usage and applicability of BGP as the

control plane for multiple SDWAN scenarios. The document aims to
demonstrate how the BGP-based control plane is used for large-scale
SDWAN overlay networks with little manual intervention.

SDWAN edge nodes are commonly interconnected by multiple types of

underlay networks owned and managed by different network providers.

"EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan,

Kiran Nagaraj, Wen Lin, Ali Sajassi, 2022-06-23,
<draft-ietf-bess-evpn-mh-split-horizon-03.txt>

Ethernet Virtual Private Network (EVPN) is commonly used along with

Network Virtualization Overlay (NVO) tunnels, as well as MPLS and
Segment Routing tunnels. The EVPN multi-homing procedures may be
different depending on the tunnel type used in the EVPN Broadcast
Domain. In particular, there are two multi-homing Split Horizon
procedures to avoid looped frames on the multi-homed CE: ESI Label
based and Local Bias. ESI Label based Split Horizon is used for
MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for
others, E.g., VXLAN tunnels. The existing specifications do not
allow the operator to decide which Split Horizon procedure to use for
tunnel encapsulations that could support both. Examples of tunnels
that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or
SRv6. This document extends the EVPN Multi-Homing procedures so that
an operator can decide the Split Horizon procedure for a given tunnel
depending on their own requirements.

"Multicast and Ethernet VPN with Segment Routing P2MP and Ingress
Replication", Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran,
Hooman Bidgoli, Dan Voyer, Zhaohui Zhang, 2022-07-02,
<draft-ietf-bess-mvpn-evpn-sr-p2mp-06.txt>

A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries

traffic from a Root to a set of Leaves. This document describes
extensions to BGP encodings and procedures for P2MP trees and Ingress
Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment
Routing domain.

"BGP MPLS-Based Ethernet VPN", Ali Sajassi, Luc Burdet, John Drake, Jorge
Rabadan, 2022-03-07, <draft-ietf-bess-rfc7432bis-04.txt>

This document describes procedures for BGP MPLS-based Ethernet VPNs

(EVPN). The procedures described here meet the requirements
specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".
 Note to Readers

_RFC EDITOR: please remove this section before publication_

The complete and detailed set of all changes between this version and
RFC7432 may be found as an Annotated Diff (rfcdiff) here
(https://tools.ietf.org/rfcdiff?url1=https://www.rfc-
editor.org/rfc/rfc7432.txt&url2=https://www.ietf.org/archive/id/
draft-ietf-bess-rfc7432bis-04.txt).

"EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols", Patrice

Brissette, Ali Sajassi, Luc Burdet, Dan Voyer, 2022-03-07,
<draft-ietf-bess-evpn-l2gw-proto-01.txt>

The existing EVPN multi-homing load-balancing modes defined are

Single-Active and All-Active. Neither of these multi-homing
mechanisms adequately represent ethernet-segments facing access
networks with Layer-2 Gateway protocols such as G.8032, (M)STP, REP,
MPLS-TP, etc. These loop-preventing Layer-2 protocols require a new
multi-homing mechanism defined in this draft.

"IPv6-Only PE Design for IPv4-NLRI with IPv6-NH", Gyan Mishra, Mankamana

Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong
Chen, 2022-03-20, <draft-ietf-bess-ipv6-only-pe-design-02.txt>

As Enterprises and Service Providers upgrade their brown field or

green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-
BGP)now plays an important role in the transition of their Provider
(P) core network as well as Provider Edge (PE) Edge network from IPv4
to IPv6. Operators must be able to continue to support IPv4
customers when both the Core and Edge networks are IPv6-Only.

This document details an important External BGP (eBGP) PE-CE Edge and
Inter-AS IPv6-Only peering design that leverages the MP-BGP
capability exchange by using IPv6 peering as pure transport, allowing
both IPv4 Network Layer Reachability Information (NLRI) and IPv6
Network Layer Reachability Information (NLRI)to be carried over the
same (Border Gateway Protocol) BGP TCP session. The design change
provides the same Dual Stacking functionality that exists today with
separate IPv4 and IPv6 BGP sessions as we have today. With this
design change from a control plane perspective a single IPv6 is
required for both IPv4 and IPv6 routing updates and from a data plane
forwarindg perspective an IPv6 address need only be configured on the
PE and CE interface for both IPv4 and IPv6 packet forwarding.

This document provides a much needed solution for Internet Exchange

Point (IXP) that are facing IPv4 address depletion at large peering
points. With this design, IXP can now deploy PE-CE IPv6-Only eBGP
Edge or Inter-AS peering design to eliminate IPv4 provisioning at the
Edge. This core and edge IPv6-Only peering design paradigm change
can apply to any eBGP peering, public internet or private, which can
be either Core networks, Data Center networks, Access networks or can
be any eBGP peering scenario. This document provides vendor specific
test cases for the IPv6-Only peering design as well as test results
for the five major vendors stakeholders in the routing and switching
indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test
results provided for the IPv6-Only Edge peering design, the goal is
that all other vendors around the world that have not been tested
will begin to adopt and implement this new Best Current Practice for
 eBGP IPv6-Only Edge peering.

As this issue with IXP IPv4 address depletion is a critical issue

around the world, it is imperative for an immediate solution that can
be implemented quickly. This Best Current Practice IPv6-only eBGP
peering design specification will help proliferate IPv6-Only
deployments at the eBGP Edge network peering points to starting
immediately at a minimum with operators around the world using Cisco,
Juniper, Arista, Nokia and Huawei. As other vendors start to
implement this Best Current Practice, the IXP IPv4 address depletion
gap will eventually be eliminated.

"Cumulative DMZ Link Bandwidth and load-balancing", satyamoh@cisco.com,

Arie Vayner, Akshay Gattani, Ajay Kini, 2022-04-01,
<draft-ietf-bess-ebgp-dmz-00.txt>

The DMZ Link Bandwidth draft provides a way to load-balance traffic

to a destination (which is in a different AS than the source) which
is reachable via more than one path. Typically, the link bandwidth
(either configured on the link of the EBGP egress interface or set
via a policy) is encoded in an extended community and then sent to
the IBGP peer which employs multi-path. The link-bandwidth value is
then extracted from the path extended community and is used as a
weight in the FIB, which does the load-balancing. This draft extends
the usage of the DMZ link bandwidth to another setting where the
ingress BGP speaker requires knowledge of the cumulative bandwidth
while doing the load-balancing. The draft also proposes neighbor-
level knobs to enable the link bandwidth extended community to be
regenerated and then advertised to EBGP peers to override the default
behavior of not advertising optional non-transitive attributes to
EBGP peers.

Bidirectional Forwarding Detection (bfd)

----------------------------------------

"Secure BFD Sequence Numbers", Mahesh Jethanandani, Sonal Agarwal, Ashesh

Mishra, Ankur Saxena, Alan DeKok, 2022-03-29,
<draft-ietf-bfd-secure-sequence-numbers-09.txt>

This document describes two new BFD Authentication mechanism,

Meticulous Keyed ISAAC, and Meticulous Keyed FNV1A. These mechanisms
can be used to authenticate BFD packets, and secure the sequence
number exchange, with less CPU time cost than using MD5 or SHA1, with
the tradeoff of decreased security. This document updates RFC 5880.

"Unsolicited BFD for Sessionless Applications", Enke Chen, Naiming Shen,

Robert Raszuk, Reshad Rahman, 2021-12-03,
<draft-ietf-bfd-unsolicited-09.txt>

For operational simplification of "sessionless" applications using

BFD, in this document we present procedures for "unsolicited BFD"
that allow a BFD session to be initiated by only one side, and be
established without explicit per-session configuration or
registration by the other side (subject to certain per-interface or
per-router policies).

We also introduce a new YANG module to configure and manage

"unsolicited BFD". The YANG module in this document conforms to the
Network Management Datastore Architecture (NMDA) [RFC8342].
 "Unaffiliated BFD Echo", Weiqiang Cheng, Ruixue Wang, Xiao Min, Reshad
Rahman, Raj Boddireddy, 2022-08-01,
<draft-ietf-bfd-unaffiliated-echo-05.txt>

Bidirectional Forwarding Detection (BFD) is a fault detection

protocol that can quickly determine a communication failure between
two forwarding engines. This document proposes a use of the BFD Echo
where the local system supports BFD but the neighboring system does
not support BFD.

This document updates RFC 5880.

"YANG Data Model for Bidirectional Forwarding Detection (BFD)", Mahesh

Jethanandani, Reshad Rahman, Lianshu Zheng, Santosh Pallagatti, Greg
Mirsky, 2022-04-06, <draft-ietf-bfd-rfc9127-bis-04.txt>

This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).

The YANG modules in this document conform to the Network Management

Datastore Architecture (NMDA) (RFC 8342). This document updates YANG
Data Model for Bidirectional Forwarding Detection (BFD) (RFC 9127).

Bit Indexed Explicit Replication (bier)

---------------------------------------

"Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit
Replication (BIER) Layer", Greg Mirsky, Tony Przygienda, Andrew Dolganow,
2022-04-05, <draft-ietf-bier-path-mtu-discovery-12.txt>

This document describes Path Maximum Transmission Unit Discovery

(PMTUD) in Bit Indexed Explicit Replication (BIER) layer.

"Performance Measurement (PM) with Marking Method in Bit Index Explicit

Replication (BIER) Layer", Greg Mirsky, Lianshu Zheng, Mach Chen, Giuseppe
Fioccola, 2022-03-31, <draft-ietf-bier-pmmm-oam-12.txt>

This document describes the applicability of a hybrid performance

measurement method for packet loss and packet delay measurements of a
multicast service through a Bit Index Explicit Replication domain.

"BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada
Govindan, IJsbrand Wijnands, Zhaohui Zhang, 2022-06-29,
<draft-ietf-bier-bgp-ls-bier-ext-12.txt>

Bit Index Explicit Replication (BIER) is an architecture that

provides optimal multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain any multicast related per-
flow state. BIER also does not require any explicit tree-building
protocol for its operation. A multicast data packet enters a BIER
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
The BFIR router adds a BIER header to the packet. The BIER header
contains a bitstring in which each bit represents exactly one BFER to
forward the packet to. The set of BFERs to which the multicast
packet needs to be forwarded is expressed by setting the bits that
correspond to those routers in the BIER header.
 BGP Link-State (BGP-LS) enables the collection of various topology
informations from the network, and the topology informations are used
by the controller to calculate the fowarding tables and then
propagate them onto the BFRs(instead of having each node to calculate
on its own) and that can be for both inter-as and intra-as
situations.

This document specifies extensions to the BGP Link-state address-

family in order to advertise the BIER informations.

"BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery

Protocols", Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda)
Wang, Zheng Zhang, Markus Stenberg, 2022-07-25, <draft-ietf-bier-mld-07.txt>

This document specifies the ingress part of a multicast flow overlay

for BIER networks. Using existing multicast listener discovery
protocols, it enables multicast membership information sharing from
egress routers, acting as listeners, toward ingress routers, acting
as queriers. Ingress routers keep per-egress-router state, used to
construct the BIER bit mask associated with IP multicast packets
entering the BIER domain.

"EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge
Rabadan, 2022-08-10, <draft-ietf-bier-evpn-07.txt>

This document specifies protocols and procedures for forwarding

broadcast, unknown unicast and multicast (BUM) traffic of Ethernet
VPNs (EVPN) using Bit Index Explicit Replication (BIER).

"Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Toerless

Eckert, Michael Menth, Gregory Cauchie, 2022-04-25,
<draft-ietf-bier-te-arch-13.txt>

This memo describes per-packet stateless strict and loose path

steered replication and forwarding for "Bit Index Explicit
Replication" (BIER, RFC8279) packets. It is called BIER Tree
Engineering (BIER-TE) and is intended to be used as the path steering
mechanism for Traffic Engineering with BIER.

BIER-TE introduces a new semantic for "bit positions" (BP). They

indicate adjacencies of the network topology, as opposed to (non-TE)
BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFER). A
BIER-TE packets BitString therefore indicates the edges of the (loop-
free) tree that the packet is forwarded across by BIER-TE. BIER-TE
can leverage BIER forwarding engines with little changes. Co-
existence of BIER and BIER-TE forwarding in the same domain is
possible, for example by using separate BIER "sub-domains" (SDs).
Except for the optional routed adjacencies, BIER-TE does not require
a BIER routing underlay, and can therefore operate without depending
on an "Interior Gateway Routing protocol" (IGP).

"BIER Underlay Path Calculation Algorithm and Constraints", Zhaohui Zhang,

Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands,
Arkadiy Gulko, 2022-05-12, <draft-ietf-bier-bar-ipa-13.txt>

This document specifies general rules for the interaction between the
BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
path calculation. The semantics defined in this document update
RFC8401 and RFC8444. This document also updates the BIER Algorithm
 registry established in RFC8401.

"A YANG data model for Tree Engineering for Bit Index Explicit Replication
(BIER-TE)", Zheng Zhang, Cui(Linda) Wang, Ran Chen, fangwei hu, Mahesh
Sivakumar, chenhuanan, 2022-05-01, <draft-ietf-bier-te-yang-05.txt>

This document defines a YANG data model for Tree Engineering for Bit
Index Explicit Replication (BIER-TE) configuration and operation.

"OSPFv3 Extensions for BIER", Peter Psenak, Nagendra Nainar, IJsbrand

Wijnands, 2021-11-19, <draft-ietf-bier-ospfv3-extensions-05.txt>

Bit Index Explicit Replication (BIER) is an architecture that

provides multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain multicast related per-flow
state. Neither does BIER require an explicit tree-building protocol
for its operation. A multicast data packet enters a BIER domain at a
"Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router
adds a BIER header to the packet. Such header contains a bit-string
in which each bit represents exactly one BFER to forward the packet
to. The set of BFERs to which the multicast packet needs to be
forwarded is expressed by the according set of bits set in BIER
packet header.

This document describes the OSPFv3 [RFC8362] protocol extensions

required for BIER with MPLS encapsulation [RFC8296]. Support for
other encapsulation types is outside the scope of this document. The
use of multiple encapsulation types is outside the scope of this
document.

"BIER Prefix Redistribute", Zheng Zhang, Bo Wu, Zhaohui Zhang, IJsbrand

Wijnands, Yisong Liu, Hooman Bidgoli, 2022-07-03,
<draft-ietf-bier-prefix-redistribute-02.txt>

This document defines a BIER proxy function to support a single BIER

sub-domain over multiple underlay routing protocol regions
(Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is
defined to redistribute BIER BFR-id information across the routing
regions.

"BIER BFD", Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu, 2022-05-05,
<draft-ietf-bier-bfd-02.txt>

Point to multipoint (P2MP) BFD is designed to verify multipoint

connectivity. This document specifies the application of P2MP BFD in
BIER network.

"BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover",

Zheng Zhang, Greg Mirsky, Quan Xiong, Yisong Liu, Huanan Li, 2022-04-24,
<draft-ietf-bier-source-protection-02.txt>

This document describes a failover in the Bit Index Explicit

Replication domain with a redundant ingress router.

"OSPF Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan
Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-07-29,
<draft-ietf-bier-te-ospf-01.txt>
 This document describes OSPF extensions for distributing BitPositions
configured on the links in "Bit Index Explicit Replication Traffic
Engineering" (BIER-TE) domain.

"IS-IS Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang, Gyan
Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-08-02,
<draft-ietf-bier-te-isis-02.txt>

This document describes IS-IS extensions for distributing

BitPositions configured on the links in "Bit Index Explicit
Replication Traffic Engineering" (BIER-TE) domain.

"OSPFv3 Extensions for BIER-TE", Huaimo Chen, Mike McBride, Aijun Wang,
Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-07-05,
<draft-ietf-bier-te-ospfv3-01.txt>

This document describes OSPFv3 extensions for distributing

BitPositions configured on the links in "Bit Index Explicit
Replication Traffic Engineering" (BIER-TE) domain.

"Multicast/BIER As A Service", Zhaohui Zhang, Eric Rosen, Daniel Awduche,

Greg Shepherd, Zheng Zhang, Gyan Mishra, 2022-07-11,
<draft-ietf-bier-multicast-as-a-service-01.txt>

This document describes a framework for providing multicast as a

service via Bit Index Explicit Replication (BIER) [RFC7279], and
specifies a few enhancements to [draft-ietf-bier-idr-extensions]
[RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service.

"BIER Fast ReRoute", Huaimo Chen, Mike McBride, Steffen Lindner, Michael
Menth, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu,
2022-07-24, <draft-ietf-bier-frr-00.txt>

BIER is a scalable multicast overlay [RFC8279] that utilizes a

routing underlay, e.g., IP, to build up its Bit Index Forwarding
Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-
FRR). It protects BIER traffic after detecting the failure of a link
or node in the core of a BIER domain until affected BIFT entries are
recomputed after reconvergence of the routing underlay. BIER-FRR is
applied locally at the point of local repair (PLR) and does not
introduce any per-flow state. The document specifies nomenclature
for BIER-FRR and gives examples for its integration in BIER
forwarding. Furthermore, it presents operation modes for BIER-FRR.
Link and node protection may be chosen as protection level.
Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based
BIER-FRR are defined and compared.

Benchmarking Methodology (bmwg)

-------------------------------

"Benchmarking Methodology for Network Security Device Performance",

Balamuhunthan Balarajah, Carsten Rossenhoevel, bmonkman, 2022-01-12,
<draft-ietf-bmwg-ngfw-performance-13.txt>

This document provides benchmarking terminology and methodology for

next-generation network security devices including next-generation
firewalls (NGFW), next-generation intrusion prevention systems
(NGIPS), and unified threat management (UTM) implementations. The
main areas covered in this document are test terminology, test
 configuration parameters, and benchmarking methodology for NGFW and
NGIPS. This document aims to improve the applicability,
reproducibility, and transparency of benchmarks and to align the test
methodology with today's increasingly complex layer 7 security
centric network application use cases. As a result, this document
makes [RFC3511] obsolete.

"Multiple Loss Ratio Search for Packet Throughput (MLRsearch)", Maciek

Konstantynowicz, Vratko Polak, 2022-03-07,
<draft-ietf-bmwg-mlrsearch-02.txt>

TODO: Update after all sections are ready.

This document proposes changes to [RFC2544], specifically to packet

throughput search methodology, by defining a new search algorithm
referred to as Multiple Loss Ratio search (MLRsearch for short).
Instead of relying on binary search with pre-set starting offered
load, it proposes a novel approach discovering the starting point in
the initial phase, and then searching for packet throughput based on
defined packet loss ratio (PLR) input criteria and defined final
trial duration time. One of the key design principles behind
MLRsearch is minimizing the total test duration and searching for
multiple packet throughput rates (each with a corresponding PLR)
concurrently, instead of doing it sequentially.

The main motivation behind MLRsearch is the new set of challenges and
requirements posed by NFV (Network Function Virtualization),
specifically software based implementations of NFV data planes.
Using [RFC2544] in the experience of the authors yields often not
repetitive and not replicable end results due to a large number of
factors that are out of scope for this draft. MLRsearch aims to
address this challenge in a simple way of getting the same result
sooner, so more repetitions can be done to describe the
replicability.

"A YANG Data Model for Network Tester Management", Vladimir Vassilev,
2022-06-17, <draft-ietf-bmwg-network-tester-cfg-00.txt>

This document introduces new YANG model for use in network

interconnect testing containing modules of traffic generator and
traffic analyzer.

Calendaring Extensions (calext)

-------------------------------

"JSCalendar: Converting from and to iCalendar", Robert Stepanek, Michael

Douglass, 2022-07-11, <draft-ietf-calext-jscalendar-icalendar-07.txt>

This document provides the required methods for converting JSCalendar

from and to iCalendar.

"Calendar subscription upgrades", Michael Douglass, 2022-03-22,

<draft-ietf-calext-subscription-upgrade-06.txt>

This specification updates RFC5545 to add the value DELETED to the

STATUS property.

This specification also adds values to the Preferences Registry

defined in RFC7240 to add the subscribe-enhanced-get and limit
 preferences and to the link relations directory defined in RFC8288.

"VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Michael

Douglass, 2022-03-05, <draft-ietf-calext-vpoll-03.txt>

This specification introduces a new RFC5545 iCalendar component which

allows for consensus scheduling, that is, voting on a number of
alternative meeting or task alternatives.

"JSContact: A JSON representation of contact data", Robert Stepanek, Mario

Loffredo, 2022-07-11, <draft-ietf-calext-jscontact-03.txt>

This specification defines a data model and JSON representation of

contact card information that can be used for data storage and
exchange in address book or directory applications. It aims to be an
alternative to the vCard data format and to be unambiguous,
extendable and simple to process. In contrast to the JSON-based
jCard format, it is not a direct mapping from the vCard data model
and expands semantics where appropriate.

"Serverside Subscriptions", Michael Douglass, 2022-03-07,

<draft-ietf-calext-serverside-subscriptions-02.txt>

This specification provides a mechanism whereby subscriptions to

external resources can be handled by the server.

This specification updates RFC4791 to add new properties for the

MKCOL request.

"Task Extensions to iCalendar", Adrian Apthorp, Michael Douglass,

2022-03-22, <draft-ietf-calext-ical-tasks-03.txt>

This document defines extensions to the Internet Calendaring and

Scheduling Core Object Specification (iCalendar) (RFC5545) to provide
improved status tracking, scheduling and specification of tasks.

It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC

4791) servers can be extended to support certain automated task
management behaviours.

"JSContact: Converting from and to vCard", Mario Loffredo, Robert Stepanek,

2022-07-11, <draft-ietf-calext-jscontact-vcard-02.txt>

This document defines how to convert contact information as defined

in the JSContact [I-D.ietf-calext-jscontact] specification from and
to vCard.

"JSCalendar: A JSON Representation of Calendar Data", Neil Jenkins, Robert

Stepanek, 2022-07-11, <draft-ietf-calext-jscalendarbis-00.txt>

This specification defines a data model and JSON representation of

calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment. It aims to be an alternative
and, over time, successor to the widely deployed iCalendar data
format. It also aims to be unambiguous, extendable, and simple to
process. In contrast to the jCal format, which is also based on
JSON, JSCalendar is not a direct mapping from iCalendar but defines
the data model independently and expands semantics where appropriate.
This specification obsoletes [RFC8984].
 "iCalendar Format Extension for JSCalendar", Robert Stepanek, Michael
Douglass, 2022-07-11,
<draft-ietf-calext-icalendar-jscalendar-extensions-00.txt>

This document defines a set of new properties for iCalendar and

extends the use of existing ones. Their primary purpose is to align
the same set of features between the JSCalendar and iCalendar
formats, but the new definitions also aim to be useful within just
the iCalendar format.

"vCard Format Extension for JSContact", Robert Stepanek, Mario Loffredo,

2022-07-11, <draft-ietf-calext-vcard-jscontact-extensions-00.txt>

This document defines a set of new properties for vCard and extends
the use of existing ones. Their primary purpose is to align the same
set of features between the JSContact and vCard formats, but the new
definitions also aim to be useful within just the vCard format.

Concise Binary Object Representation Maintenance and Extensions (cbor)

----------------------------------------------------------------------

"Packed CBOR", Carsten Bormann, 2022-07-24, <draft-ietf-cbor-packed-07.txt>

The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94)
is a data format whose design goals include the possibility of
extremely small code size, fairly small message size, and
extensibility without the need for version negotiation.

CBOR does not provide any forms of data compression. CBOR data
items, in particular when generated from legacy data models, often
allow considerable gains in compactness when applying data
compression. While traditional data compression techniques such as
DEFLATE (RFC 1951) can work well for CBOR encoded data items, their
disadvantage is that the receiver needs to decompress the compressed
form to make use of the data.

This specification describes Packed CBOR, a simple transformation of

a CBOR data item into another CBOR data item that is almost as easy
to consume as the original CBOR data item. A separate decompression
step is therefore often not required at the receiver.

// The present version (-07) adds the concept of Tag Equivalence as

// initially discussed at the CBOR Interim meeting 12 in 2022 and
// further in PR #6, for discussion before and at IETF 114.

"Concise Binary Object Representation (CBOR) Tags for Time, Duration, and
Period", Carsten Bormann, Ben Gamari, Henk Birkholz, 2022-07-27,
<draft-ietf-cbor-time-tag-01.txt>

The Concise Binary Object Representation (CBOR, RFC 8949) is a data

format whose design goals include the possibility of extremely small
code size, fairly small message size, and extensibility without the
need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags.

RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a
string) and tag 1 (Posix time as int or float). Since then,
 additional requirements have become known. The present document
defines a CBOR tag for time that allows a more elaborate
representation of time, as well as related CBOR tags for duration and
time period. It is intended as the reference document for the IANA
registration of the CBOR tags defined.

// The present version (-01) adds a trial balloon (Sections 3.6 and
// 3.7) for providing a way to include, in time tags, the hints
// defined in draft-ietf-sedate-datetime-extended. This trial
// balloon is intended for discussion at and around IETF 114.

Common Control and Measurement Plane (ccamp)

--------------------------------------------

"A YANG Data Model for Optical Transport Network Topology", Haomian Zheng,
Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios, 2022-07-11,
<draft-ietf-ccamp-otn-topo-yang-15.txt>

This document describes a YANG data model to describe the topologies

of an Optical Transport Network (OTN). It is independent of control
plane protocols and captures topological and resource related
information pertaining to OTN. This model enables clients, which
interact with a transport domain controller, for OTN topology related
operations such as obtaining the relevant topology resource
information.

"OTN Tunnel YANG Model", Haomian Zheng, Italo Busi, Sergio Belotti, Victor
Lopez, Yunbin Xu, 2022-04-08, <draft-ietf-ccamp-otn-tunnel-model-16.txt>

This document describes the YANG data model for tunnels in OTN TE
networks. The model can be used to do the configuration in order to
establish the tunnel in OTN network. This work is independent with
the control plane protocols.

"A YANG Data Model for Flexi-Grid Optical Networks", Universidad de Madrid,
Daniel Burrero, Daniel King, Young Lee, Haomian Zheng, 2022-07-10,
<draft-ietf-ccamp-flexigrid-yang-13.txt>

This document defines a YANG module for managing flexi-grid optical

networks. The model defined in this document specifies a flexi-grid
traffic engineering database that is used to describe the topology of
a flexi-grid network. It is based on and augments existing YANG
models that describe network and traffic engineering topologies.

The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"A Yang Data Model for WSON Tunnel", Young Lee, Haomian Zheng, Aihua Guo,
Victor Lopez, Daniel King, Bin-Yeong Yoon, Ricard Vilalta, 2022-07-11,
<draft-ietf-ccamp-wson-tunnel-model-07.txt>

This document provides a YANG data model for WSON TE tunnel.

"Transport Northbound Interface Applicability Statement", Italo Busi,

Daniel King, Haomian Zheng, Yunbin Xu, 2022-07-04,
<draft-ietf-ccamp-transport-nbi-app-statement-15.txt>

This document provides an analysis of the applicability of the YANG

 models defined by the IETF (in particular in the Traffic Engineering
Architecture and Signaling (TEAS) and Common Control and Measurement
Plane (CCAMP) working groups) to support ODU transit services,
transparent client services, and Ethernet Private Line/Ethernet
Virtual Private Line (EPL/EVPL) services over Optical Transport
Network (OTN) in single and multi-domain network scenarios.

This document also describes how existing YANG models can be used
through several worked examples and JSON fragments.

"A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee,
Kwang-koog Lee, Haomian Zheng, Oscar de Dios, Daniele Ceccarelli,
2022-07-10, <draft-ietf-ccamp-l1csm-yang-17.txt>

This document provides a YANG data model for Layer 1 Connectivity

Service Model (L1CSM). The intent of this document is to provide a
Layer 1 service model exploiting YANG data model, which can be
utilized by a customer network controller to initiate a service
request connectivity as well as retrieving service states toward a
Layer 1 network controller communicating with its customer network
controller. This YANG model is NMDA-compliant.

"A YANG Data Model for Microwave Topology", Jonas Ahlberg, Scott Mansfield,
Min Ye, Italo Busi, Xi Li, Daniela Spreafico, 2022-07-09,
<draft-ietf-ccamp-mw-topo-yang-03.txt>

This document defines three YANG data models to describe topologies

of microwave/millimeter radio links and bandwidth availability for a
link in general, as well as to reference interface management
information from a termination point.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang.

"Applicability of GMPLS for Beyond 100G Optical Transport Network", Qilei

Wang, Radha Valiveti, Haomian Zheng, Huub van Helvoort, Sergio Belotti,
2022-05-10, <draft-ietf-ccamp-gmpls-otn-b100g-applicability-09.txt>

This document examines the applicability of using existing GMPLS

routing and signalling mechanisms to set up Optical Data Unit-k
(ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn)
links as defined in the 2020 version of G.709.

"Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense

Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the
application code of optical interface parameters in DWDM application",
Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze,
Dieter Beller, 2022-07-01, <draft-ietf-ccamp-dwdm-if-lmp-06.txt>

This memo defines extensions to LMP [RFC4209] for managing Optical

parameters associated with Wavelength Division Multiplexing (WDM)
systems in accordance with the Interface Application Identifier
approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and
its extensions.
"A YANG model to manage the optical interface parameters for an external
transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze, Andreas
Burk, Dharini Hiremagalur, Gert Grammel, 2022-07-11,
<draft-ietf-ccamp-dwdm-if-param-yang-07.txt>

This memo defines a Yang model related to the Optical Transceiver

parameters characterising coherent 100G and above interfaces. 100G
and above Transceivers support coherent modulation, multiple
modulation formats, multiple FEC codes including some not yet
specified (or by in phase of specification by) ITU-T G.698.2
[ITU.G698.2] or any other ITU-T recommendation. Use cases are
described in RFC7698.

The Yang model defined in this memo can be used for Optical
Parameters monitoring and/or configuration of the endpoints of a
multi-vendor IaDI optical link. The use of this model does not
guarantee interworking of transceivers over a DWDM. Optical path
feasibility and interoperability has to be determined by tools and
algorithms outside the scope of this document. The purpose of this
model is to program interface parameters to consistently configure
the mode of operation of transceivers.

"A YANG Data Model for Optical Impairment-aware Topology", Dieter Beller,
Esther Le Rouzic, Sergio Belotti, Gabriele Galimberti, Italo Busi,
2022-07-11, <draft-ietf-ccamp-optical-impairment-topology-yang-10.txt>

In order to provision an optical connection through optical networks,

a combination of path continuity, resource availability, and
impairment constraints must be met to determine viable and optimal
paths through the network. The determination of appropriate paths is
known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
for WSON, while it is known as Impairment-Aware Routing and Spectrum
Assigment (IA-RSA) for SSON.

This document provides a YANG data model for the impairment-aware TE

topology in optical networks.

"A YANG Data Model for Transport Network Client Signals", Haomian Zheng,
Aihua Guo, Italo Busi, Anton Snitser, Francesco Lazzeri, 2022-07-10,
<draft-ietf-ccamp-client-signal-yang-07.txt>

A transport network is a server-layer network to provide connectivity

services to its client. The topology and tunnel information in the
transport layer has already been defined by generic Traffic-
engineered models and technology-specific models (e.g., OTN, WSON).
However, how the client signals are accessing to the network has not
been described. These information is necessary to both client and
provider.

This draft describes how the client signals are carried over
transport network and defines YANG data models which are required
during configuration procedure. More specifically, several client
signal (of transport network) models including ETH, STM-n, FC and so
on, are defined in this draft.

"A YANG Data Model for Layer 1 Types", Haomian Zheng, Italo Busi,
2022-07-11, <draft-ietf-ccamp-layer1-types-14.txt>

This document defines a collection of common data types and groupings

 in the YANG data modeling language for use with layer 1 networks.
These derived common types and groupings are intended to be imported
by modules that specify OTN networks, such as topology, tunnel,
client signal adaptation and service.

"A YANG Data Model for Ethernet TE Topology", Haomian Zheng, Aihua Guo,
Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2022-03-07,
<draft-ietf-ccamp-eth-client-te-topo-yang-02.txt>

A transport network is a server-layer network to provide connectivity

services to its client. In this draft the topology of Ethernet with
TE is described with YANG data model.

"A YANG Data Model for Flexi-Grid Tunnels", Universidad de Madrid, Daniel
Burrero, Daniel King, Victor Lopez, Italo Busi, Sergio Belotti, Gabriele
Galimberti, 2022-07-11, <draft-ietf-ccamp-flexigrid-tunnel-yang-01.txt>

This document defines a YANG model for managing flexi-grid optical

tunnels (media-channels), complementing the information provided by
the flexi-grid topology model.

The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"Framework and Data Model for OTN Network Slicing", Aihua Guo, Luis
Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu,
2022-07-11, <draft-ietf-ccamp-yang-otn-slicing-02.txt>

The requirement of slicing network resources with desired quality of

service is emerging at every network technology, including the
Optical Transport Networks (OTN). As a part of the transport
network, OTN can provide hard pipes with guaranteed data isolation
and deterministic low latency, which are highly demanded in the
Service Level Agreement (SLA).

This document describes a framework for OTN network slicing and a

YANG data model augmentation of the OTN topology model. Additional
YANG data model augmentations will be defined in a future version of
this draft.

"A YANG Data Model for Layer 0 Types", Haomian Zheng, Young Lee, Aihua Guo,
Victor Lopez, Daniel King, Dieter Beller, Sergio Belotti, Italo Busi,
Esther Le Rouzic, 2022-07-11, <draft-ietf-ccamp-rfc9093-bis-01.txt>

This document defines a collection of common data types and groupings

in the YANG data modeling language. These derived common types and
groupings are intended to be imported by modules that model Layer 0
optical Traffic Engineering (TE) configuration and state capabilities
such as Wavelength Switched Optical Networks (WSONs) and flexi-grid
Dense Wavelength Division Multiplexing (DWDM) networks.

This document obsoletes RFC 9093.

"YANG Data Model for FlexE Management", Minxue Wang, Liuyan Han, Fan Yang,
Xiaobing NIU, Luis Contreras, Xufeng Liu, 2022-06-28,
<draft-ietf-ccamp-flexe-yang-cm-00.txt>

This document defines a service provider targeted YANG data model for
the configuration and management of a Flex Ethernet (FlexE) network,
 including FlexE group and FlexE client. The YANG module in this
document conforms to the Network Management Datastore Architecture
(NMDA).

Content Delivery Networks Interconnection (cdni)

------------------------------------------------

"CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile,

Sanjay Mishra, 2022-08-25,
<draft-ietf-cdni-interfaces-https-delegation-11.txt>

This document defines a new Footprint and Capabilities metadata

objects to support HTTPS delegation between two or more
interconnected CDNs. Specifically, this document outlines CDNI
Metadata interface objects for delegation method as published in the
ACME-STAR document [RFC9115].

"Content Delivery Network Interconnection (CDNI) Footprint Types:

Subdivision Code and Union", Nir Sopher, Sanjay Mishra, 2022-08-08,
<draft-ietf-cdni-additional-footprint-types-02.txt>

Open Caching architecture is a use case of Content Delivery Networks

Interconnection (CDNI) in which the commercial Content Delivery
Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer
serves as the downstream CDN (dCDN). This document supplements the
CDNI Metadata Footprint Types defined in RFC 8006. The Footprint
Types defined in this document can be used for Footprint objects as
part of the Metadata interface (MI) defined in RFC 8006 or the
Footprint & Capabilities Advertisement interface (FCI) defined in RFC
8008. The document also updates RFC 9241 with relevant ALTO entity
domain types. The defined Footprint Types are derived from
requirements raised by Open Caching but are also applicable to CDNI
use cases in general.

"Content Delivery Network Interconnection (CDNI) Control Interface /

Triggers 2nd Edition", Ori Finkelman, Sanjay Mishra, Nir Sopher,
2022-08-29, <draft-ietf-cdni-ci-triggers-rfc8007bis-02.txt>

This document obsoletes RFC8007. This document describes the part of

the Content Delivery Network Interconnection (CDNI) Control interface
that allows a CDN to trigger activity in an interconnected CDN that
is configured to deliver content on its behalf. The upstream CDN can
use this mechanism to request that the downstream CDN pre-position
metadata or content or to request that it invalidate or purge
metadata or content. The upstream CDN can monitor the status of
activity that it has triggered in the downstream CDN.

"CDNI Metadata for Delegated Credentials", Frederic Fieau, Stephan Emile,

Guillaume Bichot, Christoph Neumann, 2022-07-09,
<draft-ietf-cdni-https-delegation-subcerts-00.txt>

The delivery of content over HTTPS involving multiple CDNs raises

credential management issues. This document defines metadata in CDNI
Control and Metadata interface to setup HTTPS delegation using
Delegated Credentials from an Upstream CDN (uCDN) to a Downstream CDN
(dCDN).

Codec Encoding for LossLess Archiving and Realtime transmission (cellar)

------------------------------------------------------------------------
"FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice,
Jerome Martinez, 2022-05-31, <draft-ietf-cellar-ffv1-v4-19.txt>

This document defines FFV1, a lossless, intra-frame video encoding

format. FFV1 is designed to efficiently compress video data in a
variety of pixel formats. Compared to uncompressed video, FFV1
offers storage compression, frame fixity, and self-description, which
makes FFV1 useful as a preservation or intermediate video format.

"Matroska Media Container Format Specifications", Steve Lhomme, Moritz

Bunkus, Dave Rice, 2022-08-28, <draft-ietf-cellar-matroska-13.txt>

This document defines the Matroska audiovisual container, including

definitions of its structural elements, as well as its terminology,
vocabulary, and application.

"Matroska Media Container Codec Specifications", Steve Lhomme, Moritz

Bunkus, Dave Rice, 2022-04-30, <draft-ietf-cellar-codec-09.txt>

This document defines the Matroska codec mappings, including the

codec ID, layout of data in a Block Element and in an optional
CodecPrivate Element.

"Matroska Media Container Tag Specifications", Steve Lhomme, Moritz Bunkus,

Dave Rice, 2022-04-30, <draft-ietf-cellar-tags-09.txt>

This document defines the Matroska tags, namely the tag names and
their respective semantic meaning.

"Free Lossless Audio Codec", Martijn van Beurden, Andrew Weaver,

2022-08-21, <draft-ietf-cellar-flac-04.txt>

This document defines the Free Lossless Audio Codec (FLAC) format.
FLAC is designed to reduce the amount of computer storage space
needed to store digital audio signals without needing to remove
information in doing so (i.e. lossless). FLAC is free in the sense
that its specification is open, its reference implementation is open-
source and it is not encumbered by any known patent. Compared to
other lossless (audio) coding formats, FLAC is a format with low
complexity and can be coded to and from with little computing
resources. Decoding of FLAC has seen many independent
implementations on many different platforms, and both encoding and
decoding can be implemented without needing floating-point
arithmetic.

"Matroska Media Container Control Track Specifications", Steve Lhomme,

Moritz Bunkus, Dave Rice, 2022-05-01, <draft-ietf-cellar-control-01.txt>

This document defines the Control Track usage found in the Matroska
container.

"Matroska Media Container Chapter Codecs Specifications", Steve Lhomme,

Moritz Bunkus, Dave Rice, 2022-04-30,
<draft-ietf-cellar-chapter-codecs-01.txt>

This document defines common Matroska Chapter Codecs, the basic

Matroska Script and the DVD inspired DVD menu.
Crypto Forum (cfrg)
-------------------

"SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2022-02-08,

<draft-irtf-cfrg-spake2-26.txt>

This document describes SPAKE2 which is a protocol for two parties

that share a password to derive a strong shared key without
disclosing the password. This method is compatible with any group,
is computationally efficient, and SPAKE2 has a security proof. This
document predated the CFRG PAKE competition and it was not selected,
however, given existing use of variants in Kerberos and other
applications it was felt publication was beneficial. Applications
that need a symmetric PAKE (password authenticated key exchange) and
where hashing onto an elliptic curve at execution time is not
possible can use SPAKE2. This document is a product of the Crypto
Forum Research Group (CFRG) in the IRTF.

"Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin,

Dimitrios Papadopoulos, Jan Vcelak, 2022-08-09, <draft-irtf-cfrg-vrf-15.txt>

A Verifiable Random Function (VRF) is the public-key version of a

keyed cryptographic hash. Only the holder of the secret key can
compute the hash, but anyone with the public key can verify the
correctness of the hash. VRFs are useful for preventing enumeration
of hash-based data structures. This document specifies VRF
constructions based on RSA and elliptic curves that are secure in the
cryptographic random oracle model.

This document is a product of the Crypto Forum Research Group (CFRG)

in the IRTF.

"Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick

Sullivan, Riad Wahby, Christopher Wood, 2022-06-15,
<draft-irtf-cfrg-hash-to-curve-16.txt>

This document specifies a number of algorithms for encoding or

hashing an arbitrary string to a point on an elliptic curve. This
document is a product of the Crypto Forum Research Group (CFRG) in
the IRTF.

"Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Alex

Davidson, Armando Faz-Hernandez, Nick Sullivan, Christopher Wood,
2022-08-01, <draft-irtf-cfrg-voprf-12.txt>

An Oblivious Pseudorandom Function (OPRF) is a two-party protocol

between client and server for computing the output of a Pseudorandom
Function (PRF). The server provides the PRF secret key, and the
client provides the PRF input. At the end of the protocol, the
client learns the PRF output without learning anything about the PRF
secret key, and the server learns neither the PRF input nor output.
An OPRF can also satisfy a notion of 'verifiability', called a VOPRF.
A VOPRF ensures clients can verify that the server used a specific
private key during the execution of the protocol. A VOPRF can also
be partially-oblivious, called a POPRF. A POPRF allows clients and
servers to provide public input to the PRF computation. This
document specifies an OPRF, VOPRF, and POPRF instantiated within
standard prime-order groups, including elliptic curves.
"KangarooTwelve", =?utf-8?q?Beno=C3=AEt_Viguier?=, David Wong, Giles Van
Assche, Quynh Dang, Joan Daemen, 2022-08-19,
<draft-irtf-cfrg-kangarootwelve-08.txt>

This document defines the KangarooTwelve eXtendable Output Function

(XOF), a hash function with output of arbitrary length. It provides
an efficient and secure hashing primitive, which is able to exploit
the parallelism of the implementation in a scalable way. It uses
tree hashing over a round-reduced version of SHAKE128 as underlying
primitive.

This document builds up on the definitions of the permutations and of

the sponge construction in [FIPS 202], and is meant to serve as a
stable reference and an implementation guide.

"BLS Signatures", Dan Boneh, Sergey Gorbunov, Riad Wahby, Hoeteck Wee,
Christopher Wood, Zhenfei Zhang, 2022-06-16,
<draft-irtf-cfrg-bls-signature-05.txt>

BLS is a digital signature scheme with aggregation properties. Given

set of signatures (signature_1, ..., signature_n) anyone can produce
an aggregated signature. Aggregation can also be done on secret keys
and public keys. Furthermore, the BLS signature scheme is
deterministic, non-malleable, and efficient. Its simplicity and
cryptographic properties allows it to be useful in a variety of use-
cases, specifically when minimal storage space or bandwidth are
required.

"Additional Parameter sets for LMS Hash-Based Signatures", Scott Fluhrer,

Quynh Dang, 2022-08-19, <draft-fluhrer-lms-more-parm-sets-08.txt>

This note extends LMS (RFC 8554) by defining parameter sets by

including additional hash functions. Hese include hash functions
that result in signatures with significantly smaller than the
signatures using the current parameter sets, and should have
sufficient security.

This document is a product of the Crypto Forum Research Group (CFRG)

in the IRTF.

"CPace, a balanced composable PAKE", Michel Abdalla, Bjoern Haase, Julia

Hesse, 2022-07-24, <draft-irtf-cfrg-cpace-06.txt>

This document describes CPace which is a protocol that allows two

parties that share a low-entropy secret (password) to derive a strong
shared key without disclosing the secret to offline dictionary
attacks. The CPace protocol was tailored for constrained devices, is
compatible with any cyclic group of prime- and non-prime order.

"Usage Limits on AEAD Algorithms", Felix Guenther, Martin Thomson,

Christopher Wood, 2022-07-11, <draft-irtf-cfrg-aead-limits-05.txt>

An Authenticated Encryption with Associated Data (AEAD) algorithm

provides confidentiality and integrity. Excessive use of the same
key can give an attacker advantages in breaking these properties.
This document provides simple guidance for users of common AEAD
functions about how to limit the use of keys in order to bound the
advantage given to an attacker. It considers limits in both single-
and multi-key settings.
"The OPAQUE Asymmetric PAKE Protocol", Daniel Bourdrez, Hugo Krawczyk,
Kevin Lewi, Christopher Wood, 2022-07-06, <draft-irtf-cfrg-opaque-09.txt>

This document describes the OPAQUE protocol, a secure asymmetric

password-authenticated key exchange (aPAKE) that supports mutual
authentication in a client-server setting without reliance on PKI and
with security against pre-computation attacks upon server compromise.
In addition, the protocol provides forward secrecy and the ability to
hide the password from the server, even during password registration.
This document specifies the core OPAQUE protocol and one
instantiation based on 3DH.

"Two-Round Threshold Schnorr Signatures with FROST", Deirdre Connolly,

Chelsea Komlo, Ian Goldberg, Christopher Wood, 2022-08-19,
<draft-irtf-cfrg-frost-08.txt>

In this draft, we present the two-round signing variant of FROST, a

Flexible Round-Optimized Schnorr Threshold signature scheme. FROST
signatures can be issued after a threshold number of entities
cooperate to issue a signature, allowing for improved distribution of
trust and redundancy with respect to a secret key. Further, this
draft specifies signatures that are compatible with [RFC8032].
However, unlike [RFC8032], the protocol for producing signatures in
this draft is not deterministic, so as to ensure protection against a
key-recovery attack that is possible when even only one participant
is malicious.

"RSA Blind Signatures", Frank Denis, Frederic Jacobs, Christopher Wood,

2022-08-06, <draft-irtf-cfrg-rsa-blind-signatures-04.txt>

This document specifies the RSA-based blind signature protocol with

appendix (RSA-BSSA). RSA blind signatures were first introduced by
Chaum for untraceable payments [Chaum83]. It extends RSA-PSS
encoding specified in [RFC8017] to enable blind signature support.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/chris-wood/draft-wood-cfrg-blind-signatures.

"Verifiable Distributed Aggregation Functions", Richard Barnes, Christopher

Patton, Phillipp Schoppmann, 2022-08-24, <draft-irtf-cfrg-vdaf-03.txt>

This document describes Verifiable Distributed Aggregation Functions

(VDAFs), a family of multi-party protocols for computing aggregate
statistics over user measurements. These protocols are designed to
ensure that, as long as at least one aggregation server executes the
protocol honestly, individual measurements are never seen by any
server in the clear. At the same time, VDAFs allow the servers to
detect if a malicious or misconfigured client submitted an input that
would result in an incorrect aggregate result.

"Key Blinding for Signature Schemes", Frank Denis, Edward Eaton, Tancrede
Lepoint, Christopher Wood, 2022-08-02,
<draft-irtf-cfrg-signature-key-blinding-02.txt>
 This document describes extensions to existing digital signature
schemes for key blinding. The core property of signing with key
blinding is that a blinded public key and all signatures produced
using the blinded key pair are independent of the unblinded key pair.
Moreover, signatures produced using blinded key pairs are
indistinguishable from signatures produced using unblinded key pairs.
This functionality has a variety of applications, including Tor onion
services and privacy-preserving airdrop for bootstrapping
cryptocurrency systems.

"The AEGIS family of authenticated encryption algorithms", Frank Denis,

Fabio Scotoni, Samuel Lucas, 2022-08-05, <draft-irtf-cfrg-aegis-aead-00.txt>

This document describes AEGIS-128L and AEGIS-256, two AES-based

authenticated encryption algorithms designed for high-performance
applications.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/jedisct1/draft-aegis-aead.

"Deterministic ECDSA and EdDSA Signatures with Additional Randomness", John

Mattsson, Erik Thormarker, Sini Ruohomaa, 2022-08-08,
<draft-irtf-cfrg-det-sigs-with-noise-00.txt>

Deterministic elliptic-curve signatures such as deterministic ECDSA

and EdDSA have gained popularity over randomized ECDSA as their
security do not depend on a source of high-quality randomness.
Recent research has however found that implementations of these
signature algorithms may be vulnerable to certain side-channel and
fault injection attacks due to their determinism. One countermeasure
to such attacks is to re-add randomness to the otherwise
deterministic calculation of the per-message secret number. This
document updates RFC 6979 and RFC 8032 to recommend constructions
with additional randomness for deployments where side-channel attacks
and fault injection attacks are a concern. The updates are invisible
to the validator of the signature and compatible with existing ECDSA
and EdDSA validators.

Computing in the Network Research Group (coinrg)

------------------------------------------------

"Use Cases for In-Network Computing", Ike Kunze, Klaus Wehrle, Dirk
Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio,
2022-03-07, <draft-irtf-coinrg-use-cases-02.txt>

Computing in the Network (COIN) comes with the prospect of deploying

processing functionality on networking devices, such as switches and
network interface cards. While such functionality can be beneficial
in several contexts, it has to be carefully placed into the context
of the general Internet communication.

This document discusses some use cases to demonstrate how real

applications can benefit from COIN and to showcase essential
requirements that have to be fulfilled by COIN applications.
Constrained RESTful Environments (core)
---------------------------------------

"Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)",

Michael Koster, Ari Keranen, Jaime Jimenez, 2022-05-04,
<draft-ietf-core-coap-pubsub-10.txt>

The Constrained Application Protocol (CoAP), and related extensions

are intended to support machine-to-machine communication in systems
where one or more nodes are resource constrained, in particular for
low power wireless sensor networks. This document defines a publish-
subscribe Broker for CoAP that extends the capabilities of CoAP for
supporting nodes with long breaks in connectivity and/or up-time.

"YANG Schema Item iDentifier (YANG SID)", Michel Veillette, Alexander

Pelov, Ivaylo Petrov, Carsten Bormann, Michael Richardson, 2022-07-26,
<draft-ietf-core-sid-19.txt>

YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
unsigned integers used to identify YANG items, as a more compact
method to identify YANG items that can be used for efficiency and in
constrained environments (RFC 7228). This document defines the
semantics, the registration, and assignment processes of YANG SIDs
for IETF managed YANG modules. To enable the implementation of these
processes, this document also defines a file format used to persist
and publish assigned YANG SIDs.

// The present version (-19) adds in draft text about objectives,

// parties, and roles. This attempts to record discussions at side
// meetings before, at, and after IETF 113.

"Group OSCORE - Secure Group Communication for CoAP", Marco Tiloca, Goeran
Selander, Francesca Palombini, John Mattsson, Jiye Park, 2022-03-07,
<draft-ietf-core-oscore-groupcomm-14.txt>

This document defines Group Object Security for Constrained RESTful

Environments (Group OSCORE), providing end-to-end security of CoAP
messages exchanged between members of a group, e.g., sent over IP
multicast. In particular, the described approach defines how OSCORE
is used in a group communication setting to provide source
authentication for CoAP group requests, sent by a client to multiple
servers, and for protection of the corresponding CoAP responses.
Group OSCORE also defines a pairwise mode where each member of the
group can efficiently derive a symmetric pairwise key with any other
member of the group for pairwise OSCORE communication.

"The Constrained RESTful Application Language (CoRAL)", Christian Amsuess,

Thomas Fossati, 2022-03-07, <draft-ietf-core-coral-05.txt>

The Constrained RESTful Application Language (CoRAL) defines a data

model and interaction model as well as a compact serialization
formats for the description of typed connections between resources on
the Web ("links"), possible operations on such resources ("forms"),
and simple resource metadata.

"Constrained Resource Identifiers", Carsten Bormann, Henk Birkholz,

2022-03-07, <draft-ietf-core-href-10.txt>
 The Constrained Resource Identifier (CRI) is a complement to the
Uniform Resource Identifier (URI) that serializes the URI components
in Concise Binary Object Representation (CBOR) instead of a sequence
of characters. This simplifies parsing, comparison and reference
resolution in environments with severe limitations on processing
power, code size, and memory size.

The present revision -10 of this draft contains an experimental

addition that allows representing user information
(https://alice@chains.example) in the URI authority component. This
feature lacks test vectors and implementation experience at the time
of writing and requires discussion.

"Group Communication for the Constrained Application Protocol (CoAP)", Esko

Dijk, Chonggang Wang, Marco Tiloca, 2022-07-11,
<draft-ietf-core-groupcomm-bis-07.txt>

This document specifies the use of the Constrained Application

Protocol (CoAP) for group communication, including the use of UDP/IP
multicast as the default underlying data transport. Both unsecured
and secured CoAP group communication are specified. Security is
achieved by use of the Group Object Security for Constrained RESTful
Environments (Group OSCORE) protocol. The target application area of
this specification is any group communication use cases that involve
resource-constrained devices or networks that support CoAP. This
document replaces RFC 7390, while it updates RFC 7252 and RFC 7641.

"Concise Problem Details For CoAP APIs", Thomas Fossati, Carsten Bormann,
2022-07-06, <draft-ietf-core-problem-details-08.txt>

This document defines a concise "problem detail" as a way to carry

machine-readable details of errors in a REST response to avoid the
need to define new error response formats for REST APIs for
constrained environments. The format is inspired by, but intended to
be more concise than, the Problem Details for HTTP APIs defined in
RFC 7807.

"Profiling EDHOC for CoAP and OSCORE", Francesca Palombini, Marco Tiloca,
Rikard Hoeglund, Stefan Hristozov, Goeran Selander, 2022-07-11,
<draft-ietf-core-oscore-edhoc-04.txt>

The lightweight authenticated key exchange protocol EDHOC can be run

over CoAP and used by two peers to establish an OSCORE Security
Context. This document further profiles this use of the EDHOC
protocol, by specifying a number of additional and optional
mechanisms. These especially include an optimization approach for
combining the execution of EDHOC with the first subsequent OSCORE
transaction. This combination reduces the number of round trips
required to set up an OSCORE Security Context and to complete an
OSCORE transaction using that Security Context.

"Observe Notifications as CoAP Multicast Responses", Marco Tiloca, Rikard

Hoeglund, Christian Amsuess, Francesca Palombini, 2022-07-11,
<draft-ietf-core-observe-multicast-notifications-04.txt>

The Constrained Application Protocol (CoAP) allows clients to

"observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases,
such as based on publish-subscribe, it would be convenient for the
 server to send a single notification addressed to all the clients
observing a same target resource. This document updates RFC7252 and
RFC7641, and defines how a server sends observe notifications as
response messages over multicast, synchronizing all the observers of
a same resource on a same shared Token value. Besides, this document
defines how Group OSCORE can be used to protect multicast
notifications end-to-end between the server and the observer clients.

"Conditional Attributes for Constrained RESTful Environments", Michael

Koster, Alan Soloway, Bill Silverajan, 2022-05-10,
<draft-ietf-core-conditional-attributes-04.txt>

This specification defines Conditional Notification and Control

Attributes that work with CoAP Observe (RFC7641).

Editor note

The git repository for the draft is found at https://github.com/core-

wg/conditional-attributes/

"Key Update for OSCORE (KUDOS)", Rikard Hoeglund, Marco Tiloca, 2022-07-11,
<draft-ietf-core-oscore-key-update-02.txt>

Object Security for Constrained RESTful Environments (OSCORE) uses

AEAD algorithms to ensure confidentiality and integrity of exchanged
messages. Due to known issues allowing forgery attacks against AEAD
algorithms, limits should be followed on the number of times a
specific key is used for encryption or decryption. Among other
reasons, approaching key usage limits requires updating the OSCORE
keying material before communications can securely continue.

This document defines how two OSCORE peers must follow these key
usage limits and what steps they must take to preserve the security
of their communications. Also, it specifies Key Update for OSCORE
(KUDOS), a lightweight procedure that two peers can use to update
their keying material and establish a new OSCORE Security Context.
Finally, this document specifies a method that two peers can use to
update their OSCORE identifiers, as a stand-alone procedure or
embedded in a KUDOS execution. Thus, this document updates RFC 8613.

"Attacks on the Constrained Application Protocol (CoAP)", John Mattsson,

John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess,
2022-05-09, <draft-ietf-core-attacks-on-coap-00.txt>

Being able to securely read information from sensors, to securely

control actuators, and to not enable distributed denial-of-service
attacks are essential in a world of connected and networking things
interacting with the physical world. This document summarizes a
number of known attacks on CoAP and show that just using CoAP with a
security protocol like DTLS, TLS, or OSCORE is not enough for secure
operation. Several of the discussed attacks can be mitigated with
the solutions in draft-ietf-core-echo-request-tag.

"CoAP Protocol Indication", Christian Amsuess, 2022-07-11,

<draft-ietf-core-transport-indication-01.txt>

The Constrained Application Protocol (CoAP, [RFC7252]) is available

over different transports (UDP, DTLS, TCP, TLS, WebSockets), but
lacks a way to unify these addresses. This document provides
 terminology and provisions based on Web Linking [RFC8288] to express
alternative transports available to a device, and to optimize
exchanges using these.

CBOR Object Signing and Encryption (cose)

-----------------------------------------

"CBOR Object Signing and Encryption (COSE): Header parameters for carrying
and referencing X.509 certificates", Jim Schaad, 2020-12-14,
<draft-ietf-cose-x509-08.txt>

The CBOR Signing And Encrypted Message (COSE) structure uses

references to keys in general. For some algorithms, additional
properties are defined which carry parameters relating to keys as
needed. The COSE Key structure is used for transporting keys outside
of COSE messages. This document extends the way that keys can be
identified and transported by providing attributes that refer to or
contain X.509 certificates.

"CBOR Object Signing and Encryption (COSE): Countersignatures", Jim Schaad,

Russ Housley, 2022-08-31, <draft-ietf-cose-countersign-09.txt>

Concise Binary Object Representation (CBOR) is a data format designed

for small code size and small message size. CBOR Object Signing and
Encryption (COSE) defines a set of security services for CBOR. This
document defines a countersignature algorithm along with the needed
header parameters and CBOR tags for COSE. This document updates RFC
9052.

"CBOR Encoded X.509 Certificates (C509 Certificates)", John Mattsson,

Goeran Selander, Shahid Raza, Joel Hoglund, Martin Furuhed, 2022-07-10,
<draft-ietf-cose-cbor-encoded-cert-04.txt>

This document specifies a CBOR encoding of X.509 certificates. The

resulting certificates are called C509 Certificates. The CBOR
encoding supports a large subset of RFC 5280 and all certificates
compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
eUICC, and CA/Browser Forum Baseline Requirements profiles. When
used to re-encode DER encoded X.509 certificates, the CBOR encoding
can in many cases reduce the size of RFC 7925 profiled certificates
with over 50%. The CBOR encoded structure can alternatively be
signed directly ("natively signed"), which does not require re-
encoding for the signature to be verified. The document also
specifies C509 COSE headers, a C509 TLS certificate type, and a C509
file format.

"Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and
Encryption (COSE)", Hannes Tschofenig, Russ Housley, Brendan Moran,
2022-07-11, <draft-ietf-cose-hpke-02.txt>

This specification defines hybrid public-key encryption (HPKE) for

use with CBOR Object Signing and Encryption (COSE). HPKE offers a
variant of public-key encryption of arbitrary-sized plaintexts for a
recipient public key.

HPKE works for any combination of an asymmetric key encapsulation

mechanism (KEM), key derivation function (KDF), and authenticated
encryption with additional data (AEAD) encryption function.
Authentication for HPKE in COSE is provided by COSE-native security
 mechanisms.

"CBOR Web Token (CWT) Claims in COSE Headers", Tobias Looker, Michael
Jones, 2022-07-08, <draft-ietf-cose-cwt-claims-in-headers-00.txt>

This document describes how to include CBOR Web Token (CWT) claims in
the header parameters of any COSE structure. This functionality
helps to facilitate applications that wish to make use of CBOR Web
Token (CWT) claims in encrypted COSE structures and/or COSE
structures featuring detached signatures, while having some of those
claims be available before decryption and/or without inspecting the
detached payload.

"Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE",

Tobias Looker, Michael Jones, 2022-07-08,
<draft-ietf-cose-bls-key-representations-00.txt>

This specification defines how to represent cryptographic keys for

the pairing-friendly elliptic curves known as Barreto-Lynn-Scott
(BLS), for use with the key representation formats of JSON Web Key
(JWK) and COSE (COSE_Key).

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/tplooker/draft-ietf-cose-bls-key-representations.

"JOSE and COSE Encoding for Post-Quantum Signatures", Michael Prorock, Orie
Steele, Rafael Misoczki, Michael Osborne, Christine Cloostermans,
2022-08-16, <draft-ietf-cose-post-quantum-signatures-00.txt>

This document describes JSON and CBOR serializations for several post
quantum cryptography (PQC) based suites including CRYSTALS Dilithium,
Falcon, and SPHINCS+.

This document does not define any new cryptography, only

seralizations of existing cryptographic systems.

This document registers key types for JOSE and COSE, specifically
LWE, NTRU, and HASH.

Key types in this document are specified by the cryptographic

algorithm family in use by a particular algorithm as discussed in
RFC7517.

This document registers signature algorithms types for JOSE and COSE,
specifically CRYDI3 and others as required for use of various post
quantum signature schemes.

DANE Authentication for Network Clients Everywhere (dance)

----------------------------------------------------------

"An Architecture for DNS-Bound Client and Sender Identities", Ash Wilson,
Shumon Huque, Olle Johansson, 2022-05-24,
<draft-wilson-dance-architecture-02.txt>

This architecture document defines terminology, interaction, and

 authentication patterns, related to the use of DANE DNS records for
TLS client and messaging peer identity, within the context of
existing object security and TLS-based protocols.

"TLS Client Authentication via DANE TLSA records", Shumon Huque, Viktor
Dukhovni, Ash Wilson, 2022-03-24, <draft-ietf-dance-client-auth-00.txt>

The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish

Transport Layer Security (TLS) server certificates or public keys in
the DNS. This document updates RFC 6698 and RFC 7671. It describes
how to additionally use the TLSA record to publish client
certificates or public keys, and also the rules and considerations
for using them with TLS.

"TLS Extension for DANE Client Identity", Shumon Huque, Viktor Dukhovni,
Ash Wilson, 2022-03-24, <draft-ietf-dance-tls-clientid-00.txt>

This document specifies a TLS and DTLS extension to convey a DNS-

Based Authentication of Named Entities (DANE) Client Identity to a
TLS or DTLS server. This is useful for applications that perform TLS
client authentication via DANE TLSA records.

"An Architecture for DNS-Bound Client and Sender Identities", Ash Wilson,
Shumon Huque, Olle Johansson, Michael Richardson, 2022-07-28,
<draft-ietf-dance-architecture-00.txt>

This architecture document defines terminology, interaction, and

authentication patterns, related to the use of DANE DNS records for
TLS client and messaging peer identity, within the context of
existing object security and TLS-based protocols.

Deterministic Networking (detnet)

---------------------------------

"Deterministic Networking (DetNet) YANG Model", Xuesong Geng, Yeoncheol

Ryoo, Don Fedyk, Reshad Rahman, Zhenqiang Li, 2022-02-05,
<draft-ietf-detnet-yang-16.txt,.pdf>

This document contains the specification for the Deterministic

Networking YANG Model for configuration and operational data for
DetNet Flows. The model allows for provisioning of end-to-end DetNet
service on devices along the path without dependency on any signaling
protocol. It also specifies operational status for flows. An
operator or network controller programs the configuration of the
devices.

The YANG module defined in this document conforms to the Network

Management Datastore Architecture (NMDA).

"DetNet Bounded Latency", Norman Finn, Jean-Yves Le Boudec, Ehsan

Mohammadpour, Jiayi Zhang, Balazs Varga, 2022-04-08,
<draft-ietf-detnet-bounded-latency-10.txt>

This document presents a timing model for sources, destinations, and

DetNet transit nodes. Using the model, it provides a methodology to
compute end-to-end latency and backlog bounds for various queuing
methods. The methodology can be used by the management and control
planes and by resource reservation algorithms to provide bounded
latency and zero congestion loss for the DetNet service.
 "Operations, Administration and Maintenance (OAM) for Deterministic
Networks (DetNet) with MPLS Data Plane", Greg Mirsky, Mach Chen, Balazs
Varga, Janos Farkas, 2022-03-07, <draft-ietf-detnet-mpls-oam-07.txt>

This document defines format and use principals of the Deterministic

Network (DetNet) service Associated Channel (ACH) over a DetNet
network with the MPLS data plane. The DetNet service ACH can be used
to carry test packets of active Operations, Administration, and
Maintenance protocols that are used to detect DetNet failures and
measure performance metrics.

"Operations, Administration and Maintenance (OAM) for Deterministic

Networks (DetNet) with IP Data Plane", Greg Mirsky, Mach Chen, David Black,
2022-08-22, <draft-ietf-detnet-ip-oam-05.txt>

This document defines the principles for using Operations,

Administration, and Maintenance protocols and mechanisms in the
Deterministic Networking networks with the IP data plane.

"Deterministic Networking (DetNet) Controller Plane Framework", Andrew

Malis, Xuesong Geng, Mach Chen, Fengwei Qin, Balazs Varga, 2022-06-28,
<draft-ietf-detnet-controller-plane-framework-02.txt>

This document provides a framework overview for the Deterministic

Networking (DetNet) controller plane. It discusses concepts and
requirements for DetNet controller plane which could be basis for
future solution specification.

"Framework of Operations, Administration and Maintenance (OAM) for

Deterministic Networking (DetNet)", Greg Mirsky, Fabrice Theoleyre,
Georgios Papadopoulos, Carlos Bernardos, Balazs Varga, Janos Farkas,
2022-06-13, <draft-ietf-detnet-oam-framework-06.txt>

Deterministic Networking (DetNet), as defined in RFC 8655, is aimed

to provide a bounded end-to-end latency on top of the network
infrastructure, comprising both Layer 2 bridged and Layer 3 routed
segments. This document's primary purpose is to detail the specific
requirements of the Operation, Administration, and Maintenance (OAM)
recommended to maintain a deterministic network. With the
implementation of the OAM framework in DetNet, an operator will have
a real-time view of the network infrastructure regarding the
network's ability to respect the Service Level Objective, such as
packet delay, delay variation, and packet loss ratio, assigned to
each DetNet flow.

"Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP",

Balazs Varga, Janos Farkas, Andrew Malis, 2022-03-21,
<draft-ietf-detnet-mpls-over-ip-preof-00.txt>

This document describes how DetNet IP data plane can support the
Packet Replication, Elimination, and Ordering Functions (PREOF) built
on the existing MPLS PREOF solution [RFC8939] and the mechanisms
defined in [RFC9025].

Diameter Maintenance and Extensions (dime)

------------------------------------------

"Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand,

 2022-08-03, <draft-ietf-dime-group-signaling-14.txt>

In large network deployments, a single Diameter node can support over

a million concurrent Diameter sessions. In some use cases, Diameter
nodes need to apply the same operation to a large group of Diameter
sessions concurrently. The Diameter base protocol commands operate
on a single session so these use cases could result in many thousands
of command exchanges to enforce the same operation on each session in
the group. In order to reduce signaling, it would be desirable to
enable bulk operations on all (or part of) the sessions managed by a
Diameter node using a single or a few command exchanges. This
document specifies the Diameter protocol extensions to achieve this
signaling optimization.

Domain-based Message Authentication, Reporting & Conformance (dmarc)

--------------------------------------------------------------------

"Domain-based Message Authentication, Reporting, and Conformance (DMARC)",

Todd Herr, John Levine, 2022-08-30, <draft-ietf-dmarc-dmarcbis-18.txt>

This document describes the Domain-based Message Authentication,

Reporting, and Conformance (DMARC) protocol.

DMARC permits the owner of an email author's domain name to enable

verification of the domain's use, to indicate the Domain Owner's or
Public Suffix Operator's message handling preference regarding failed
verification, and to request reports about use of the domain name.
Mail receiving organizations can use this information when evaluating
handling choices for incoming mail.

This document obsoletes RFC 7489.

"Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Failure Reporting", Steven Jones, 2022-08-21,
<draft-ietf-dmarc-failure-reporting-05.txt>

Domain-based Message Authentication, Reporting, and Conformance

(DMARC) is a scalable mechanism by which a domain owner can request
feedback about email messages using their domain in the From: address
field. This document describes "failure reports," or "failed message
reports," which provide details about individual messages that failed
to authenticate according to the DMARC mechanism.

"DMARC Aggregate Reporting", Alex Brotman, 2022-04-20,

<draft-ietf-dmarc-aggregate-reporting-05.txt>

DMARC allows for domain holders to request aggregate reports from

receivers. This report is an XML document, and contains extensible
elements that allow for other types of data to be specified later.
The aggregate reports can be submitted to the domain holder's
specified destination as supported by the receiver.

This document (along with others) obsoletes RFC7489.

Distributed Mobility Management (dmm)

-------------------------------------

"Segment Routing IPv6 for Mobile User Plane", Satoru Matsushima, Clarence
Filsfils, Miya Kohno, Pablo Camarillo, Dan Voyer, Charles Perkins,
 2022-05-09, <draft-ietf-dmm-srv6-mobile-uplane-21.txt>

This document specifies the applicability of SRv6 (Segment Routing

IPv6) to the user-plane of mobile networks. The network programming
nature of SRv6 accomplishes mobile user-plane functions in a simple
manner. The statelessness of SRv6 and its ability to control both
service layer path and underlying transport can be beneficial to the
mobile user-plane, providing flexibility, end-to-end network slicing,
and SLA control for various applications.

"Mobility aware Transport Network Slicing for 5G", Uma Chunduri, John
Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Praveen Muley,
2022-07-11, <draft-ietf-dmm-tn-aware-mobility-04.txt>

This document specifies a framework and mapping of slices in 5G

mobile systems to transport network slices in IP, Layer 2 or Layer 1
transport networks. Slices in 5G systems are characterized by
latency bounds, reservation guarantees, jitter, data rates,
availability, mobility speed, usage density, criticality and
priority. These characteristics are mapped to transport network
slice include bandwidth, latency and criteria such as isolation,
directionality and disjoint routes. Mobile slice criteria are mapped
to the appropriate transport slice and capabilities offered in
backhaul, midhaul and fronthaul connectivity segments between radio
side network functions and user plane function(gateway).

This document describes how a mobile network slice is mapped to a

slice in IP or Layer 2 transport network between 3GPP provisioning
end points. The same mapping mechanisms apply during initial UE
session setup and following UE mobility. Applicability of this
framework and underlying transport networks, which can enable
different slice properties are also discussed. This is based on
mapping between mobile and transport underlays (L2, Segment Routing,
IPv6, MPLS and IPv4).

Domain Name System Operations (dnsop)

-------------------------------------

"The ALT Special Use Top Level Domain", Warren Kumari, Paul Hoffman,
2022-08-23, <draft-ietf-dnsop-alt-tld-17.txt>

This document reserves a TLD label, "alt" to be used in non-DNS

contexts. It also provides advice and guidance to developers
developing alternative namespaces.

[ This document is being collaborated on in Github at

<https://github.com/wkumari/draft-wkumari-dnsop-alt-tld>. The most
recent version of the document, open issues, etc should all be
available here. The authors (gratefully) accept pull requests. ]

"Recommendations for DNSSEC Resolvers Operators", Daniel Migault, Dan York,

2022-05-13, <draft-ietf-dnsop-dnssec-validator-requirements-01.txt>

The DNS Security Extensions (DNSSEC) define a process for validating

received data and assert them authentic and complete as opposed to
forged.

This document clarifies the scope and responsibilities of DNSSEC

Resolver Operators (DRO) as well as operational recommendations that
 DNSSEC validators operators SHOULD put in place in order to implement
sufficient trust that makes DNSSEC validation output accurate. The
recommendations described in this document include, provisioning
mechanisms as well as monitoring and management mechanisms.

"DNS Catalog Zones", Peter van Dijk, Libor Peltan, Ondrej Sury, Willem
Toorop, Kees Monshouwer, Peter Thomassen, Aram Sargsyan, 2022-07-07,
<draft-ietf-dnsop-dns-catalog-zones-06.txt>

This document describes a method for automatic DNS zone provisioning

among DNS primary and secondary nameservers by storing and
transferring the catalog of zones to be provisioned as one or more
regular DNS zones.

"DNS Glue Requirements in Referral Responses", Mark Andrews, Shumon Huque,

Paul Wouters, Duane Wessels, 2022-08-25,
<draft-ietf-dnsop-glue-is-not-optional-06.txt>

The DNS uses glue records to allow iterative clients to find the
addresses of name servers that are contained within a delegated zone.
Authoritative Servers are expected to return all available glue
records for in-domain name servers in a referral response. If
message size constraints prevent the inclusion of all glue records
for in-domain name servers, the server MUST set the TC flag to inform
the client that the response is incomplete, and that the client
SHOULD use another transport to retrieve the full response. This
document updates RFC 1034 to clarify correct server behavior.

"Service binding and parameter specification via the DNS (DNS SVCB and
HTTPS RRs)", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2022-05-24,
<draft-ietf-dnsop-svcb-https-10.txt>

This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTP origins. SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP].
By providing more information to the client before it attempts to
establish a connection, these records offer potential benefits to
both performance and privacy.

TO BE REMOVED: This document is being collaborated on in Github at:

https://github.com/MikeBishop/dns-alt-svc
(https://github.com/MikeBishop/dns-alt-svc). The most recent working
version of the document, open issues, etc. should all be available
there. The authors (gratefully) accept pull requests.

"Fragmentation Avoidance in DNS", Kazunori Fujiwara, Paul Vixie,

2022-08-21, <draft-ietf-dnsop-avoid-fragmentation-08.txt>

EDNS0 enables a DNS server to send large responses using UDP and is
widely deployed. Large DNS/UDP responses are fragmented, and IP
fragmentation has exposed weaknesses in application protocols. It is
possible to avoid IP fragmentation in DNS by limiting response size
where possible, and signaling the need to upgrade from UDP to TCP
transport where necessary. This document proposes to avoid IP
 fragmentation in DNS.

"Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC", Dmitry Belyavsky, Vasily Dolmatov, Boris Makarenko,
2022-07-28, <draft-ietf-dnsop-rfc5933-bis-09.txt>

This document describes how to produce digital signatures and hash

functions using the GOST R 34.10-2012 and GOST R 34.11-2012
algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
Domain Name System Security Extensions (DNSSEC).

This document obsoletes RFC 5933 and updates RFC 8624.

"Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie, Ralph

Dolmans, 2022-03-07, <draft-ietf-dnsop-ns-revalidation-02.txt>

This document recommends improved DNS [RFC1034] [RFC1035] resolver

behavior with respect to the processing of Name Server (NS) resource
record sets (RRset) during iterative resolution. When following a
referral response from an authoritative server to a child zone, DNS
resolvers should explicitly query the authoritative NS RRset at the
apex of the child zone and cache this in preference to the NS RRset
on the parent side of the zone cut. Resolvers should also
periodically revalidate the child delegation by re-quering the parent
zone at the expiration of the TTL of the parent side NS RRset.

"DNS Terminology", Paul Hoffman, Kazunori Fujiwara, 2022-07-27,

<draft-ietf-dnsop-rfc8499bis-04.txt>

The Domain Name System (DNS) is defined in literally dozens of

different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes
changed in the decades since the DNS was first defined. This
document gives current definitions for many of the terms used in the
DNS in a single document.

This document obsoletes RFC 8499 and updates RFC 2308.

"DNS Error Reporting", Roy Arends, Matt Larson, 2022-07-10,

<draft-ietf-dnsop-dns-error-reporting-02.txt>

DNS Error Reporting is a lightweight error reporting mechanism that

provides the operator of an authoritative server with reports on DNS
resource records that fail to resolve or validate, that a Domain
Owner or DNS Hosting organization can use to improve domain hosting.
The reports are based on Extended DNS Errors [RFC8914].

When a domain name fails to resolve or validate due to a

misconfiguration or an attack, the operator of the authoritative
server may be unaware of this. To mitigate this lack of feedback,
this document describes a method for a validating recursive resolver
to automatically signal an error to an agent specified by the
authoritative server. DNS Error Reporting uses the DNS to report
errors.

Another lack of feedback occurs when validation was successful, or

when there is no error to report. This positive feedback may be
helpful to show that a deployment was successful. This document
introcudes an extended DNS error "NO ERROR".
"DNS Security Extensions (DNSSEC)", Paul Hoffman, 2022-08-11,
<draft-ietf-dnsop-dnssec-bcp-03.txt>

This document describes the DNS security extensions (commonly called

"DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of
others. One purpose is to introduce all of the RFCs in one place so
that the reader can understand the many aspects of DNSSEC. This
document does not update any of those RFCs. Another purpose is to
move DNSSEC to Best Current Practice status.

This document is currently maintained at

https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and
pull requests are welcomed.

"The "ZONEVERSION" EDNS option for the version token of a RR's zone", Hugo
Salgado, Mauricio Ereche, 2022-04-21, <draft-ietf-dnsop-zoneversion-00.txt>

The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS

authoritative server to add an EDNS option in the answer of such
query with a token field representing the version of the zone which
contains the answered Resource Record, such as the SOA serial field
in zones when this number corresponds to the zone version.

This "ZONEVERSION" data allows to debug and diagnose problems by

helping to recognize the data source of an answer in an atomic single
query, by associating the response with a respective zone version.

"Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's

Operator", Peter Thomassen, Nils Wisiol, 2022-08-17,
<draft-ietf-dnsop-dnssec-bootstrapping-02.txt>

This document introduces an in-band method for DNS operators to

publish arbitrary information about the zones they are authoritative
for, in an authenticated fashion and on a per-zone basis. The
mechanism allows managed DNS operators to securely announce DNSSEC
key parameters for zones under their management, including for zones
that are not currently securely delegated.

Whenever DS records are absent for a zone's delegation, this signal

enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex. The
parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay" ([RFC8078]).

This document deprecates the DS enrollment methods described in

Section 3 of [RFC8078] in favor of Section 3 of this document.

[ Ed note: This document is being collaborated on at

https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]

"DNSSEC automation", Ulrich Wisser, Shumon Huque, 2022-05-24,

<draft-ietf-dnsop-dnssec-automation-00.txt>

This document describes an algorithm and a protocol to automate

DNSSEC Multi-Signer [RFC8901] "Multi-Signer DNSSEC Models" setup,
 operations and decomissioning. Using Model 2 of the Multi-Signer
specification, where each operator has their own distinct KSK and ZSK
sets (or CSK sets), [RFC8078] "Managing DS Records from the Parent
via CDS/CDNSKEY" and [RFC7477] "Child-to-Parent Synchronization in
DNS" to accomplish this.

"Negative Caching of DNS Resolution Failures", Duane Wessels, William

Carroll, Matthew Thomas, 2022-07-27,
<draft-ietf-dnsop-caching-resolution-failures-00.txt>

In the DNS, resolvers employ caching to reduce both latency for end
users and load on authoritative name servers. The process of
resolution may result in one of three types of responses: (1) a
response containing the requested data; (2) a response indicating the
requested data does not exist; or (3) a non-response due to a
resolution failure in which the resolver does not receive any useful
information regarding the data's existence. This document concerns
itself only with the third type.

RFC 2308 specifies requirements for DNS negative caching. There,

caching of type (1) and (2) responses is mandatory and caching of
type (3) responses is optional. This document updates RFC 2308 to
require negative caching for DNS resolution failures.

"Survey of Domain Verification Techniques using DNS", Shivan Sahib, Shumon

Huque, Paul Wouters, 2022-07-28,
<draft-ietf-dnsop-domain-verification-techniques-00.txt>

Many services on the Internet need to verify ownership or control of

a domain in the Domain Name System (DNS) [RFC1034] [RFC1035]. This
verification is often done by requesting a specific DNS record to be
visible in the domain. This document surveys various techniques in
wide use today, the pros and cons of each, and proposes some
practices to avoid known problems.

Extensions for Scalable DNS Service Discovery (dnssd)

-----------------------------------------------------

"Service Registration Protocol for DNS-Based Service Discovery", Ted Lemon,

Stuart Cheshire, 2022-07-11, <draft-ietf-dnssd-srp-14.txt>

The Service Registration Protocol for DNS-Based Service Discovery

uses the standard DNS Update mechanism to enable DNS-Based Service
Discovery using only unicast packets. This makes it possible to
deploy DNS Service Discovery without multicast, which greatly
improves scalability and improves performance on networks where
multicast service is not an optimal choice, particularly 802.11
(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
uses public keys and SIG(0) to allow services to defend their
registrations against attack.

"An EDNS0 option to negotiate Leases on DNS Updates", Stuart Cheshire, Ted
Lemon, 2022-07-11, <draft-ietf-dnssd-update-lease-02.txt>

This document describes an EDNS0 option that can be used by DNS

Update requestors and DNS servers to include a lease lifetime in a
DNS Update or response, allowing a server to garbage collect stale
resource records that have been added by DNS Updates
 "Advertising Proxy for DNS-SD Service Registration Protocol", Stuart
Cheshire, Ted Lemon, 2022-07-11, <draft-ietf-dnssd-advertising-proxy-01.txt>

An Advertising Proxy advertises the contents of a DNS zone, for

example maintained using the DNSSD Service Registration Protocol
(SRP), using multicast DNS. This allows legacy clients to discover
services registered with SRP using multicast DNS.

DDoS Open Threat Signaling (dots)

---------------------------------

"Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry", Yuhei Hayashi,
chenmeiling, Li Su, 2022-04-01, <draft-ietf-dots-telemetry-use-cases-10.txt>

DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS
protocols to assist the mitigator in using efficient DDoS attack
mitigation techniques in a network. This document presents sample
use cases for DOTS Telemetry. It discusses in particular what
components are deployed in the network, how they cooperate, and what
information is exchanged to effectively use these techniques.

"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel

Configuration Attributes for Robust Block Transmission", Mohamed Boucadair,
Jon Shallow, 2022-09-01, <draft-ietf-dots-robust-blocks-04.txt>

This document specifies new DDoS Open Threat Signaling (DOTS) signal
channel configuration parameters that can be negotiated between DOTS
peers to enable the use of Q-Block1 and Q-Block2 CoAP options. These
options enable robust and faster transmission rates for large amounts
of data with less packet interchanges as well as supporting faster
recovery should any of the blocks get lost in transmission.

Also, this document defines a YANG data model for representing these
new DOTS signal channel configuration parameters.

DNS PRIVate Exchange (dprive)

-----------------------------

"Unilateral Opportunistic Deployment of Encrypted

Recursive-to-Authoritative DNS", Daniel Gillmor, Joey Salazar, Paul
Hoffman, 2022-07-11, <draft-ietf-dprive-unilateral-probing-01.txt>

This document sets out steps that DNS servers (recursive resolvers
and authoritative servers) can take unilaterally (without any
coordination with other peers) to defend DNS query privacy against a
passive network monitor. The steps in this document can be defeated
by an active attacker, but should be simpler and less risky to deploy
than more powerful defenses.

The goal of this document is to simplify and speed deployment of

opportunistic encrypted transport in the recursive-to-authoritative
hop of the DNS ecosystem. With wider easy deployment of the
underlying transport on an opportunistic basis, we hope to facilitate
the future specification of stronger cryptographic protections
against more powerful attacks.

Drone Remote ID Protocol (drip)

-------------------------------
 "Drone Remote Identification Protocol (DRIP) Architecture", Stuart Card,
Adam Wiethuechter, Robert Moskowitz, Shuai Zhao, Andrei Gurtov, 2022-08-16,
<draft-ietf-drip-arch-29.txt>

This document describes an architecture for protocols and services to

support Unmanned Aircraft System (UAS) Remote Identification (RID)
and tracking, plus UAS RID-related communications. This architecture
adheres to the requirements listed in the DRIP Requirements document
(RFC9153).

"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)",
Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov,
2022-08-03, <draft-ietf-drip-rid-32.txt>

This document describes the use of Hierarchical Host Identity Tags

(HHITs) as self-asserting IPv6 addresses and thereby a trustable
identifier for use as the Unmanned Aircraft System Remote
Identification and tracking (UAS RID).

This document updates RFC7401 and RFC7343.

Within the context of RID, HHITs will be called DRIP Entity Tags
(DETs). HHITs provide claims to the included explicit hierarchy that
provides registry (via, e.g., DNS, RDAP) discovery for 3rd-party
identifier endorsement.

"DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote
ID", Adam Wiethuechter, Stuart Card, Robert Moskowitz, 2022-09-01,
<draft-ietf-drip-auth-21.txt>

This document describes how to add trust into the Broadcast Remote ID
(RID) specification discussed in the DRIP Architecture; first trust
in the RID ownership and second in the source of the RID messages.
It defines message types and associated formats (sent within the
Authentication Message) that can be used to authenticate past
messages sent by an unmanned aircraft (UA) and provide proof of UA
trustworthiness even in the absence of Internet connectivity at the
receiving node.

"DRIP Entity Tag (DET) Registration & Lookup", Adam Wiethuechter, Stuart
Card, Robert Moskowitz, Jim Reid, 2022-07-11,
<draft-ietf-drip-registries-05.txt>

This document details the required mechanisms for the registration

and discovery of DRIP Entity Tags (DETs). The registration process
relies upon the Extensible Provisioning Protocol (EPP). The
discovery process leverages DNS, DNSSEC, and related technology. The
lookup process relies upon the Registration Data Access Protocol
(RDAP). The DETs can be registered with as their "raw public keys"
or in X.509 certificates.

Delay/Disruption Tolerant Networking (dtn)

------------------------------------------

"DTN Management Architecture", Edward Birrane, Emery Annis, Sarah Heiner,

2022-07-10, <draft-ietf-dtn-dtnma-01.txt>

This document describes the motivation for, and services required of,
the management of devices deployed in a Delay-Tolerant Networking
 (DTN) environment. Together, this set of information outlines a
conceptual DTN Management Architecture (DTNMA) suitable for
deployment in any of the challenged and constrained DTN operational
environments.

The DTNMA is supported by two types of asynchronous behavior. First,

the DTNMA does not presuppose any synchronized transport behavior
between managed and managing devices. Second, the DTNMA does not
support any query-response semantics. In this way, the DTNMA allows
for operation in extremely challenging conditions, to include over
uni-directional links and cases where delays/disruptions prevent
operation over traditional transport layers.

Emergency Context Resolution with Internet Technologies (ecrit)

---------------------------------------------------------------

"A LoST extension to return complete and similar location info", Brian
Rosen, Roger Marshall, Jeff Martin, 2022-03-04,
<draft-ietf-ecrit-similar-location-19.txt>

This document describes an extension to the LoST protocol of RFC 5222

that allows additional civic location information to be returned in a
<findServiceResponse>. This extension supports two use cases: First,
when the input location is valid but lacks some Civic Address
elements, the LoST server can provide a completed form. Second, when
the input location is invalid, the LoST server can identify one or
more feasible ("similar") locations. This extension is applicable
when the location information in the <findService> request uses the
Basic Civic profile as described in RFC 5222 or another profile whose
definition provides instructions concerning its use with this
extension.

Revision of core Email specifications (emailcore)

-------------------------------------------------

"Simple Mail Transfer Protocol", John Klensin, 2022-07-09,

<draft-ietf-emailcore-rfc5321bis-12.txt>

This document is a specification of the basic protocol for Internet

electronic mail transport. It (including text carried forward from
RFC 5321) consolidates, updates, and clarifies several previous
documents, making all or parts of most of them obsolete. It covers
the SMTP extension mechanisms and best practices for the contemporary
Internet, but does not provide details about particular extensions.
The document also provides information about use of SMTP for other
than strict mail transport and delivery. This document replaces RFC
5321, the earlier version with the same title.

"Applicability Statement for IETF Core Email Protocols", John Klensin,

Kenneth Murchison, Ekow Sam, 2022-05-23, <draft-ietf-emailcore-as-05.txt>

Electronic mail is one of the oldest Internet applications that is

still in very active use. While the basic protocols and formats for
mail transport and message formats have evolved slowly over the
years, events and thinking in more recent years have supplemented
those core protocols with additional features and suggestions for
their use. This Applicability Statement describes the relationship
among many of those protocols and provides guidance and makes
recommendations for the use of features of the core protocols.
 "Internet Message Format", Pete Resnick, 2022-04-04,
<draft-ietf-emailcore-rfc5322bis-03.txt>

This document specifies the Internet Message Format (IMF), a syntax

for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is a
revision of Request For Comments (RFC) 5322, itself a revision of
Request For Comments (RFC) 2822, all of which supersede Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages", updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs.

EAP Method Update (emu)

-----------------------

"Forward Secrecy for the Extensible Authentication Protocol Method for

Authentication and Key Agreement (EAP-AKA' FS)", Jari Arkko, Karl Norrman,
Vesa Torvinen, John Mattsson, 2022-07-11, <draft-ietf-emu-aka-pfs-07.txt>

Many different attacks have been reported as part of revelations

associated with pervasive surveillance. Some of the reported attacks
involved compromising the smart card supply chain, such as attacking
SIM card manufacturers and operators in an effort to compromise
shared secrets stored on these cards. Since the publication of those
reports, manufacturing and provisioning processes have gained much
scrutiny and have improved. However, the danger of resourceful
attackers for these systems is still a concern. Always assuming
breach such as key compromise and minimizing the impact of breach are
essential zero-trust principles.

This specification is an optional extension to the EAP-AKA'

authentication method which was defined in [RFC9048]. The extension,
when negotiated, provides Forward Secrecy for the session key
generated as a part of the authentication run in EAP-AKA'. This
prevents an attacker who has gained access to the long-term pre-
shared secret in a SIM card from being able to decrypt any past
communications. In addition, if the attacker stays merely a passive
eavesdropper, the extension prevents attacks against future sessions.
This forces attackers to use active attacks instead.

"TLS-based EAP types and TLS 1.3", Alan DeKok, 2022-07-05,

<draft-ietf-emu-tls-eap-types-07.txt>

EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many
other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP-
TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific
EAP methods. This document updates those methods in order to use the
new key derivation methods available in TLS 1.3. Additional changes
necessitated by TLS 1.3 are also discussed.

Email mailstore and eXtensions To Revise or Amend (extra)

---------------------------------------------------------

"Sieve Email Filtering: Snooze Extension", Kenneth Murchison, Ricardo

Signes, Neil Jenkins, 2022-03-07, <draft-ietf-extra-sieve-snooze-04.txt>

This document describes the "snooze" extension to the Sieve email

filtering language. The "snooze" extension gives Sieve the ability
 to postpone the delivery of an incoming email message into a target
mailbox until a later point in time.

"IANA registry for Sieve actions", Alexey Melnikov, Kenneth Murchison,

2022-08-15, <draft-ietf-extra-sieve-action-registry-04.txt>

This document creates a registry of Sieve (RFC 5228) actions in order

to help developers and Sieve extension writers track interactions
between different extensions.

"IMAP Paged SEARCH & FETCH Extension", Alexey Melnikov, Arun Achuthan,
Vikram Nagulakonda, Luis Alves, 2022-08-12,
<draft-ietf-extra-imap-partial-02.txt>

The PARTIAL extension of the Internet Message Access Protocol (RFC

3501/RFC 9051) allows clients to limit the number of search results
returned, as well as to perform incremental (paged) searches. This
also helps servers to optimize resource usage when performing
searches.

This document extends PARTIAL SEARCH return option originally

specified in RFC 5267. It also clarifies some interactions between
RFC 5267 and RFC 4731/RFC 9051.

"Sieve Email Filtering: Extension for Processing iMIP Messages", Kenneth

Murchison, Ricardo Signes, Matthew Horsfall, 2022-07-11,
<draft-ietf-extra-processimip-00.txt>

This document describes the "processimip" extension to the Sieve

email filtering language. The "processimip" extension gives Sieve
the ability to process messages using the iCalendar Message-Based
Interoperability Protocol (iMIP).

Open Issues

"IMAP MESSAGELIMIT Extension", Alexey Melnikov, Arun Achuthan, Vikram

Nagulakonda, Luis Alves, 2022-08-14,
<draft-ietf-extra-imap-messagelimit-00.txt>

The MESSAGELIMIT extension of the Internet Message Access Protocol

(RFC 3501/RFC 9051) allows servers to announce a limit on the number
of messages that can be processed in a single
FETCH/SEARCH/STORE/COPY/MOVE command. This helps servers to control
resource usage when performing various IMAP operations.

Grant Negotiation and Authorization Protocol (gnap)

---------------------------------------------------

"Grant Negotiation and Authorization Protocol", Justin Richer, Aaron

Parecki, Fabien Imbault, 2022-07-11, <draft-ietf-gnap-core-protocol-10.txt>

GNAP defines a mechanism for delegating authorization to a piece of

software, and conveying that delegation to the software. This
delegation can include access to a set of APIs as well as information
passed directly to the software.

"Grant Negotiation and Authorization Protocol Resource Server Connections",

Justin Richer, Aaron Parecki, Fabien Imbault, 2022-07-11,
<draft-ietf-gnap-resource-servers-02.txt>
 GNAP defines a mechanism for delegating authorization to a piece of
software, and conveying that delegation to the software. This
extension defines methods for resource servers (RS) to communicate
with authorization servers (AS) in an interoperable fashion.

Global Routing Operations (grow)

--------------------------------

"Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi

Sriram, Alexander Azimov, 2022-04-26,
<draft-ietf-grow-route-leak-detection-mitigation-07.txt>

Problem definition for route leaks and enumeration of types of route

leaks are provided in RFC 7908. This document describes a new well-
known Large Community that provides a way for route-leak prevention,
detection, and mitigation. The configuration process for this
Community can be automated with the methodology for setting BGP roles
that is described in ietf-idr-bgp-open-policy draft.

"TLV support for BMP Route Monitoring and Peer Down Messages", Paolo
Lucente, Yunan Gu, 2022-03-07, <draft-ietf-grow-bmp-tlv-07.txt>

Most of the message types defined by the BGP Monitoring Protocol

(BMP) make provision for optional trailing data. However, Route
Monitoring messages (which provide a snapshot of the monitored
Routing Information Base) and Peer Down messages (which indicate that
a peering session was terminated) do not. Supporting optional data
in TLV format across all BMP message types allows for a homogeneous
and extensible surface that would be useful for the most different
use-cases that need to convey additional data to a BMP station.
While it is not intended for this document to cover any specific
utilization scenario, it defines a simple way to support optional TLV
data in all message types.

"Support for Enterprise-specific TLVs in the BGP Monitoring Protocol",

Paolo Lucente, Yunan Gu, 2022-07-27, <draft-ietf-grow-bmp-tlv-ebit-00.txt>

Message types defined by the BGP Monitoring Protocol (BMP) do

provision for data in TLV - Type, Length, Value - format, either in
the shape of optional TLVs at the end of a BMP message or Stats
Reports TLVs. However the space for Type value is unique and
governed by IANA. To allow the usage of vendor-specific TLVs, a
mechanism to define per-vendor Type values is required. In this
document we introduce an Enterprise Bit, or E-bit, for such purpose.

"Near Real Time Mirroring (NRTM) version 4", Sasha Romijn, Job Snijders,
Edward Shryane, Stavros Konstantaras, 2022-08-25,
<draft-ietf-grow-nrtm-v4-00.txt>

This document specifies a one-way synchronization protocol for

Internet Routing Registry (IRR) records. The protocol allows
instances of IRR database servers to mirror IRR records, specified in
in the Routing Policy Specification Language (RPSL), between each
other.

Home Networking (homenet)

-------------------------
 "Simple Provisioning of Public Names for Residential Networks", Daniel
Migault, Ralf Weber, Michael Richardson, Ray Hunter, 2022-06-13,
<draft-ietf-homenet-front-end-naming-delegation-16.txt>

Home network owners often have devices that they wish to access
outside their home network - i.e., from the Internet using their
names. To do so, these names needs to be made publicly available in
the DNS.

This document describes how a Homenet Naming Authority (HNA) can

instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public
Homenet Zone on its behalf.

"DHCPv6 Options for Home Network Naming Authority", Daniel Migault, Ralf
Weber, Tomek Mrugalski, 2022-07-28,
<draft-ietf-homenet-naming-architecture-dhc-options-16.txt>

This document defines DHCPv6 options so an agnostic Homenet Naming

Authority (HNA) can automatically proceed to the appropriate
configuration and outsource the authoritative naming service for the
home network. In most cases, the outsourcing mechanism is
transparent for the end user.

Human Rights Protocol Considerations (hrpc)

-------------------------------------------

"Guidelines for Human Rights Protocol and Architecture Considerations",

Gurshabad Grover, Niels ten Oever, 2022-03-28,
<draft-irtf-hrpc-guidelines-13.txt>

This document sets guidelines for human rights considerations for

developers working on network protocols and architectures, similar to
the work done on the guidelines for privacy considerations [RFC6973].
This is an updated version of the guidelines for human rights
considerations in [RFC8280].

This document is not an Internet Standards Track specification; it is

published for informational purposes.

This informational document has consensus for publication from the

Internet Research Task Force (IRTF) Human Right Protocol
Considerations Research Group. It has been reviewed, tried, and
tested by both by the research group as well as by researchers and
practitioners from outside the research group. The research group
acknowledges that the understanding of the impact of internet
protocols and architecture on society is a developing practice and is
a body of research that is still in development.

"Internet Protocols and the Human Rights to Freedom of Association and

Assembly", Niels ten Oever, Stephane Couture, Mallory Knodel, 2022-08-03,
<draft-irtf-hrpc-association-11.txt>

This document explores whether there is a relation between the

Internet architecture and the ability of people to exercise their
rights to peaceful assembly and association online. It does so by
asking the question: what are the protocol development considerations
for freedom of assembly and association? The Internet increasingly
mediates our lives, our relationships, and our ability to exercise
our human rights. As a global assemblage, the Internet provides a
 public space, yet it is predominantly built on private
infrastructure. Since Internet protocols and architecture play a
central role in the management, development, and use of the Internet,
we analyze the relation between protocols, architecture, and the
rights to assemble and associate to mitigate infringements on those
rights. This document concludes that the way in which infrastructure
is designed and implemented impacts people's ability to exercise
their freedom of assembly and association. It is therefore
recommended that the the potential impacts of Internet technologies
should be assessed, reflecting recommendations of various UN bodies
and norms. Finally, the document considers both the limitations on
changing association and impact of "forced association" in the
context of online platforms.

Building Blocks for HTTP APIs (httpapi)

---------------------------------------

"RateLimit Fields for HTTP", Roberto Polli, Alex Ruiz, 2022-07-06,

<draft-ietf-httpapi-ratelimit-headers-05.txt>

This document defines the RateLimit-Limit, RateLimit-Remaining,

RateLimit-Reset and RateLimit-Policy fields for HTTP, thus allowing
servers to publish current service limits and clients to shape their
request policy and avoid being throttled out.

"Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal,
2022-05-25, <draft-ietf-httpapi-rfc7807bis-03.txt>

This document defines a "problem detail" to carry machine-readable

details of errors in HTTP response content and/or fields to avoid the
need to define new error response formats for HTTP APIs.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/ietf-wg-httpapi/rfc7807bis.

"The Idempotency-Key HTTP Header Field", Jayadeba Jena, Sanjay Dalal,

2022-05-09, <draft-ietf-httpapi-idempotency-key-header-01.txt>

The HTTP Idempotency-Key request header field can be used to carry

idempotency key in order to make non-idempotent HTTP methods such as
POST or PATCH fault-tolerant.

"REST API Media Types", Roberto Polli, 2022-03-07,

<draft-ietf-httpapi-rest-api-mediatypes-01.txt>

This document registers the following media types used in APIs on the
IANA Media Types registry: application/yaml, application/schema+json,
application/schema-instance+json, application/openapi+json, and
application/openapi+yaml.

"YAML Media Type", Roberto Polli, Erik Wilde, Eemeli Aro, 2022-08-05,
<draft-ietf-httpapi-yaml-mediatypes-03.txt>

This document registers the application/yaml media type and the +yaml
structured syntax suffix on the IANA Media Types registry.
 "The Link-Template HTTP Header Field", Mark Nottingham, 2022-04-29,
<draft-ietf-httpapi-link-template-00.txt>

This specification defines the Link-Template HTTP header field,

providing a means for describing the structure of a link between two
resources, so that new links can be generated.

HTTP (httpbis)
--------------

"Cookies: HTTP State Management Mechanism", Lily Chen, Steven Englehardt,

Mike West, John Wilander, 2022-04-24, <draft-ietf-httpbis-rfc6265bis-10.txt>

This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 6265.

"Digest Fields", Roberto Polli, Lucas Pardue, 2022-06-19,

<draft-ietf-httpbis-digest-headers-10.txt>

This document defines HTTP fields that support integrity digests.

The Content-Digest field can be used for the integrity of HTTP
message content. The Repr-Digest field can be used for the integrity
of HTTP representations. Want-Content-Digest and Want-Repr-Digest
can be used to indicate a sender's interest and preferences for
receiving the respective Integrity fields.

This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP
fields.

"HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny,

2022-07-11, <draft-ietf-httpbis-message-signatures-11.txt>

This document describes a mechanism for creating, encoding, and

verifying digital signatures or message authentication codes over
components of an HTTP message. This mechanism supports use cases
where the full HTTP message may not be known to the signer, and where
the message may be transformed (e.g., by intermediaries) before
reaching the verifier. This document also describes a means for
requesting that a signature be applied to a subsequent HTTP message
in an ongoing HTTP exchange.

"The HTTP QUERY Method", Julian Reschke, Ashok Malhotra, James Snell,
2022-07-04, <draft-ietf-httpbis-safe-method-w-body-03.txt>

This specification defines a new HTTP method, QUERY, as a safe,

idempotent request method that can carry request content.

"Client-Cert HTTP Header Field", Brian Campbell, Mike Bishop, 2022-05-25,

<draft-ietf-httpbis-client-cert-field-02.txt>

This document defines HTTP extension header fields that allow a TLS
terminating reverse proxy to convey the client certificate
information of a mutually-authenticated TLS connection to the origin
 server in a common and predictable manner.

"Retrofit Structured Fields for HTTP", Mark Nottingham, 2022-06-08,

<draft-ietf-httpbis-retrofit-04.txt>

This specification nominates a selection of existing HTTP fields as

having syntax that is compatible with Structured Fields, so that they
can be handled as such (subject to certain caveats).

To accommodate some additional fields whose syntax is not compatible,

it also defines mappings of their semantics into new Structured
Fields. It does not specify how to negotiate their use.

"The ORIGIN Extension in HTTP/3", Mike Bishop, 2022-06-13,

<draft-ietf-httpbis-origin-h3-00.txt>

The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but

needs to be separately registered. This document describes the
ORIGIN frame for HTTP/3.

Interface to Network Security Functions (i2nsf)

-----------------------------------------------

"Applicability of Interfaces to Network Security Functions to Network-Based

Security Services", Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares,
Diego Lopez, 2019-09-16, <draft-ietf-i2nsf-applicability-18.txt>

This document describes the applicability of Interface to Network

Security Functions (I2NSF) to network-based security services in
Network Functions Virtualization (NFV) environments, such as
firewall, deep packet inspection, or attack mitigation engines.

"I2NSF Consumer-Facing Interface YANG Data Model", Jaehoon Jeong, Chaehong

Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2022-08-08,
<draft-ietf-i2nsf-consumer-facing-interface-dm-23.txt>

This document describes an information model and the corresponding

YANG data model for the Consumer-Facing Interface of the Security
Controller in an Interface to Network Security Functions (I2NSF)
system in a Network Functions Virtualization (NFV) environment. The
information model defines various types of managed objects and the
relationship among them needed to build the flow policies from users'
perspective. This information model is based on the "Event-
Condition-Action" (ECA) policy model defined by a capability
information model for I2NSF, and the YANG data model is defined for
enabling different users of a given I2NSF system to define, manage,
and monitor flow policies within an administrative domain (e.g., user
group).

"I2NSF Network Security Function-Facing Interface YANG Data Model", Jinyong

Kim, Jaehoon Jeong, J., PARK, Susan Hares, Qiushi Lin, 2022-06-01,
<draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt>

This document defines a YANG data model for configuring security

policy rules on Network Security Functions (NSF) in the Interface to
Network Security Functions (I2NSF) framework. The YANG data model in
this document is for the NSF-Facing Interface between a Security
Controller and NSFs in the I2NSF framework. It is built on the basis
of the YANG data model in the I2NSF Capability YANG Data Model
 document for the I2NSF framework.

"I2NSF Capability YANG Data Model", Susan Hares, Jaehoon Jeong, Jinyong
Kim, Robert Moskowitz, Qiushi Lin, 2022-05-23,
<draft-ietf-i2nsf-capability-data-model-32.txt>

This document defines an information model and the corresponding YANG

data model for the capabilities of various Network Security Functions
(NSFs) in the Interface to Network Security Functions (I2NSF)
framework to centrally manage the capabilities of the various NSFs.

"I2NSF Registration Interface YANG Data Model for NSF Capability

Registration", Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J.,
PARK, 2022-08-31, <draft-ietf-i2nsf-registration-interface-dm-20.txt>

This document defines an information model and a YANG data model for
Registration Interface between Security Controller and Developer's
Management System (DMS) in the Interface to Network Security
Functions (I2NSF) framework to register Network Security Functions
(NSF) of the DMS with the Security Controller. The objective of
these information and data models is to support NSF capability
registration and query via I2NSF Registration Interface.

"I2NSF NSF Monitoring Interface YANG Data Model", Jaehoon Jeong, Patrick
Lingga, Susan Hares, Liang Xia, Henk Birkholz, 2022-06-01,
<draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt>

This document proposes an information model and the corresponding

YANG data model of an interface for monitoring Network Security
Functions (NSFs) in the Interface to Network Security Functions
(I2NSF) framework. If the monitoring of NSFs is performed with the
NSF monitoring interface in a standard way, it is possible to detect
the indication of malicious activity, anomalous behavior, the
potential sign of denial-of-service attacks, or system overload in a
timely manner. This monitoring functionality is based on the
monitoring information that is generated by NSFs. Thus, this
document describes not only an information model for the NSF
monitoring interface along with a YANG tree diagram, but also the
corresponding YANG data model.

Internet Architecture Board (iab)

---------------------------------

"The Harmful Consequences of the Robustness Principle", Martin Thomson,

David Schinazi, 2022-07-11, <draft-iab-protocol-maintenance-08.txt>

The robustness principle, often phrased as "be conservative in what

you send, and liberal in what you accept", has long guided the design
and implementation of Internet protocols. The posture this statement
advocates promotes interoperability in the short term, but can
negatively affect the protocol ecosystem over time. For a protocol
that is actively maintained, the robustness principle can, and
should, be avoided.

"The "xml2rfc" version 3 Vocabulary", Heather Flanagan, 2022-04-11,

<draft-iab-rfc7991bis-04.txt>

This document defines the "xml2rfc" version 3 vocabulary: an XML-

based language used for writing RFCs and Internet-Drafts. It is
 heavily derived from the version 2 vocabulary that is also under
discussion. This document obsoletes the earlier v3 grammar described
in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749.

"IAB workshop report: Measuring Network Quality for End-Users", Wes

Hardaker, Omer Shapira, 2022-08-10, <draft-iab-mnqeu-report-04.txt>

The Measuring Network Quality for End-Users workshop was held

virtually by the Internet Architecture Board (IAB) from September
14-16, 2021. This report summarizes the workshop, the topics
discussed, and some preliminary conclusions drawn at the end of the
workshop.

"Report from the IAB Workshop on Analyzing IETF Data (AID), 2021", Niels
ten Oever, Corinne Cath, Mirja Kuehlewind, Colin Perkins, 2022-05-30,
<draft-iab-aid-workshop-01.txt>

The 'Show me the numbers: Workshop on Analyzing IETF Data (AID)' was
convened by the Internet Architecture Board (IAB) from November 29 to
December 2 and hosted by the IN-SIGHT.it project at the University of
Amsterdam, however, converted to an online only event. The workshop
was conducted based on two discussion parts and a hackathon activity
in between. This report summarizes the workshop's discussion and
identifies topics that warrant future work and consideration.

Note that this document is a report on the proceedings of the

workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.

"Considerations on Application - Network Collaboration Using Path Signals",

Jari Arkko, Ted Hardie, Tommy Pauly, Mirja Kuehlewind, 2022-07-11,
<draft-iab-path-signals-collaboration-01.txt>

This document discusses principles for designing mechanisms that use

or provide path signals, and calls for standards action in specific
valuable cases. RFC 8558 describes path signals as messages to or
from on-path elements, and points out that visible information will
be used whether it is intended as a signal or not. The principles in
this document are intended as guidance for the design of explicit
path signals, which are encouraged to be authenticated and include a
minimal set of parties and minimize information sharing. These
principles can be achieved through mechanisms like encryption of
information and establishing trust relationships between entities on
a path.

Internet Congestion Control (iccrg)

-----------------------------------

"rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP",

Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen
Balasubramanian, 2022-03-20, <draft-irtf-iccrg-rledbat-02.txt>

This document specifies the rLEDBAT, a set of mechanisms that enable

the execution of a less-than-best-effort congestion control algorithm
for TCP at the receiver end.

Information-Centric Networking (icnrg)

--------------------------------------
 "CCNinfo: Discovering Content and Network Information in Content-Centric
Networks", Hitoshi Asaeda, Atsushi Ooka, Xun Shao, 2022-09-01,
<draft-irtf-icnrg-ccninfo-12.txt>

This document describes a mechanism named "CCNinfo" that discovers

information about the network topology and in-network cache in
Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN
routing path information per name prefix, 2) the Round-Trip Time
(RTT) between the content forwarder and consumer, and 3) the states
of in-network cache per name prefix. CCNinfo is useful to understand
and debug the behavior of testbed networks and other experimental
deployments of CCN systems.

This document is a product of the IRTF Information-Centric Networking

Research Group (ICNRG). This document represents the consensus view
of ICNRG and has been reviewed extensively by several members of the
ICN community and the RG. The authors and RG chairs approve of the
contents. The document is sponsored under the IRTF and is not issued
by the IETF and is not an IETF standard. This is an experimental
protocol and the specification may change in the future.

"ICN Ping Protocol Specification", Spyridon Mastorakis, Jim Gibson, Ilya

Moiseenko, Ralph Droms, David Oran, 2022-05-03,
<draft-irtf-icnrg-icnping-06.txt>

This document presents the design of an ICN Ping protocol. It

includes the operations of both the client and the forwarder. This
document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG).

"ICN Traceroute Protocol Specification", Spyridon Mastorakis, Jim Gibson,

Ilya Moiseenko, Ralph Droms, David Oran, 2022-05-03,
<draft-irtf-icnrg-icntraceroute-06.txt>

This document presents the design of an ICN Traceroute protocol.

This includes the operation of both the client and the forwarder.
This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG).

"Alternative Delta Time Encoding for CCNx Using Compact Floating-Point

Arithmetic", Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch,
2022-04-27, <draft-irtf-icnrg-ccnx-timetlv-00.txt>

CCNx utilizes delta time for a number of functions. When using CCNx
in environments with constrained nodes or bandwidth constrained
networks, it is valuable to have a compressed representation of delta
time. In order to do so, either accuracy or dynamic range has to be
sacrificed. Since the current uses of delta time do not require both
simultaneously, one can consider a logarithmic encoding such as that
specified in [RFC5497] and [IEEE.754.2019]. This document updates
_CCNx messages in TLV Format_ [RFC8609] to specify this alternative
encoding.

Inter-Domain Routing (idr)

--------------------------

"Distribution of Traffic Engineering (TE) Policies and State using BGP-LS",

Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler,
Jeff Tantsura, 2022-08-22, <draft-ietf-idr-te-lsp-distribution-18.txt>

This document describes a mechanism to collect the Traffic

Engineering Policy information that is locally available in a node
and advertise it into BGP Link State (BGP-LS) updates. Such
information can be used by external components for path computation,
re-optimization, service placement, network visualization, etc.

"BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald

Eastlake, Stephane Litkowski, Shunwan Zhuang, 2022-04-18,
<draft-ietf-idr-flowspec-l2vpn-19.txt>

This document defines a Border Gateway Protocol (BGP) Flow

Specification (flowspec) extension to disseminate Ethernet Layer 2
(L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering
rules either by themselves or in conjunction with L3 flowspecs.
AFI/SAFI 6/133 and 25/134 are used for these purposes. New component
types and two extended communities are also defined.

"BGP Community Container Attribute", Robert Raszuk, Jeffrey Haas, Andrew

Lange, Bruno Decraene, Shane Amante, Paul Jakma, 2022-07-11,
<draft-ietf-idr-wide-bgp-communities-08.txt>

Route tagging plays an important role in external BGP relations,

communicating various routing policies between peers. It is also a
very common best practice for operators to propagate various
additional route information between internal peers. The most common
tool used today to attach various information about routes is through
the use of BGP communities.

This document defines a new encoding which will enhance and simplify
what can be accomplished today with the use of BGP communities. The
most important addition this specification makes over currently
defined BGP communities is the ability to specify and advertise an
operator's parameters for execution It also provides an extensible
platform for any future community encoding requirements.

"BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur
Patel, Susan Hares, Jeffrey Haas, 2022-07-03,
<draft-ietf-idr-bgp-model-14.txt>

This document defines a YANG data model for configuring and managing
BGP, including protocol, policy, and operational aspects, such as
RIB, based on data center, carrier, and content provider operational
requirements.

"BGP Dissemination of Flow Specification Rules for Tunneled Traffic",

Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu,
2022-07-10, <draft-ietf-idr-flowspec-nvo3-16.txt>

This draft specifies a Border Gateway Protocol (BGP) Network Layer

Reachability Information (NLRI) encoding format for flow
specifications (RFC 8955) that can match on a variety of tunneled
traffic. In addition, flow specification components are specified for
certain tunneling header fields.

"BGP Next-Hop dependent capabilities", Bruno Decraene, Kireeti Kompella,

Wim Henderickx, 2022-06-08, <draft-ietf-idr-next-hop-capability-08.txt>
 RFC 5492 advertises the capabilities of the BGP peer. When the BGP
peer is not the same as the BGP Next-Hop, it is useful to also be
able to advertise the capability of the BGP Next-Hop, in particular
to advertise forwarding plane features. This document defines a
mechanism to advertise such BGP Next Hop dependent Capabilities.

This document defines a new BGP non-transitive attribute to carry

Next-Hop Capabilities. This attribute is guaranteed to be deleted or
updated when the BGP Next Hop is changed, in order to reflect the
capabilities of the new BGP Next-Hop.

This document also defines a Next-Hop capability to advertise the

ability to process the MPLS Entropy Label as an egress LSR for all
NLRI advertised in the BGP UPDATE. It updates RFC 6790 with regard
to this BGP signaling.

"Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence

Filsfils, Ketan Talaulikar, Paul Mattes, Dhanendra Jain, Steven Lin,
2022-07-27, <draft-ietf-idr-segment-routing-te-policy-20.txt>

This document introduces a BGP SAFI with two NLRIs to advertise a

candidate path of a Segment Routing (SR) Policy. An SR Policy is an
ordered list of segments (i.e., instructions) that represent a
source-routed policy. An SR Policy consists of one or more candidate
paths, each consisting of one or more segment lists. A headend may
be provisioned with candidate paths for an SR Policy via several
different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This
document specifies how BGP may be used to distribute SR Policy
candidate paths. It defines sub-TLVs for the Tunnel Encapsulation
Attribute for signaling information about these candidate paths.

This documents updates RFC9012 with extensions to the Color Extended

Community to support additional steering modes over SR Policy.

"BGP-LS Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo

Chen, Ketan Talaulikar, Shunwan Zhuang, 2022-05-12,
<draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt>

This document describes the process to build Border Gateway Protocol-

Link State (BGP-LS) key parameters in inter-domain scenario, defines
one new BGP-LS Network Layer Reachability Information (NLRI) type
(Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic
Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let
Software Definition Network (SDN) controller retrieve the network
topology automatically under various inter-AS environments.

Such extension and process can enable the network operator to collect
the interconnect information between different domains and then
calculate the overall network topology automatically based on the
information provided by BGP-LS protocol.

"BGP Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils,
Ketan Talaulikar, Mach Chen, Daniel Bernier, Bruno Decraene, 2021-11-10,
<draft-ietf-idr-bgpls-srv6-ext-09.txt>

Segment Routing over IPv6 (SRv6) allows for a flexible definition of

end-to-end paths within various topologies by encoding paths as
sequences of topological or functional sub-paths, called "segments".
These segments are advertised by various protocols such as BGP, IS-IS
 and OSPFv3.

This document defines extensions to BGP Link-state (BGP-LS) to

advertise SRv6 segments along with their behaviors and other
attributes via BGP. The BGP-LS address-family solution for SRv6
described in this document is similar to BGP-LS for SR for the MPLS
data-plane defined in a separate document.

"Flexible Algorithm Advertisement using BGP Link-State", Ketan Talaulikar,

Peter Psenak, Shawn Zandi, Gaurav Dawra, 2022-08-24,
<draft-ietf-idr-bgp-ls-flex-algo-12.txt>

Flexible Algorithm is a solution that allows some routing protocols

(e.g., OSPF and IS-IS) to compute paths over a network based on user-
defined (and hence, flexible) constraints and metrics. The
computation is performed by routers participating in the specific
network in a distributed manner using a Flexible Algorithm
Definition. This Definition is provisioned on one or more routers
and propagated through the network by OSPF and IS-IS flooding.

BGP Link-State (BGP-LS) enables the collection of various topology

information from the network. This document defines extensions to
the BGP-LS address family to advertise the Flexible Algorithm
Definition as a part of the topology information from the network.

"Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari,

Kotikalapudi Sriram, Lilia Hannachi, Jeffrey Haas, 2022-03-07,
<draft-ietf-idr-deprecate-as-set-confed-set-07.txt>

BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
AS_CONFED_SET in the Border Gateway Protocol. This document advances
this recommendation to a standards requirement in BGP; it proscribes
the use of the AS_SET and AS_CONFED_SET types of path segments in the
AS_PATH. This is done to simplify the design and implementation of
BGP and to make the semantics of the originator of a route clearer.
This will also simplify the design, implementation, and deployment of
various BGP security mechanisms. This document (if approved) updates
RFC 4271 and RFC 5065 by eliminating AS_SET and AS_CONFED_SET types,
and obsoletes RFC 6472.

"Support for Long-lived BGP Graceful Restart", Jim Uttaro, Enke Chen, Bruno
Decraene, John Scudder, 2022-08-29, <draft-ietf-idr-long-lived-gr-01.txt>

In this document we introduce a new BGP capability termed "Long-lived

Graceful Restart Capability" so that stale routes can be retained for
a longer time upon session failure. A well-known BGP community
"LLGR_STALE" is introduced for marking stale routes retained for a
longer time. A second well-known BGP community, "NO_LLGR", is
introduced to mark routes for which these procedures should not be
applied. We also specify that such long-lived stale routes be
treated as the least-preferred, and their advertisements be limited
to BGP speakers that have advertised the new capability. Use of this
extension is not advisable in all cases, and we provide guidelines to
help determine if it is.

We update RFC 6368 by specifying that the LLGR_STALE community must

be propagated into, or out of, the path attributes exchanged between
PE and CE.
"Distribution of Link-State and Traffic Engineering Information Using BGP",
Ketan Talaulikar, 2021-11-10, <draft-ietf-idr-rfc7752bis-10.txt>

In a number of environments, a component external to a network is

called upon to perform computations based on the network topology and
the current state of the connections within the network, including
Traffic Engineering (TE) information. This is information typically
distributed by IGP routing protocols within the network.

This document describes a mechanism by which link-state and TE

information can be collected from networks and shared with external
components using the BGP routing protocol. This is achieved using a
new BGP Network Layer Reachability Information (NLRI) encoding
format. The mechanism is applicable to physical and virtual IGP
links. The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic

Optimization (ALTO) servers and Path Computation Elements (PCEs).

This document obsoletes RFC 7752 by completely replacing that

document. It makes some small changes and clarifications to the
previous specification. This document also obsoletes RFC 9029 by
incorporating the updates which it made to RFC 7752.

"BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu,
2022-05-02, <draft-ietf-idr-bgp-bfd-strict-mode-07.txt>

This document specifies extensions to RFC4271 BGP-4 that enable a BGP

speaker to negotiate additional Bidirectional Forwarding Detection
(BFD) extensions using a BGP capability. This BFD capability enables
a BGP speaker to prevent a BGP session from being established until a
BFD session is established. It is referred to as BGP BFD "strict-
mode". BGP BFD strict-mode will be supported when both the local
speaker and its remote peer are BFD strict-mode capable.

"SR Policy Extensions for Path Segment and Bidirectional Path", Cheng Li,
Zhenbin Li, Yuanyang Yin, Weiqiang Cheng, Ketan Talaulikar, 2022-08-07,
<draft-ietf-idr-sr-policy-path-segment-06.txt>

A Segment Routing (SR) policy is a set of candidate SR paths

consisting of one or more segment lists with necessary path
attributes. For each SR path, it may also have its own path
attributes, and Path Segment is one of them. A Path Segment is
defined to identify an SR path, which can be used for performance
measurement, path correlation, and end-2-end path protection. Path
Segment can be also used to correlate two unidirectional SR paths
into a bidirectional SR path which is required in some scenarios, for
example, mobile backhaul transport network.

This document defines extensions to BGP to distribute SR policies

carrying Path Segment and bidirectional path information.

"BGP Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang
Ou, Yujia Luo, Sujian Lu, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Haibo
Wang, 2022-01-25, <draft-ietf-idr-rpd-15.txt>

It is hard to adjust traffic and optimize traffic paths in a

traditional IP network from time to time through manual
configurations. It is desirable to have a mechanism for setting up
 routing policies, which adjusts traffic and optimizes traffic paths
automatically. This document describes BGP Extensions for Routing
Policy Distribution (BGP RPD) to support this.

"SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS",
Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar,
2022-08-07, <draft-ietf-idr-bgp-ls-sr-policy-path-segment-03.txt>

This document specifies the way of collecting configuration and

states of SR policies carrying Path Segment and bidirectional path
information by using BPG-LS. Such information can be used by
external conponents for many use cases such as performance
measurement, path re-optimization and end-to-end protection.

"Segment Routing Path MTU in BGP", Cheng Li, Yongqing Zhu, Ahmed El Sawaf,
Zhenbin Li, 2022-04-21, <draft-ietf-idr-sr-policy-path-mtu-05.txt>

Segment Routing is a source routing paradigm that explicitly

indicates the forwarding path for packets at the ingress node. An SR
policy is a set of candidate SR paths consisting of one or more
segment lists with necessary path attributes. However, the path
maximum transmission unit (MTU) information for SR path is not
available in the SR policy since the SR does not require signaling.
This document defines extensions to BGP to distribute path MTU
information within SR policies.

"Signaling Maximum Transmission Unit (MTU) using BGP-LS", Yongqing Zhu,

Zhibo Hu, Shuping Peng, Robbins Mwehair, 2022-05-30,
<draft-ietf-idr-bgp-ls-link-mtu-03.txt>

BGP Link State (BGP-LS) describes a mechanism by which link-state and

TE information can be collected from networks and shared with
external components using the BGP routing protocol. The centralized
controller (PCE/SDN) completes the service path calculation based on
the information transmitted by the BGP-LS and delivers the result to
the Path Computation Client (PCC) through the PCEP or BGP protocol.

Segment Routing (SR) leverages the source routing paradigm, which can
be directly applied to the MPLS architecture with no change on the
forwarding plane and applied to the IPv6 architecture, with a new
type of routing header, called SRH. The SR uses the IGP protocol as
the control protocol. Compared to the MPLS tunneling technology, the
SR does not require additional signaling. Therefore, the SR does not
support the negotiation of the Path MTU. Since multiple labels or
SRv6 SIDs are pushed in the packets, it is more likely that the
packet size exceeds the path mtu of SR tunnel.

This document specifies the extensions to BGP Link State (BGP-LS) to

carry maximum transmission unit (MTU) messages of link. The PCE/SDN
calculates the Path MTU while completing the service path calculation
based on the information transmitted by the BGP-LS.

"BGP SR Policy Extensions to Enable IFIT", Fengwei Qin, Hang Yuan, Shunxing
Yang, Tianran Zhou, Giuseppe Fioccola, 2022-07-07,
<draft-ietf-idr-sr-policy-ifit-04.txt>

Segment Routing (SR) policy is a set of candidate SR paths consisting

of one or more segment lists and necessary path attributes. It
enables instantiation of an ordered list of segments with a specific
 intent for traffic steering. In-situ Flow Information Telemetry
(IFIT) refers to network OAM data plane on-path telemetry techniques,
in particular the most popular are In-situ OAM (IOAM) and Alternate
Marking. This document defines extensions to BGP to distribute SR
policies carrying IFIT information. So that IFIT methods can be
enabled automatically when the SR policy is applied.

"BGP Color-Aware Routing (CAR)", Dhananjaya Rao, Swadesh Agrawal, Clarence

Filsfils, Dirk Steinberg, Luay Jalil, Yuanchao Su, Bruno Decraene, Jim
Guichard, Ketan Talaulikar, Keyur Patel, Haibo Wang, Jim Uttaro,
2022-07-06, <draft-dskc-bess-bgp-car-05.txt>

This document describes a BGP based routing solution to establish

end-to-end intent-aware paths across a multi-domain service provider
transport network. This solution is called BGP Color-Aware Routing
(BGP CAR).

"BGP Link-State Extensions for BGP-only Fabric", Ketan Talaulikar, Clarence

Filsfils, krishnaswamy ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad
Durrani, 2022-05-13, <draft-ietf-idr-bgp-ls-bgp-only-fabric-03.txt>

BGP is used as the only routing protocol in some networks today. In

such networks, it is useful to get a detailed view of the nodes and
underlying links in the topology along with their attributes similar
to one available when using link state routing protocols. Such a
view of a BGP-only fabric enables use cases like traffic engineering
and forwarding of services along paths other than the BGP best path
selection.

This document defines extensions to the BGP Link-state address-family

(BGP-LS) and the procedures for advertisement of the topology in a
BGP-only network. It also describes a specific use-case for traffic
engineering based on Segment Routing.

"BGP UPDATE for SDWAN Edge Discovery", Linda Dunbar, Susan Hares, Robert
Raszuk, Kausik Majumdar, Gyan Mishra, 2022-08-13,
<draft-ietf-idr-sdwan-edge-discovery-04.txt>

The document describes the encoding of BGP UPDATE messages for the
SDWAN edge node property discovery.

In the context of this document, BGP Route Reflector (RR) is the

component of the SDWAN Controller that receives the BGP UPDATE from
SDWAN edges and in turns propagates the information to the intended
peers that are authorized to communicate via the SDWAN overlay
network.

"BGP Flow Specification for SRv6", Zhenbin Li, Lei Li, Huaimo Chen,
Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Xufeng Liu,
2022-04-08, <draft-ietf-idr-flowspec-srv6-01.txt>

This document proposes extensions to BGP Flow Specification for SRv6

for filtering packets with a SRv6 SID that matches a sequence of
conditions.

"BGP-LS Advertisement of Segment Routing Service Segments", Gaurav Dawra,

Clarence Filsfils, Ketan Talaulikar, Francois Clad, Daniel Bernier, Jim
Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Jim Guichard, Cheng Li,
2022-04-24, <draft-ietf-idr-bgp-ls-sr-service-segments-01.txt>
 Service functions are deployed as, physical or virtualized elements
along with network nodes or on servers in data centers. Segment
Routing (SR) brings in the concept of segments which can be
topological or service instructions. Service segments are SR
segments that are associated with service functions. SR Policies are
used for the setup of paths for steering of traffic through service
functions using their service segments.

BGP Link-State (BGP-LS) enables distribution of topology information

from the network to a controller or an application in general so it
can learn the network topology. This document specifies the
extensions to BGP-LS for the advertisement of service functions along
their associated service segments. The BGP-LS advertisement of
service function information along with the network nodes that they
are attached to, or associated with, enables controllers compute and
setup service paths in the network.

"BGP Cease Notification Subcode For BFD", Jeffrey Haas, 2022-08-21,

<draft-ietf-idr-bfd-subcode-03.txt>

The Bidirectional Forwarding Detection protocol (BFD) is used to

detect loss of connectivity between two forwarding engines, typically
with low latency. BFD is leveraged by routing protocols, including
the Border Gateway Protocol (BGP), to use that detection of loss of
connectivity to bring down the protocol connections faster than the
native protocol timers.

This document defines a Subcode for the BGP Cease NOTIFICATION

message for when a BGP connection is being closed due to a BFD
session going down.

"BGP Flow Specification Version 2", Susan Hares, Donald Eastlake, Chaitanya
Yadlapalli, Sven Maduschke, 2022-04-19, <draft-ietf-idr-flowspec-v2-00.txt>

BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC

8956, and RFC 9117 describes the distribution of traffic filter
policy (traffic filters and actions) distributed via BGP. Multiple
applications have used BGP FSv1 to distribute traffic filter policy.
These applications include the following: mitigation of denial of
service (DoS), enabling traffic filtering in BGP/MPLS VPNs,
centralized traffic control of router firewall functions, and SFC
traffic insertion.

During the deployment of BGP FSv1 a number of issues were detected

due to lack of consistent TLV encoding for rules for flow
specifications, lack of user ordering of filter rules and/or actions,
and lack of clear definition of interaction with BGP peers not
supporting FSv1. Version 2 of the BGP flow specification (FSv2)
protocol addresses these features. In order to provide a clear
demarcation between FSv1 and FSv2, a different NLRI encapsulates
FSv2.

"Advertising p2mp policies in BGP", Hooman Bidgoli, Dan Voyer, Andrew

Stone, Rishabh Parekh, Serge KRIER, Swadesh Agrawal, 2022-05-27,
<draft-ietf-idr-sr-p2mp-policy-00.txt>

SR P2MP policies are set of policies that enable architecture for

P2MP service delivery.
 A P2MP policy consists of candidate paths that connects the Root of
the Tree to a set of Leaves. The P2MP policy is composed of
replication segments. A replication segment is a forwarding
instruction for a candidate path which is downloaded to the Root,
transit nodes and the leaves.

This document specifies a new BGP SAFI with a new NLRI in order to
advertise P2MP policy from a controller to a set of nodes.

This document introduces three new route types within this NLRI, one
for P2MP policy and its candidate paths that need to be programmed on
the Root node, one for the replication segment incoming SID which
uniquely will identify the cross connect and another for each
outgoing interface that the packets get replicated to. The last two
route types are forwarding instructions that needs to be programmed
on the Root, and optionally on Transit and Leaf nodes.

It should be noted that this document does not specify how the Root
and the Leaves are discovered on the controller, it only describes
how the P2MP Policy and Replication Segments are programmed from the
controller to the nodes.

"BGP-LS Extensions for IS-IS Flood Reflection", Jordan Head, Tony

Przygienda, 2022-07-05, <draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt>

This document defines new BGP-LS (BGP Link-State) TLVs in order to

carry IS-IS Flood Reflection information.

"BGP for BIER-TE Path", Huaimo Chen, Mike McBride, Ran Chen, Gyan Mishra,
Aijun Wang, Yisong Liu, Yanhe Fan, Boris Khasanov, Lei Liu, Xufeng Liu,
2022-07-06, <draft-ietf-idr-bier-te-path-00.txt>

This document describes extensions to Border Gateway Protocol (BGP)

for distributing a Bit Index Explicit Replication Traffic/Tree
Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is
defined to encode the information about a BIER-TE path.

"BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT)

Capabilities", Giuseppe Fioccola, Ran Pang, Subin Wang, Shunwan Zhuang,
Haibo Wang, 2022-07-08, <draft-ietf-idr-bgp-ifit-capabilities-00.txt>

This document defines extensions to BGP [RFC4271] to advertise the

In-situ Flow Information Telemetry (IFIT) capabilities. Within an
IFIT domain, IFIT-capability advertisement from the tail node to the
head node assists the head node to determine whether a particular
IFIT Option type can be encapsulated in data packets. Such
advertisement would be useful for mitigating the leakage threat and
facilitating the deployment of IFIT measurements on a per-service and
on-demand basis.

"BGP Classful Transport Planes", Kaliraj Vairavakkalai, Natrajan

Venkataraman, Israel Means, Gyan Mishra, Deepak Gowda, 2022-08-15,
<draft-ietf-idr-bgp-classful-transport-planes-01.txt>

This document specifies a mechanism, referred to as "Intent Driven

Service Mapping" to express association of overlay routes with
underlay routes satisfying a certain SLA using BGP. The document
describes a framework for classifying underlay routes into transport
 classes and mapping service routes to specific transport class.

The "Transport class" construct maps to a desired SLA and can be used
to realize the "Topology Slice" in 5G Network slicing architecture.

This document specifies BGP protocol procedures that enable

dissemination of such service mapping information that may span
multiple cooperating administrative domains. These domains may be
administetered by the same provider or by closely co-ordinating
provider networks.

A new BGP transport layer address family (SAFI 76) is defined for
this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI
encoding. This new address family is called "BGP Classful
Transport", aka BGP CT.

BGP CT makes it possible to advertise multiple tunnels to the same

destination address, thus avoiding need of multiple loopbacks on the
egress node.

It carries transport prefixes across tunnel domain boundaries (e.g.

in Inter-AS Option-C networks), which is parallel to BGP LU (SAFI 4)
. It disseminates "Transport class" information for the transport
prefixes across the participating domains, which is not possible with
BGP LU. This makes the end-to-end network a "Transport Class" aware
tunneled network.

Though BGP CT family is used only in the option-C inter-AS neworks,

the Service Mapping procedures described in this document apply in
the same manner to Intra-AS service end points as well as Inter-AS
option-A, option-B and option-C variations.

"BGP Color-Aware Routing (CAR)", Dhananjaya Rao, Swadesh Agrawal,

2022-08-28, <draft-ietf-idr-bgp-car-00.txt>

This document describes a BGP based routing solution to establish

end-to-end intent-aware paths across a multi-domain service provider
transport network. This solution is called BGP Color-Aware Routing
(BGP CAR).

IP Performance Measurement (ippm)

---------------------------------

"Simple Two-way Active Measurement Protocol (STAMP) Data Model", Greg

Mirsky, Xiao Min, Wei Luo, 2022-07-10, <draft-ietf-ippm-stamp-yang-10.txt>

This document specifies the data model for implementations of

Session-Sender and Session-Reflector for Simple Two-way Active
Measurement Protocol (STAMP) mode using YANG.

"In-situ OAM IPv6 Options", Shwetha Bhandari, Frank Brockners, 2022-06-16,

<draft-ietf-ippm-ioam-ipv6-options-08.txt>

In-situ Operations, Administration, and Maintenance (IOAM) records

operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document
outlines how IOAM data fields are encapsulated in IPv6.

"In-situ OAM Loopback and Active Flags", Tal Mizrahi, Frank Brockners,
Shwetha Bhandari, Barak Gafni, Mickey Spiegel, 2022-08-18,
<draft-ietf-ippm-ioam-flags-10.txt>

In-situ Operations, Administration, and Maintenance (IOAM) collects

operational and telemetry information in packets while they traverse
a path between two points in the network. This document defines two
new flags in the IOAM Trace Option headers, specifically the Loopback
and Active flags.

"In-situ OAM Direct Exporting", Haoyu Song, Barak Gafni, Frank Brockners,
Shwetha Bhandari, Tal Mizrahi, 2022-08-18,
<draft-ietf-ippm-ioam-direct-export-10.txt>

In-situ Operations, Administration, and Maintenance (IOAM) is used

for recording and collecting operational and telemetry information.
Specifically, IOAM allows telemetry data to be pushed into data
packets while they traverse the network. This document introduces a
new IOAM option type (denoted IOAM-Option-Type) called the Direct
Export (DEX) Option-Type, which is used as a trigger for IOAM data to
be directly exported or locally aggregated without being pushed into
in-flight data packets. The exporting method and format are outside
the scope of this document.

"A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2022-05-06,

<draft-ietf-ippm-connectivity-monitoring-04.txt>

Within a Segment Routing domain, segment routed measurement packets

can be sent along pre-determined paths. This enables new kinds of
measurements. Connectivity monitoring allows to supervise the state
and performance of a connection or a (sub)path from one or a few
central monitoring systems. This document specifies a suitable
type-P connectivity monitoring metric.

"A YANG Data Model for In-Situ OAM", Tianran Zhou, Jim Guichard, Frank
Brockners, Srihari Raghavan, 2022-07-07, <draft-ietf-ippm-ioam-yang-04.txt>

In-situ Operations, Administration, and Maintenance (IOAM) records

operational and telemetry information in user packets while the
packets traverse a path between two points in the network. This
document defines a YANG module for the IOAM function.

"Simple TWAMP (STAMP) Extensions for Segment Routing Networks", Rakesh

Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Richard
Foote, 2022-09-02, <draft-ietf-ippm-stamp-srpm-06.txt>

Segment Routing (SR) leverages the source routing paradigm. SR is

applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) forwarding planes. This document specifies RFC 8762 (Simple
Two-Way Active Measurement Protocol (STAMP)) extensions for SR
networks, for both SR-MPLS and SRv6 forwarding planes by augmenting
the optional extensions defined in RFC 8972.

"Echo Request/Reply for Enabled In-situ OAM Capabilities", Xiao Min, Greg
Mirsky, Lei Bo, 2022-07-06, <draft-ietf-ippm-ioam-conf-state-04.txt>

This document describes an extension to the echo request/reply

mechanisms used in IPv6 (including Segment Routing with IPv6 data
plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
(SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
 Replication (BIER) environments, which can be used within the In situ
Operations, Administration, and Maintenance (IOAM) domain, allowing
the IOAM encapsulating node to discover the enabled IOAM capabilities
of each IOAM transit and IOAM decapsulating node.

"Integrity of In-situ OAM Data Fields", Frank Brockners, Shwetha Bhandari,

Tal Mizrahi, Justin Iurman, 2022-07-05,
<draft-ietf-ippm-ioam-data-integrity-02.txt>

In-situ Operations, Administration, and Maintenance (IOAM) records

operational and telemetry information in the packet while the packet
traverses a path in the network. IETF protocols require features to
ensure their security. This document describes the integrity
protection of IOAM-Data-Fields.

"In-situ OAM Deployment", Frank Brockners, Shwetha Bhandari, Daniel

Bernier, Tal Mizrahi, 2022-04-11, <draft-ietf-ippm-ioam-deployment-01.txt>

In-situ Operations, Administration, and Maintenance (IOAM) collects

operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document
provides a framework for IOAM deployment and provides best current
practices.

"Explicit Flow Measurements Techniques", Mauro Cociglio, Alexandre

Ferrieux, Giuseppe Fioccola, Igor Lubashev, Fabio Bulgarella, Isabelle
Hamchaoui, Massimo Nilo, Riccardo Sisto, Dmitri Tikhonov, 2022-05-05,
<draft-ietf-ippm-explicit-flow-measurements-01.txt>

This document describes protocol independent methods called Explicit

Flow Measurement Techniques that employ few marking bits, inside the
header of each packet, for loss and delay measurement. The
endpoints, marking the traffic, signal these metrics to intermediate
observers allowing them to measure connection performance, and to
locate the network segment where impairments happen. Different
alternatives are considered within this document. These signaling
methods apply to all protocols but they are especially valuable when
applied to protocols that encrypt transport header and do not allow
traditional methods for delay and loss detection.

"Test Protocol for One-way IP Capacity Measurement", Len Ciavattone, Alfred

Morton, 2022-07-09, <draft-ietf-ippm-capacity-protocol-02.txt>

This memo addresses the problem of protocol support for measuring

Network Capacity metrics in RFC 9097, where the method deploys a
feedback channel from the receiver to control the sender's
transmission rate in near-real-time. This memo defines a simple
protocol to perform the RFC 9097 (and other) measurements.

See Section 10: The authors seek feedback to determine what

additional features will be necessary for an IETF Standards Track
Protocol, beyond what is present in the running code available now.

"Responsiveness under Working Conditions", Christoph Paasch, Randall Meyer,

Stuart Cheshire, Omer Shapira, Matt Mathis, 2022-07-11,
<draft-ietf-ippm-responsiveness-01.txt,.pdf>

For many years, a lack of responsiveness, variously called lag,

latency, or bufferbloat, has been recognized as an unfortunate, but
 common, symptom in today's networks. Even after a decade of work on
standardizing technical solutions, it remains a common problem for
the end users.

Everyone "knows" that it is "normal" for a video conference to have

problems when somebody else at home is watching a 4K movie or
uploading photos from their phone. However, there is no technical
reason for this to be the case. In fact, various queue management
solutions (fq_codel, cake, PIE) have solved the problem.

Our networks remain unresponsive, not from a lack of technical

solutions, but rather a lack of awareness of the problem and its
solutions. We believe that creating a tool whose measurement matches
people's everyday experience will create the necessary awareness, and
result in a demand for products that solve the problem.

This document specifies the "RPM Test" for measuring responsiveness.

It uses common protocols and mechanisms to measure user experience
specifically when the network is under working conditions. The
measurement is expressed as "Round-trips Per Minute" (RPM) and should
be included with throughput (up and down) and idle latency as
critical indicators of network quality.

"IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination

Option", Nalini Elkins, mackermann@bcbsm.com, Ameya Deshpande, Tommaso
Pecorella, Adnan Rashid, 2022-06-20,
<draft-ietf-ippm-encrypted-pdmv2-01.txt>

RFC8250 describes an optional Destination Option (DO) header embedded

in each packet to provide sequence numbers and timing information as
a basis for measurements. As this data is sent in clear- text, this
may create an opportunity for malicious actors to get information for
subsequent attacks. This document defines PDMv2 which has a
lightweight handshake (registration procedure) and encryption to
secure this data. Additional performance metrics which may be of use
are also defined.

"Alternate-Marking Method", Giuseppe Fioccola, Mauro Cociglio, Greg Mirsky,

Tal Mizrahi, Tianran Zhou, 2022-07-25, <draft-ietf-ippm-rfc8321bis-03.txt>

This document describes the Alternate-Marking technique to perform

packet loss, delay, and jitter measurements on live traffic. This
technology can be applied in various situations and for different
protocols. According to the classification defined in RFC 7799, it
could be considered Passive or Hybrid depending on the application.
This document obsoletes RFC 8321.

"Multipoint Alternate-Marking Clustered Method", Giuseppe Fioccola, Mauro

Cociglio, Amedeo Sapio, Riccardo Sisto, Tianran Zhou, 2022-07-25,
<draft-ietf-ippm-rfc8889bis-03.txt>

This document generalizes and expands Alternate-Marking methodology

to measure any kind of unicast flow whose packets can follow several
different paths in the network -- in wider terms, a multipoint-to-
multipoint network. For this reason, the technique here described is
called "Multipoint Alternate-Marking". This document obsoletes RFC
8889.

IP Security Maintenance and Extensions (ipsecme)

------------------------------------------------

"Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana
Prasad, 2022-03-24, <draft-ietf-ipsecme-labeled-ipsec-07.txt>

This document defines a new Traffic Selector (TS) Type for Internet
Key Exchange version 2 to add support for negotiating Mandatory
Access Control (MAC) security labels as a traffic selector of the
Security Policy Database (SPD). Security Labels for IPsec are also
known as "Labeled IPsec". The new TS type is TS_SECLABEL, which
consists of a variable length opaque field specifying the security
label. This document updates the IKEv2 TS negotiation specified in
RFC 7296 Section 2.9.

"IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP
Traffic Flow Security", Christian Hopps, 2022-09-04,
<draft-ietf-ipsecme-iptfs-19.txt>

This document describes a mechanism for aggregation and fragmentation

of IP packets when they are being encapsulated in ESP payloads. This
new payload type can be used for various purposes such as decreasing
encapsulation overhead for small IP packets; however, the focus in
this document is to enhance IPsec traffic flow security (IP-TFS) by
adding Traffic Flow Confidentiality (TFC) to encrypted IP
encapsulated traffic. TFC is provided by obscuring the size and
frequency of IP traffic using a fixed-sized, constant-send-rate IPsec
tunnel. The solution allows for congestion control as well as non-
constant send-rate usage.

"Group Key Management using IKEv2", Valery Smyslov, Brian Weis, 2022-04-06,
<draft-ietf-ipsecme-g-ikev2-06.txt>

This document presents an extension to the Internet Key Exchange

version 2 (IKEv2) protocol for the purpose of a group key management.
The protocol is in conformance with the Multicast Security (MSEC) key
management architecture, which contains two components: member
registration and group rekeying. Both components require a Group
Controller/Key Server to download IPsec group security associations
to authorized members of a group. The group members then exchange IP
multicast or other group traffic as IPsec packets. This document
obsoletes RFC 6407. This documents also updates RFC 7296 by renaming
one of transform types defined there.

"Multiple Key Exchanges in IKEv2", C. Tjhai, M. Tomlinson, G. Bartlett,

Scott Fluhrer, Daniel Van Geest, Oscar Garcia-Morchon, Valery Smyslov,
2022-06-13, <draft-ietf-ipsecme-ikev2-multiple-ke-06.txt>

This document describes how to extend the Internet Key Exchange

Protocol Version 2 (IKEv2) to allow multiple key exchanges to take
place while computing a shared secret during a Security Association
(SA) setup. The primary application of this feature in IKEv2 is the
ability to perform one or more post-quantum key exchanges in
conjunction with the classical (Elliptic Curve) Diffie-Hellman key
exchange, so that the resulting shared key is resistant against
quantum computer attacks. Another possible application is the
ability to combine several key exchanges in situations when no single
key exchange algorithm is trusted by both initiator and responder.

This document updates RFC7296 by renaming a transform type 4 from

 "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and
renaming a field in the Key Exchange Payload from "Diffie-Hellman
Group Num" to "Key Exchange Method". It also renames an IANA
registry for this transform type from "Transform Type 4 - Diffie-
Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange
Method Transform IDs". These changes generalize key exchange
algorithms that can be used in IKEv2.

"A YANG Data Model for IP Traffic Flow Security", Don Fedyk, Christian
Hopps, 2022-08-31, <draft-ietf-ipsecme-yang-iptfs-10.txt>

This document describes a YANG module for the management of IP

Traffic Flow Security additions to IKEv2 and IPsec.

"Deprecation of IKEv1 and obsoleted algorithms", Paul Wouters, 2022-06-10,

<draft-ietf-ipsecme-ikev1-algo-to-historic-06.txt>

Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly,

IKEv1 has been moved to Historic status. A number of old algorithms
that are associated with IKEv1, and not widely implemented for IKEv2
are deprecated as well. This document adds a Status column to the
IANA IKEv2 Transform Type registries that shows the deprecation
status.

"TCP Encapsulation of IKE and IPsec Packets", Tommy Pauly, Valery Smyslov,
2022-08-22, <draft-ietf-ipsecme-rfc8229bis-09.txt>

This document describes a method to transport Internet Key Exchange

Protocol (IKE) and IPsec packets over a TCP connection for traversing
network middleboxes that may block IKE negotiation over UDP. This
method, referred to as "TCP encapsulation", involves sending both IKE
packets for Security Association establishment and Encapsulating
Security Payload (ESP) packets over a TCP connection. This method is
intended to be used as a fallback option when IKE cannot be
negotiated over UDP.

TCP encapsulation for IKE and IPsec was defined in RFC 8229. This
document updates the specification for TCP encapsulation by including
additional clarifications obtained during implementation and
deployment of this method. This documents obsoletes RFC 8229.

"Definitions of Managed Objects for IP Traffic Flow Security", Don Fedyk,

Eric Kinzie, 2021-11-18, <draft-ietf-ipsecme-mib-iptfs-03.txt>

This document describes managed objects for the the management of IP

Traffic Flow Security additions to IKEv2 and IPsec. This document
provides a read only version of the objects defined in the YANG
module for the same purpose.

"Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for

Encrypted DNS", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery
Smyslov, 2022-08-30, <draft-ietf-ipsecme-add-ike-04.txt>

This document specifies new Internet Key Exchange Protocol Version 2

(IKEv2) Configuration Payload Attribute Types to assign DNS resolvers
that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH),
DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ).

"Announcing Supported Authentication Methods in IKEv2", Valery Smyslov,

 2022-07-11, <draft-ietf-ipsecme-ikev2-auth-announce-01.txt>

This specification defines a mechanism that allows the Internet Key

Exchange version 2 (IKEv2) implementations to indicate the list of
supported authentication methods to their peers while establishing
IKEv2 Security Association (SA). This mechanism improves
interoperability when IKEv2 partners are configured with multiple
different credentials to authenticate each other.

IP Wireless Access in Vehicular Environments (ipwave)

-----------------------------------------------------

"IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement

and Use Cases", Jaehoon Jeong, 2022-05-19,
<draft-ietf-ipwave-vehicular-networking-29.txt>

This document discusses the problem statement and use cases of

IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications are
vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
vehicle-to-everything (V2X) communications. First, this document
explains use cases using V2V, V2I, and V2X networking. Next, for
IPv6-based vehicular networks, it makes a gap analysis of current
IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
and Security & Privacy), and then enumerates gaps for the extensions
of those IPv6 protocols for IPv6-based vehicular networking.

JSON Mail Access Protocol (jmap)

--------------------------------

"JMAP for Quotas", Rene Cordier, 2022-08-09, <draft-ietf-jmap-quotas-05.txt>

This document specifies a data model for handling quotas on accounts

with a server using JMAP.

"JMAP for Sieve Scripts", Kenneth Murchison, 2022-07-28,

<draft-ietf-jmap-sieve-09.txt>

This document specifies a data model for managing Sieve scripts on a

server using the JSON Meta Application Protocol (JMAP).

"JMAP for Tasks", Joris Baum, Hans-Joerg Happel, 2022-05-09,

<draft-ietf-jmap-tasks-04.txt>

This document specifies a data model for synchronizing task data with
a server using JMAP.

"JMAP Blob management extension", Bron Gondwana, 2022-06-01,

<draft-ietf-jmap-blob-12.txt>

The JMAP base protocol (RFC8620) provides the ability to upload and
download arbitrary binary data via HTTP POST and GET on defined
endpoint. This binary data is called a "blob".

This extension adds additional ways to create and access blobs, by

making inline method calls within a standard JMAP request.

This extension also adds a reverse lookup mechanism to discover where

blobs are referenced within other data types.
 "JMAP extension for S/MIME signing and encryption", Alexey Melnikov,
2022-07-11, <draft-ietf-jmap-smime-sender-extensions-02.txt>

This document specifies an extension to JMAP for sending S/MIME

signed and S/MIME encrypted messages.

JSON Path (jsonpath)

--------------------

"JSONPath: Query expressions for JSON", Stefan Gossner, Glyn Normington,

Carsten Bormann, 2022-08-16, <draft-ietf-jsonpath-base-06.txt>

JSONPath defines a string syntax for selecting and extracting values

within a JSON (RFC 8259) value.

"I-Regexp: An Interoperable Regexp Format", Carsten Bormann, Tim Bray,

2022-07-11, <draft-ietf-jsonpath-iregexp-01.txt>

This document specifies I-Regexp, a flavor of regular expressions

that is limited in scope with the goal of interoperation across many
different regular-expression libraries.

Common Authentication Technology Next Generation (kitten)

---------------------------------------------------------

"SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Margaret
Cullen, Simon Josefsson, 2021-05-10, <draft-ietf-kitten-sasl-saml-ec-20.txt>

Security Assertion Markup Language (SAML) 2.0 is a generalized

framework for the exchange of security-related information between
asserting and relying parties. Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks that facilitate an
extensible authentication model, among other things. This document
specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages
the capabilities of a SAML-aware "enhanced client" to address
significant barriers to federated authentication in a manner that
encourages reuse of existing SAML bindings and profiles designed for
non-browser scenarios.

"SPAKE Pre-Authentication", Nathaniel McCallum, Simo Sorce, Robbie Harwood,

Greg Hudson, 2022-06-08, <draft-ietf-kitten-krb-spake-preauth-10.txt>

This document defines a new pre-authentication mechanism for the

Kerberos protocol. The mechanism uses a password-authenticated key
exchange to prevent brute-force password attacks, and may optionally
incorporate a second factor.

Lightweight Authenticated Key Exchange (lake)

---------------------------------------------

"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John

Mattsson, Francesca Palombini, 2022-07-10, <draft-ietf-lake-edhoc-15.txt>

This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a

very compact and lightweight authenticated Diffie-Hellman key
exchange with ephemeral keys. EDHOC provides mutual authentication,
forward secrecy, and identity protection. EDHOC is intended for
 usage in constrained scenarios and a main use case is to establish an
OSCORE security context. By reusing COSE for cryptography, CBOR for
encoding, and CoAP for transport, the additional code size can be
kept very low.

"Traces of EDHOC", Goeran Selander, John Mattsson, Marek Serafin, Marco

Tiloca, 2022-07-25, <draft-ietf-lake-traces-02.txt>

This document contains some example traces of Ephemeral Diffie-

Hellman Over COSE (EDHOC).

Limited Additional Mechanisms for PKIX and SMIME (lamps)

--------------------------------------------------------

"Certificate Management Protocol (CMP) Updates", Hendrik Brockhaus, David

von Oheimb, John Gray, 2022-06-29, <draft-ietf-lamps-cmp-updates-23.txt>

This document contains a set of updates to the syntax and transfer of

Certificate Management Protocol (CMP) version 2. This document
updates RFC 4210, RFC 5912, and RFC 6712.

The aspects of CMP updated in this document are using EnvelopedData

instead of EncryptedValue, clarifying the handling of p10cr messages,
improving the crypto agility, as well as adding new general message
types, extended key usages to identify certificates for use with CMP,
and well-known URI path segments.

CMP version 3 is introduced to enable signaling support of

EnvelopedData instead of EncryptedValue and signaling the use of an
explicit hash AlgorithmIdentifier in certConf messages, as far as
needed.

"Lightweight Certificate Management Protocol (CMP) Profile", Hendrik

Brockhaus, David von Oheimb, Steffen Fries, 2022-07-08,
<draft-ietf-lamps-lightweight-cmp-profile-13.txt>

This document aims at simple, interoperable, and automated PKI

management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices
as lightweight as possible, only the most crucial types of operations
and options are specified as mandatory. More special and complex use
cases are supported as well, by features specified as recommended or
optional.

"Header Protection for S/MIME", Daniel Gillmor, Bernie Hoeneisen, Alexey

Melnikov, 2022-03-07, <draft-ietf-lamps-header-protection-08.txt>

S/MIME version 3.1 introduced a mechanism to provide end-to-end

cryptographic protection of e-mail message headers. However, few
implementations generate messages using this mechanism, and several
legacy implementations have revealed rendering or security issues
when handling such a message.

This document updates the S/MIME specification to offer a different

mechanism that provides the same cryptographic protections but with
 fewer downsides when handled by legacy clients. Furthermore, it
offers more explicit guidance for clients when generating or handling
e-mail messages with cryptographic protection of message headers.

"Certificate Management Protocol (CMP) Algorithms", Hendrik Brockhaus, Hans

Aschauer, Mike Ounsworth, John Gray, 2022-06-02,
<draft-ietf-lamps-cmp-algorithms-15.txt>

This document describes the conventions for using several

cryptographic algorithms with the Certificate Management Protocol
(CMP). CMP is used to enroll and further manage the lifecycle of
X.509 certificates. This document also updates the algorithm use
profile from RFC 4210 Appendix D.2.

"Clarification of RFC7030 CSR Attributes definition", Michael Richardson,

Owen Friel, David von Oheimb, Dan Harkins, 2022-07-24,
<draft-richardson-lamps-rfc7030-csrattrs-04.txt>

The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in

its specification of the CSR Attributes Response. This has resulted
in implementation challenges and implementor confusion.

This document updates RFC7030 (EST) and clarifies how the CSR
Attributes Response can be used by an EST server to specify both CSR
attribute OIDs and also CSR attribute values that the server expects
the client to include in subsequent CSR request.

"General Purpose Extended Key Usage (EKU) for Document Signing X.509
Certificates", Tadahiko Ito, Tomofumi Okubo, Sean Turner, 2022-08-21,
<draft-ietf-lamps-documentsigning-eku-05.txt>

RFC5280 specifies several extended key purpose identifiers

(KeyPurposeIds) for X.509 certificates. This document defines a
general purpose document signing KeyPurposeId for inclusion in the
Extended Key Usage (EKU) extension of X.509 public key certificates.
Document Signing applications may require that the EKU extension be
present and that a document signing KeyPurposeId be indicated in
order for the certificate to be acceptable to that Document Signing
application.

"Internet X.509 Public Key Infrastructure: Logotypes in X.509

Certificates", Stefan Santesson, Russ Housley, Trevor Freeman, Leonard
Rosenthol, 2022-08-27, <draft-ietf-lamps-rfc3709bis-04.txt>

This document specifies a certificate extension for including

logotypes in public key certificates and attribute certificates.
This document obsoletes RFC 3709 and RFC 6170.

"Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm

Identifiers", Sean Turner, Simon Josefsson, Daniel McCarney, Tadahiko Ito,
2022-06-30, <draft-ietf-lamps-8410-ku-clarifications-02.txt>

This document updates RFC 8410 to clarify existing and specify

missing semantics for key usage bits when used in certificates that
support the Ed25519, Ed448, X25519, and X448 Elliptic Curve
Cryptography algorithms.

"Internet X.509 Public Key Infrastructure -- Certificate Management

Protocol (CMP)", Hendrik Brockhaus, David von Oheimb, Mike Ounsworth, John
 Gray, 2022-08-11, <draft-ietf-lamps-rfc4210bis-02.txt>

This document describes the Internet X.509 Public Key Infrastructure

(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP
provides interactions between client systems and PKI components such
as a Registration Authority (RA) and a Certification Authority (CA).

This document includes the updates on RFC 4210 specified by CMP

Updates [RFCAAAA] Section 2 and Appendix A.2 maintaining backward
compatibility with CMP version 2 wherever possible and obsoleted both
documents. Updates to CMP version 2 are: improving crypto agility,
extending the polling mechanism, adding new general message types,
and adding extended key usages to identify special CMP server
authorizations. Introducing version 3 to be used only for changes to
the ASN.1 syntax, which are: support of EnvelopedData instead of
EncryptedValue and hashAlg for indicating a hash AlgorithmIdentifier
in certConf messages.

"Internet X.509 Public Key Infrastructure -- HTTP Transfer for the

Certificate Management Protocol (CMP)", Hendrik Brockhaus, David von
Oheimb, Mike Ounsworth, John Gray, 2022-08-11,
<draft-ietf-lamps-rfc6712bis-02.txt>

This document describes how to layer the Certificate Management

Protocol (CMP) over HTTP.

It includes the updates on RFC 6712 specified in CMP Updates

[RFCAAAA] Section 3 and obsoleted both documents. These updates
introduce CMP URIs using a Well-known prefix.

"Clarification of RFC7030 CSR Attributes definition", Michael Richardson,

Owen Friel, David von Oheimb, Dan Harkins, 2022-08-15,
<draft-ietf-lamps-rfc7030-csrattrs-00.txt>

The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in

its specification of the CSR Attributes Response. This has resulted
in implementation challenges and implementor confusion.

This document updates RFC7030 (EST) and clarifies how the CSR
Attributes Response can be used by an EST server to specify both CSR
attribute OIDs and also CSR attribute values, in particular X.509
extension values, that the server expects the client to include in
subsequent CSR request.

"X.509 Certificate Extension for 5G Network Function Types", Russ Housley,

Sean Turner, John Mattsson, Daniel Migault, 2022-09-01,
<draft-ietf-lamps-5g-nftypes-00.txt>

This document specifies the certificate extension for including

Network Function Types (NFTypes) for the 5G System in X.509v3 public
key certificates as profiled in RFC 5280.

Locator/ID Separation Protocol (lisp)

-------------------------------------

"LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert

Cabellos-Aparicio, Damien Saucez, 2022-07-07, <draft-ietf-lisp-sec-29.txt>
 This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup
process. LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages.

"An Architectural Introduction to the Locator/ID Separation Protocol

(LISP)", Albert Cabellos-Aparicio, Damien Saucez, 2021-09-20,
<draft-ietf-lisp-introduction-15.txt>

This document describes the architecture of the Locator/ID Separation

Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory
purposes, more details can be found in [I-D.ietf-lisp-rfc6830bis] and
[I-D.ietf-lisp-rfc6833bis], the protocol specifications.

"LISP YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras,

Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino,
2022-08-29, <draft-ietf-lisp-yang-18.txt>

This document describes a YANG data model to use with the Locator/ID
Separation Protocol (LISP).

The YANG modules in this document conform to the Network Management

Datastore Architecture (NMDA).

"The Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller,

David Meyer, Darrel Lewis, Albert Cabellos-Aparicio, 2022-05-07,
<draft-ietf-lisp-rfc6830bis-38.txt>

This document describes the Data-Plane protocol for the Locator/ID

Separation Protocol (LISP). LISP defines two namespaces, End-point
Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local Map-Cache.

LISP requires no change to either host protocol stacks or to underlay

routers and offers Traffic Engineering, multihoming and mobility,
among other features.

This document obsoletes RFC 6830.

"Locator/ID Separation Protocol (LISP) Control-Plane", Dino Farinacci,

Fabio Maino, Vince Fuller, Albert Cabellos-Aparicio, 2022-05-02,
<draft-ietf-lisp-rfc6833bis-31.txt>

This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two types of
LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --
that provides a simplified "front end" for one or more Endpoint ID to
Routing Locator mapping databases.

By using this Control-Plane service interface and communicating with

Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs) are not dependent on the details of
mapping database systems, which facilitates modularity with different
 database designs. Since these devices implement the "edge" of the
LISP Control-Plane infrastructure, connecting EID addressable nodes
of a LISP site, it the implementation and operational complexity of
the overall cost and effort of deploying LISP.

This document obsoletes RFC 6830 and RFC 6833.

"LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal,

Parantap Lahiri, 2022-03-20, <draft-ietf-lisp-te-10.txt>

This document describes how LISP reencapsulating tunnels can be used

for Traffic Engineering purposes. The mechanisms described in this
document require no LISP protocol changes but do introduce a new
locator (RLOC) encoding. The Traffic Engineering features provided
by these LISP mechanisms can span intra-domain, inter-domain, or
combination of both.

"LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White,
2022-07-24, <draft-ietf-lisp-mn-12.txt>

This document describes how a lightweight version of LISP's ITR/ETR

functionality can be used to provide seamless mobility to a mobile
node. The LISP Mobile Node design described in this document uses
standard LISP functionality to provide scalable mobility for LISP
mobile nodes.

"LISP Virtual Private Networks (VPNs)", Victor Moreno, Dino Farinacci,

2022-07-10, <draft-ietf-lisp-vpn-09.txt>

This document describes the use of the Locator/ID Separation Protocol

(LISP) to create Virtual Private Networks (VPNs). LISP is used to
provide segmentation in both the LISP data plane and control plane.
These VPNs can be created over the top of the Internet or over
private transport networks, and can be implemented by Enterprises or
Service Providers. The goal of these VPNs is to leverage the
characteristics of LISP - routing scalability, simply expressed
Ingress site TE Policy, IP Address Family traversal, and mobility, in
ways that provide value to network operators.

"LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc

Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino
Farinacci, 2022-07-10, <draft-ietf-lisp-eid-mobility-10.txt>

The LISP control plane offers the flexibility to support multiple

overlay flavors simultaneously. This document specifies how LISP can
be used to provide control-plane support to deploy a unified L2 and
L3 overlay solution for End-point Identifier (EID) mobility, as well
as analyzing possible deployment options and models.

"LISP Predictive RLOCs", Dino Farinacci, Padma Pillay-Esnault, 2022-04-11,

<draft-ietf-lisp-predictive-rlocs-10.txt>

This specification describes a method to achieve near-zero packet

loss when an EID is roaming quickly across RLOCs.

"LISP EID Anonymity", Dino Farinacci, Padma Pillay-Esnault, Wassim Haddad,

2022-03-20, <draft-ietf-lisp-eid-anonymity-12.txt>

This specification will describe how ephemeral LISP EIDs can be used
 to create source anonymity. The idea makes use of frequently
changing EIDs much like how a credit-card system uses a different
credit-card numbers for each transaction.

"Vendor Specific LISP Canonical Address Format (LCAF)", Alberto

Rodriguez-Natal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino
Farinacci, 2022-07-06, <draft-ietf-lisp-vendor-lcaf-12.txt>

This document describes a new Locator/ID Separation Protocol (LISP)

Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF
enables organizations to have implementation-specific encodings for
LCAF addresses. This document updates RFC8060.

"LISP Generic Protocol Extension", Fabio Maino, Jennifer Lemon, Puneet

Agarwal, Darrel Lewis, Michael Smith, 2020-07-26,
<draft-ietf-lisp-gpe-19.txt>

This document describes extensions to the Locator/ID Separation

Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation and allow to introduce new
protocol capabilities.

"Publish/Subscribe Functionality for LISP", Alberto Rodriguez-Natal, Vina

Ermagan, Albert Cabellos-Aparicio, Sharon Barkai, Mohamed Boucadair,
2021-06-28, <draft-ietf-lisp-pubsub-09.txt>

This document specifies an extension to the Request/Reply based LISP

Control Plane to enable Publish/Subscribe (PubSub) operation.

"Locator/ID Separation Protocol (LISP) Map-Versioning", Luigi Iannone,

Damien Saucez, Olivier Bonaventure, 2022-06-21,
<draft-ietf-lisp-6834bis-14.txt>

This document describes the LISP (Locator/ID Separation Protocol)

Map-Versioning mechanism, which provides in-packet information about
Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
encapsulate LISP data packets. This approach is based on associating
a version number to EID-to-RLOC mappings and the transport of such a
version number in the LISP-specific header of LISP-encapsulated
packets. LISP Map-Versioning is particularly useful to inform
communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers
(ETRs) about modifications of the mappings used to encapsulate
packets. The mechanism is optional and transparent to
implementations not supporting this feature, since in the LISP-
specific header and in the Map Records, bits used for Map-Versioning
can be safely ignored by ITRs and ETRs that do not support or do not
want to use the mechanism.

This document obsoletes RFC 6834 "Locator/ID Separation Protocol

(LISP) Map-Versioning", which is the initial experimental
specifications of the mechanisms updated by this document.

"LISP Control-Plane ECDSA Authentication and Authorization", Dino

Farinacci, Erik Nordmark, 2022-08-15, <draft-ietf-lisp-ecdsa-auth-08.txt>

This draft describes how LISP control-plane messages can be

individually authenticated and authorized without a a priori shared-
key configuration. Public-key cryptography is used with no new PKI
infrastructure required.
 "Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA
Registry for Packet Type Allocations", Mohamed Boucadair, Christian
Jacquenet, 2019-01-24, <draft-ietf-lisp-rfc8113bis-03.txt>

This document specifies a Locator/ID Separation Protocol (LISP)

shared message type for defining future extensions and conducting
experiments without consuming a LISP packet type codepoint for each
extension.

This document obsoletes RFC 8113.

"Network-Hexagons:Geolocation Mobility Edge Network Based On H3 and LISP",

sbarkai@gmail.com, Bruno Fernandez-Ruiz, Rotem Tamir, Alberto
Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio, Dino Farinacci,
2022-08-15, <draft-ietf-lisp-nexagon-39.txt>

This informational document combines virtual layer3 routing and

geospatial hierarchical grid forming a Geolocation mobility edge
network. When vehicles with AI cameras detect objects of interest
on the road, they use their GPS to calculate their high-resolution
grid-tile position. They then use this tile to calculate the
high-resolution tile of the detection. A low-resolution tile which
contains the detection tile identifies a network-addressable shard.
The shard tile ID is used as basis for IPv6 endpoint identifier (EID).
Geospatial EIDs are the queue destination and channel source of shard
Geolocation processes, consolidating detections form all vehicles in
that area. Geolocation processes based on EID queues and channels are
therefore portable via the Locator/ID Separation Protocol (LISP).

"LISP Map Server Reliable Transport", Darrel Lewis, Balaji

Venkatachalapathy, Marc Portoles-Comeras, Isidor Kouvelas, Chris Cassar,
2022-07-10, <draft-ietf-lisp-map-server-reliable-transport-00.txt>

The communication between LISP ETRs and Map-Servers is based on

unreliable UDP message exchange coupled with periodic message
transmission in order to maintain soft state. The drawback of
periodic messaging is the constant load imposed on both the ETR and
the Map-Server. New use cases for LISP have increased the amount of
state that needs to be communicated with requirements that are not
satisfied by the current mechanism. This document introduces the use
of a reliable transport for ETR to Map-Server communication in order
to eliminate the periodic messaging overhead, while providing
reliability, flow-control and endpoint liveness detection.

IPv6 over Low Power Wide-Area Networks (lpwan)

----------------------------------------------

"Data Model for Static Context Header Compression (SCHC)", Ana Minaburo,
Laurent Toutain, 2022-08-26, <draft-ietf-lpwan-schc-yang-data-model-17.txt>

This document describes a YANG data model for the SCHC (Static
Context Header Compression) compression and fragmentation rules.

This document formalizes the description of the rules for better

interoperability between SCHC instances either to exchange a set of
rules or to modify some rules parameters.

"SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Sergio Aguilar,
 Laurent Toutain, Sandra Cespedes, Diego Torre, Julien Boite, 2022-08-01,
<draft-ietf-lpwan-schc-over-sigfox-12.txt>

The Generic Framework for Static Context Header Compression and

Fragmentation (SCHC) specification describes two mechanisms: i) an
application header compression scheme, and ii) a frame fragmentation
and loss recovery functionality. SCHC offers a great level of
flexibility that can be tailored for different Low Power Wide Area
Network (LPWAN) technologies.

The present document provides the optimal parameters and modes of

operation when SCHC is implemented over a Sigfox LPWAN. This set of
parameters are also known as a "SCHC over Sigfox profile."

"SCHC over NBIoT", Edgar Ramos, Ana Minaburo, 2022-07-11,

<draft-ietf-lpwan-schc-over-nbiot-10.txt>

The Static Context Header Compression and Fragmentation (SCHC)

specification describes header compression and fragmentation
functionalities for LPWAN (Low Power Wide Area Networks)
technologies. The Narrowband Internet of Things (NB-IoT)
architecture may adapt SCHC to improve its capacities.

This document describes the use of SCHC over the NB-IoT wireless
access and provides recommendations for the use cases and efficient
parameterization.

"LPWAN Static Context Header Compression (SCHC) Architecture", Alexander

Pelov, Pascal Thubert, Ana Minaburo, 2022-06-30,
<draft-ietf-lpwan-architecture-02.txt>

This document defines the LPWAN SCHC architecture.

"SCHC Compound ACK", Juan Zuniga, Carles Gomez, Sergio Aguilar, Laurent
Toutain, Sandra Cespedes, Diego Torre, 2022-08-01,
<draft-ietf-lpwan-schc-compound-ack-06.txt>

The present document describes an extension to the SCHC (Static

Context Header Compression and fragmentation) protocol RFC8724. It
defines a SCHC Compound ACK message format and procedure, which are
intended to reduce the number of response transmissions (i.e., SCHC
ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several
windows in a single SCHC message (i.e., the SCHC Compound ACK).

Both message format and procedure are generic, so they can be used,
for instance, by any of the four LWPAN technologies defined in
RFC8376, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w.

Link State Routing (lsr)

------------------------

"YANG Data Model for IS-IS Protocol", Stephane Litkowski, Derek Yeung, Acee
Lindem, Zhaohui Zhang, Ladislav Lhotka, 2019-10-15,
<draft-ietf-isis-yang-isis-cfg-42.txt>

This document defines a YANG data model that can be used to configure
and manage the IS-IS protocol on network elements.

"YANG Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Zhaohui
Zhang, Ing-Wher Chen, Acee Lindem, 2019-10-17, <draft-ietf-ospf-yang-29.txt>

This document defines a YANG data model that can be used to configure
and manage OSPF. The model is based on YANG 1.1 as defined in RFC
7950 and conforms to the Network Management Datastore Architecture
(NMDA) as described in RFC 8342.

"YANG Data Model for OSPF Segment Routing", Derek Yeung, Yingzhen Qu,
Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2022-07-03,
<draft-ietf-ospf-sr-yang-18.txt>

This document defines a YANG data module that can be used to

configure and manage OSPF Extensions for Segment Routing. It also
defines a module for management of Signaling Maximum SID Depth (MSD)
Using OSPF.

"YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen
Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2022-08-18,
<draft-ietf-isis-sr-yang-14.txt>

This document defines a YANG data module that can be used to

configure and manage IS-IS Segment Routing for MPLS data plane.

"IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils,

Ketan Talaulikar, Arkadiy Gulko, 2022-05-18,
<draft-ietf-lsr-flex-algo-20.txt>

IGP protocols traditionally compute best paths over the network based
on the IGP metric assigned to the links. Many network deployments
use RSVP-TE based or Segment Routing based Traffic Engineering to
steer traffic over a path that is computed using different metrics or
constraints than the shortest IGP path. This document proposes a
solution that allows IGPs themselves to compute constraint-based
paths over the network. This document also specifies a way of using
Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
along the constraint-based paths.

"IGP extension for PCEP security capability support in the PCE discovery",
Diego Lopez, Qin WU, Dhruv Dhody, Qiufang Ma, Daniel King, 2021-08-21,
<draft-ietf-lsr-pce-discovery-security-support-09.txt>

When a Path Computation Element (PCE) is a Label Switching Router

(LSR) participating in the Interior Gateway Protocol (IGP), or even a
server participating in IGP, its presence and path computation
capabilities can be advertised using IGP flooding. The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for
OSPF and IS-IS respectively. However these specifications lack a
method to advertise PCEP security (e.g., Transport Layer Security
(TLS), TCP Authentication Option (TCP-AO)) support capability.

This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV

that can be announced as an attribute in the IGP advertisement to
distribute PCEP security support information. In addition, this
document updates RFC 5088 and RFC 5089 to allow advertisement of Key
ID or Key Chain Name Sub-TLV to support TCP-AO security capability.
RFC 8231, RFC 8306, and RFC 8623 are also updated to reflect the
movement of the IANA "PCE Capability Flags" registry.
"Dynamic Flooding on Dense Graphs", Tony Li, Tony Przygienda, Peter Psenak,
Les Ginsberg, Huaimo Chen, David Cooper, Luay Jalil, Srinath Dontula, Gyan
Mishra, 2022-06-07, <draft-ietf-lsr-dynamic-flooding-11.txt>

Routing with link state protocols in dense network topologies can

result in sub-optimal convergence times due to the overhead
associated with flooding. This can be addressed by decreasing the
flooding topology so that it is less dense.

This document discusses the problem in some depth and an

architectural solution. Specific protocol changes for IS-IS, OSPFv2,
and OSPFv3 are described in this document.

"IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Peter

Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu,
2021-10-20, <draft-ietf-lsr-isis-srv6-extensions-18.txt>

The Segment Routing (SR) architecture allows flexible definition of

the end-to-end path by encoding it as a sequence of topological
elements called "segments". It can be implemented over the MPLS or
the IPv6 data plane. This document describes the IS-IS extensions
required to support Segment Routing over the IPv6 data plane.

This document updates RFC 7370 by modifying an existing registry.

"OSPF YANG Model Augmentations for Additional Features - Version 1", Acee
Lindem, Yingzhen Qu, 2022-07-09,
<draft-ietf-lsr-ospf-yang-augmentation-v1-08.txt>

This document defines YANG data modules augmenting the IETF OSPF YANG
model to provide support for Traffic Engineering Extensions to OSPF
Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in
RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF
Link-Local Signaling (LLS) Extensions for Local Interface ID
Advertisement as defined in RFC 8510, OSPF Application-Specific Link
Attributes as defined in RFC 8920, and OSPF Flexible Algorithm.

"YANG Model for OSPFv3 Extended LSAs", Acee Lindem, Sharmila Palani,
Yingzhen Qu, 2022-08-30, <draft-ietf-lsr-ospfv3-extended-lsa-yang-12.txt>

This document defines a YANG data model augmenting the IETF OSPF YANG
model to provide support for OSPFv3 Link State Advertisement (LSA)
Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide
extensible TLV-based LSAs for the base LSA types defined in RFC 5340.

"IS-IS Extended Hierarchy", Tony Li, Les Ginsberg, Paul Wells, 2022-06-28,
<draft-ietf-lsr-isis-extended-hierarchy-06.txt>

The IS-IS routing protocol was originally defined with a two level
hierarchical structure. This was adequate for the networks at the
time. As we continue to expand the scale of our networks, it is
apparent that additional hierarchy would be a welcome degree of
flexibility in network design.

This document defines IS-IS Levels 3 through 8.

"OSPF BFD Strict-Mode", Ketan Talaulikar, Peter Psenak, Albert Fu, Rejesh
Shetty, 2022-09-03, <draft-ietf-lsr-ospf-bfd-strict-mode-07.txt>
 This document specifies the extensions to OSPF that enable an OSPF
router to signal the requirement for a Bidirectional Forwarding
Detection (BFD) session prior to adjacency formation. Link-Local
Signaling (LLS) is used to advertise the requirement for strict-mode
BFD session establishment for an OSPF adjacency. If both OSPF
neighbors advertise BFD strict-mode, adjacency formation will be
blocked until a BFD session has been successfully established.

This document updates RFC2328 by augmenting the OSPF neighbor state

machine with a check for BFD session up before progression from Init
to Two-Way state when operating in OSPF BFD strict-mode.

"OSPF Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston,

2022-09-03, <draft-ietf-lsr-ospf-reverse-metric-07.txt>

This document specifies the extensions to OSPF that enable a router

to use link-local signaling to signal the metric that receiving
neighbor(s) should use for a link to the signaling router. The
signaling of this reverse metric, to be used on the link to the
signaling router, allows a router to influence the amount of traffic
flowing towards itself and in certain use cases enables routers to
maintain symmetric metrics on both sides of a link between them.

"YANG Module for IS-IS Reverse Metric", Christian Hopps, 2022-01-01,

<draft-ietf-lsr-yang-isis-reverse-metric-06.txt>

This document defines a YANG module for managing the reverse metric
extension to the Intermediate System to Intermediate System intra-
domain routeing information exchange protocol (IS-IS).

"OSPFv3 Extensions for SRv6", Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter
Psenak, 2022-08-23, <draft-ietf-lsr-ospfv3-srv6-extensions-07.txt>

The Segment Routing (SR) architecture allows a flexible definition of

the end-to-end path by encoding it as a sequence of topological
elements called "segments". It can be implemented over an MPLS or
IPv6 data plane. This document describes the OSPFv3 extensions
required to support Segment Routing over the IPv6 data plane (SRv6).

"Flooding Topology Minimum Degree Algorithm", Huaimo Chen, Mehmet Toy, Yi

Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2022-07-05,
<draft-ietf-lsr-flooding-topo-min-degree-05.txt>

This document proposes an algorithm for a node to compute a flooding

topology, which is a subgraph of the complete topology per underline
physical network. When every node in an area automatically
calculates a flooding topology by using a same algorithm and floods
the link states using the flooding topology, the amount of flooding
traffic in the network is greatly reduced. This would reduce
convergence time with a more stable and optimized routing
environment.

"Area Proxy for IS-IS", Tony Li, Sarah Chen, Vivek Ilangovan, Gyan Mishra,
2022-05-16, <draft-ietf-lsr-isis-area-proxy-08.txt>

Link state routing protocols have hierarchical abstraction already

built into them. However, when lower levels are used for transit,
they must expose their internal topologies to each other, leading to
scale issues.
 To avoid this, this document discusses extensions to the IS-IS
routing protocol that would allow level 1 areas to provide transit,
yet only inject an abstraction of the level 1 topology into level 2.
Each level 1 area is represented as a single level 2 node, thereby
enabling greater scale.

"IS-IS Flood Reflection", Tony Przygienda, Chris Bowers, Yiu Lee, Alankar
Sharma, Russ White, 2021-12-09,
<draft-ietf-lsr-isis-flood-reflection-07.txt>

This document describes a backwards compatible, optional IS-IS

extension that allows the creation of IS-IS flood reflection
topologies. Flood reflection allows topologies in which L1 areas
provide transit forwarding for L2 using all available L1 nodes
internally. It accomplishes this by creating L2 flood reflection
adjacencies within each L1 area. Those adjacencies are used to flood
L2 LSPDUs, and they are used in the L2 SPF computation. However,
they are not used for forwarding within the flood reflection cluster.
This arrangement gives the L2 topology significantly better scaling
properties. As additional benefit, only those routers directly
participating in flood reflection have to support the feature. This
allows for the incremental deployment of scalable L1 transit areas in
an existing network, without the necessity of upgrading other routers
in the network.

"IS-IS Topology-Transparent Zone", Huaimo Chen, Richard Li, Yi Yang, Yanhe

Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani, 2022-03-31,
<draft-ietf-lsr-isis-ttz-05.txt>

This document specifies a topology-transparent zone in an IS-IS area.

A zone is a subset (block/piece) of an area, which comprises a group
of routers and a number of circuits connecting them. It is
abstracted as a virtual entity such as a single virtual node or zone
edges mesh. Any router outside of the zone is not aware of the zone.
The information about the circuits and routers inside the zone is not
distributed to any router outside of the zone.

"Advertising Layer 2 Bundle Member Link Attributes in OSPF", Ketan

Talaulikar, Peter Psenak, 2022-09-02, <draft-ietf-lsr-ospf-l2bundles-05.txt>

There are deployments where the Layer 3 (L3) interface on which OSPF
operates is a Layer 2 (L2) interface bundle. Existing OSPF
advertisements only support advertising link attributes of the Layer
3 interface. If entities external to OSPF wish to control traffic
flows on the individual physical links which comprise the Layer 2
interface bundle, link attribute information for the bundle members
is required.

This document defines the protocol extensions for OSPF to advertise

the link attributes of L2 bundle members.

"IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS

Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong
Duan, 2022-09-01, <draft-ietf-lsr-isis-rfc5316bis-04.txt>

This document describes extensions to the Intermediate System to

Intermediate System (IS-IS) protocol to support Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
 (TE) for multiple Autonomous Systems (ASs). It defines IS-IS
extensions for the flooding of TE information about inter-AS links,
which can be used to perform inter-AS TE path computation.

No support for flooding information from within one AS to another AS

is proposed or defined in this document.

This document builds on RFC 5316 by adding support for IPv6-only

operation.

This document obsoletes RFC 5316.

"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", William Britto,

Shraddha Hegde, Parag Kaneriya, Rejesh Shetty, Ron Bonica, Peter Psenak,
2022-05-16, <draft-ietf-lsr-ip-flexalgo-06.txt>

An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute

constraint-based paths. The base IGP Flex-Algorithm specification
describes how it is used with Segment Routing (SR) data planes - SR
MPLS and SRv6.

This document extends IGP Flex-Algorithm, so that it can be used with

regular IPv4 and IPv6 forwarding.

"Extensions to OSPF for Advertising Prefix Administrative Tags", Acee

Lindem, Peter Psenak, 2022-08-29, <draft-ietf-lsr-ospf-admin-tags-04.txt>

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be

able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3
were relegated to a single tag for AS External and Not-So-Stubby-Area
(NSSA) prefixes. With the flexible encodings provided by OSPFv2
Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs,
multiple administrative tags may advertised for all types of
prefixes. These administrative tags can be used for many
applications including route redistribution policy, selective prefix
prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection,
and many others.

The ISIS protocol supports a similar mechanism that is described in

RFC 5130.

"IS-IS YANG Model Augmentations for Additional Features - Version 1", Acee
Lindem, Stephane Litkowski, Yingzhen Qu, 2022-03-06,
<draft-ietf-lsr-isis-yang-augmentation-v1-03.txt>

This document defines YANG data modules augmenting the IETF IS-IS
YANG model to provide support for IS-IS Minimum Remaining Lifetime as
defined in RFC 7987, IS-IS Application-Specific Link Attributes as
defined in RFC 8919, and IS-IS Flexible Algorithm.

"Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual

Transport Network", Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li,
2022-07-10, <draft-ietf-lsr-isis-sr-vtn-mt-03.txt>

Enhanced VPN (VPN+) aims to provide enhanced VPN service to support

some application's needs of enhanced isolation and stringent
performance requirements. VPN+ requires integration between the
overlay VPN connectivity and the characteristics provided by the
underlay network. A Virtual Transport Network (VTN) is a virtual
 underlay network which consists of a subset of network resources
allocated on network nodes and links in a customized topology of the
physical network. A VTN could be used as the underlay to support one
or a group of VPN+ services.

In some network scenarios, each VTN can be associated with a unique

logical network topology. This document describes a mechanism to
build the SR based VTNs using IS-IS Multi-Topology together with
other well-defined IS-IS extensions.

"OSPF-GT (Generalized Transport)", Acee Lindem, Yingzhen Qu, Abhay Roy,

Sina Mirtorabi, 2022-07-09, <draft-ietf-lsr-ospf-transport-instance-03.txt>

OSPFv2 and OSPFv3 include a reliable flooding mechanism to

disseminate routing topology and Traffic Engineering (TE) information
within a routing domain. Given the effectiveness of these
mechanisms, it is advantageous to use the same mechanism for
dissemination of other types of information within the domain.
However, burdening OSPF with this additional information will impact
intra-domain routing convergence and possibly jeopardize the
stability of the OSPF routing domain. This document presents
mechanisms to advertise this non-routing information in separate OSPF
Generalized Transport (OSPF-GT) instances.

OSPF-GT is not constrained to the semantics as traditional OSPF.

OSPF-GT neighbors are not required to be directly attached since they
are never used to compute hop-by-hop routing. Consequently,
independent sparse topologies can be defined to dissemenate non-
routing information only to those OSPF-GT routers requiring it.

"Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints", Shraddha

Hegde, William Britto, Rejesh Shetty, Bruno Decraene, Peter Psenak, Tony
Li, 2022-07-08, <draft-ietf-lsr-flex-algo-bw-con-03.txt>

Many networks configure the link metric relative to the link

capacity. High bandwidth traffic gets routed as per the link
capacity. Flexible algorithms provides mechanisms to create
constraint based paths in IGP. This draft documents a generic metric
type and set of bandwidth related constraints to be used in Flexible
Algorithms.

"Algorithm Related IGP-Adjacency SID Advertisement", Shaofu Peng, Ran Chen,

Ketan Talaulikar, Peter Psenak, 2022-07-25,
<draft-ietf-lsr-algorithm-related-adjacency-sid-03.txt>

Segment Routing architecture supports the use of multiple routing

algorithms, i.e., different constraint-based shortest-path
calculations can be supported. There are two standard algorithms:
SPF and Strict-SPF, defined in Segment Routing architecture. There
are also other user defined algorithms according to Flex-algo
applicaiton. However, an algorithm identifier is often included as
part of a Prefix-SID advertisement, that maybe not satisfy some
scenarios where multiple algorithm share the same link resource.
This document complement that the algorithm identifier can be also
included as part of a Adjacency-SID advertisement

"YANG Data Model for OSPF SRv6", Zhibo Hu, Xuesong Geng, Syed Raza,
Yingzhen Qu, Acee Lindem, 2022-03-26, <draft-ietf-lsr-ospf-srv6-yang-01.txt>
 This document defines a YANG data model that can be used to configure
and manage OSPFv3 SRv6 as defined in I-D.ietf-lsr-
ospfv3-srv6-extensions.

"YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong
Geng, Qiufang Ma, 2022-03-26, <draft-ietf-lsr-isis-srv6-yang-01.txt>

This document defines a YANG data model that can be used to configure
and manage IS-IS SRv6 [I-D.ietf-lsr-isis-srv6-extensions].

"IS-IS Fast Flooding", Bruno Decraene, Les Ginsberg, Tony Li, Guillaume
Solignac, Marek Karasek, Chris Bowers, Gunter Van de Velde, Peter Psenak,
Tony Przygienda, 2022-07-11, <draft-ietf-lsr-isis-fast-flooding-01.txt>

Current Link State Protocol Data Unit (PDU) flooding rates are much
slower than what modern networks can support. The use of IS-IS at
larger scale requires faster flooding rates to achieve desired
convergence goals. This document discusses the need for faster
flooding, the issues around faster flooding, and some example
approaches to achieve faster flooding. It also defines protocol
extensions relevant to faster flooding.

"Update to OSPF Terminology", Mike Fox, Acee Lindem, Alvaro Retana,

2022-07-09, <draft-ietf-lsr-ospf-terminology-03.txt>

This document updates some OSPF terminology to be in line with

inclusive language used in the industry. The IETF has designated
National Institute of Standards and Technology (NIST) "Guidance for
NIST Staff on Using Inclusive Language in Documentary Standards" for
its inclusive language guidelines.

This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243,

RFC5614, and RFC5838.

Link State Vector Routing (lsvr)

--------------------------------

"Layer-3 Discovery and Liveness", Randy Bush, Rob Austein, Keyur Patel,
2022-05-02, <draft-ietf-lsvr-l3dl-09.txt>

In Massive Data Centers, BGP-SPF and similar routing protocols are

used to build topology and reachability databases. These protocols
need to discover IP Layer-3 attributes of links, such as neighbor IP
addressing, logical link IP encapsulation abilities, and link
liveness. This Layer-3 Discovery and Liveness protocol collects
these data, which may then be disseminated using BGP-SPF and similar
protocols.

"Layer-3 Discovery and Liveness Signing", Randy Bush, Russ Housley, Rob
Austein, 2022-05-02, <draft-ietf-lsvr-l3dl-signing-04.txt>

The Layer-3 Discovery and Liveness protocol OPEN PDU may contain a
public key and a certificate, which can be used to verify signatures
on subsequent PDUs. This document describes two mechanisms based on
digital signatures, one that is Trust On First Use (TOFU), and one
that uses a trust anchor signture over the public key to provide
authentication as well as session integrity.

"L3DL Upper-Layer Protocol Configuration", Randy Bush, Keyur Patel,

 2022-05-02, <draft-ietf-lsvr-l3dl-ulpc-03.txt>

This document uses the Layer-3 Liveness and Discovery protocol to

communicate the parameters needed to exchange inter-device Upper
Layer Protocol Configuration for upper-layer protocols such as the
BGP family.

Light-Weight Implementation Guidance (lwig)

-------------------------------------------

"Alternative Elliptic Curve Representations", Rene Struik, 2022-01-21,

<draft-ietf-lwig-curve-representations-23.txt,.pdf>

This document specifies how to represent Montgomery curves and

(twisted) Edwards curves as curves in short-Weierstrass form and
illustrates how this can be used to carry out elliptic curve
computations leveraging existing implementations and specifications
of, e.g., ECDSA and ECDH using NIST prime curves. We also provide
extensive background material that may be useful for implementers of
elliptic curve cryptography.

"Minimal IP Encapsulating Security Payload (ESP)", Daniel Migault, Tobias

Guggemos, 2022-05-24, <draft-ietf-lwig-minimal-esp-11.txt>

This document describes the minimal properties that an IP

Encapsulating Security Payload (ESP) implementation needs to meet to
remain interoperable with the standard RFC4303 ESP. Such a minimal
version of ESP is not intended to become a replacement of the RFC
4303 ESP. Instead, a minimal implementation is expected to be
optimized for constrained environments while remaining interoperable
with implementations of RFC 4303 ESP. In addition, this document
also provides some considerations for implementing minimal ESP in a
constrained environment which includes limiting the number of flash
writes, handling frequent wakeup / sleep states, limiting wakeup
time, and reducing the use of random generation.

This document does not update or modify RFC 4303. It provides a

compact description of how to implement the minimal version of that
protocol. RFC 4303 remains the authoritative description.

"Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue,

Ari Keranen, Carles Gomez, 2022-06-29, <draft-ietf-lwig-7228bis-00.txt>

The Internet Protocol Suite is increasingly used on small devices

with severe constraints on power, memory, and processing resources,
creating constrained-node networks. This document provides a number
of basic terms that have been useful in the standardization work for
constrained-node networks.

MAC Address Device Identification for Network and Application Services (madinas)
--------------------------------------------------------------------------------

"Randomized and Changing MAC Address Use Cases", Jerome Henry, Yiu Lee,
2022-07-09, <draft-ietf-madinas-use-cases-02.txt>

To limit the association between a device, its traffic, its location

and its user, client vendors have started implementing MAC address
rotation. When such rotation happens, some in-network states may
break, which may affect network efficiency and the user experience.
 At the same time, devices may continue sending other stable
identifiers, defeating the MAC rotation purposes. This document
lists various network environments and a set of network services that
may be affected by such rotation. This document then examines
settings and use cases where the user experience may be affected by
in-network state disruption, and settings where other machine
identifiers may expose the user privacy. Last, this document
examines solutions to maintain user privacy while preserving user
quality of experience and network operation efficiency.

"MAC address randomization", Juan Zuniga, Carlos Bernardos, Amelia

Andersdotter, 2022-07-08,
<draft-ietf-madinas-mac-address-randomization-02.txt>

Internet privacy has become a major concern over the past few years.
Users are becoming more aware that their online activity leaves a
vast digital footprint, that communications are not always properly
secured, and that their location and actions can be easily tracked.
One of the main factors for the location tracking issue is the wide
use of long-lasting identifiers, such as MAC addresses.

There have been several initiatives at the IETF and the IEEE 802
standards committees to overcome some of these privacy issues. This
document provides an overview of these activities, with the intention
to inform the technical community about them, and help coordinate
between present and future standardization activities.

Mobile Ad-hoc Networks (manet)

------------------------------

"DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng,
David Wiggins, Lou Berger, Stan Ratliff, 2022-07-29,
<draft-ietf-manet-dlep-credit-flow-control-11.txt>

This document defines new Dynamic Link Exchange Protocol (DLEP) Data
Items that are used to support credit-based flow control. Credit
window control is used to regulate when data may be sent to an
associated virtual or physical queue. The Data Items are defined in
an extensible and reusable fashion. Their use will be mandated in
other documents defining specific DLEP extensions.

"DLEP Traffic Classification Data Item", Bow-Nan Cheng, David Wiggins, Lou
Berger, 2022-07-29, <draft-ietf-manet-dlep-traffic-classification-08.txt>

This document defines a new Dynamic Link Exchange Protocol (DLEP)

Data Item that is used to support traffic classification. Traffic
classification information is used to identify traffic flows based on
frame/packet content such as destination address. The Data Item is
defined in an extensible and reusable fashion. Its use will be
mandated in other documents defining specific DLEP extensions. This
document also introduces DLEP Sub-Data Items, and Sub-Data Items are
defined to support DiffServ and Ethernet traffic classification.

Multiplexed Application Substrate over QUIC Encryption (masque)

---------------------------------------------------------------

"IP Proxying Support for HTTP", Tommy Pauly, David Schinazi, Alex
Chernyakhovsky, Mirja Kuehlewind, Magnus Westerlund, 2022-07-11,
<draft-ietf-masque-connect-ip-02.txt>
 This document describes a method of proxying IP packets over HTTP.
This protocol is similar to CONNECT-UDP, but allows transmitting
arbitrary IP packets, without being limited to just TCP like CONNECT
or UDP like CONNECT-UDP.

MBONE Deployment (mboned)

-------------------------

"Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng,
Xufeng Liu, Mahesh Sivakumar, 2022-08-31,
<draft-ietf-mboned-multicast-yang-model-07.txt>

This document provides a general multicast YANG data model, which

takes full advantages of existed multicast protocol models to control
the multicast network, and guides the deployment of multicast
service.

"Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, 2022-03-07,

<draft-ietf-mboned-ambi-03.txt>

This document defines Asymmetric Manifest-Based Integrity (AMBI).

AMBI allows each receiver or forwarder of a stream of multicast
packets to check the integrity of the contents of each packet in the
data stream. AMBI operates by passing cryptographically verifiable
hashes of the data packets inside manifest messages, and sending the
manifests over authenticated out-of-band communication channels.

"Discovery Of Restconf Metadata for Source-specific multicast", Jake

Holland, 2022-03-07, <draft-ietf-mboned-dorms-04.txt>

This document defines DORMS (Discovery Of Restconf Metadata for

Source-specific multicast), a method to discover and retrieve
extensible metadata about source-specific multicast channels using
RESTCONF. The reverse IP DNS zone for a multicast sender's IP
address is configured to use SRV resource records to advertise the
hostname of a RESTCONF server that publishes metadata according to a
new YANG module with support for extensions. A new service name and
the new YANG module are defined.

"Circuit Breaker Assisted Congestion Control", Jake Holland, 2022-03-07,

<draft-ietf-mboned-cbacc-04.txt>

This document specifies Circuit Breaker Assisted Congestion Control

(CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate
metadata about multicast channels from senders to intermediate
network nodes or receivers. The circuit breaker behavior is defined
as a supplement to receiver driven congestion control systems, to
preserve network health if misbehaving or malicious receiver
applications subscribe to a volume of traffic that exceeds capacity
policies or capability for a network or receiving device.

"Multicast Network Address Translation", Jake Holland, 2022-03-07,

<draft-ietf-mboned-mnat-01.txt>

This document defines a method for a network to maintain Network

Address Translation address mappings for the transport of globally
addressed multicast traffic within a network that can't otherwise
forward the globally addressed traffic. A new Multicast Network
 Address Translation (MNAT) service is defined to communicate the
address mappings to ingress and egress points within the network, and
considerations for operation of the MNAT service are described.

"Multicast On-path Telemetry using IOAM", Haoyu Song, Mike McBride, Greg
Mirsky, Gyan Mishra, Hitoshi Asaeda, Tianran Zhou, 2022-08-11,
<draft-ietf-mboned-multicast-telemetry-04.txt>

This document discusses the requirements of on-path telemetry for

multicast traffic using In-situ OAM. Applying In-situ OAM for
multicast telemetry presents some unique challenges. This document
provides the solutions based on the In-situ OAM trace option and
direct export option to support the telemetry data correlation and
the multicast tree reconstruction without collecting redundant data.

"Multicast Redundant Ingress Router Failover", Greg Shepherd, Zheng Zhang,

Yisong Liu, Ying Cheng, Gyan Mishra, 2022-07-11,
<draft-ietf-mboned-redundant-ingress-failover-01.txt>

This document discusses multicast redundant ingress router failover

issues, include global multicast and Service Provider Network MVPN
use case. This document analyzes specification of global multicast
and Multicast VPN Fast Upstream Failover and the Ingress PE Standby
Modes and the benefits of each mode.

Media Type Maintenance (mediaman)

---------------------------------

"The 'haptics' Top-level Media Type", Yeshwant Muthusamy, Chris Ullrich,

2022-05-22, <draft-ietf-mediaman-haptics-01.txt>

This memo serves to register and document the 'haptics' top-level

media type, under which subtypes for representation formats for
haptics may be registered. This document also serves as a
registration application for a set of intended subtypes, which are
representative of some existing subtypes already in use.

"Guidelines for the Definition of New Top Level Media Types", Martin
Duerst, 2022-07-10, <draft-ietf-mediaman-toplevel-00.txt>

The goal of this document is to identify best practices for defining

new top-level media types. It updates RFC 6838, when approved.
Comments and discussion about this document should be directed to
media-types@ietf.org, the mailing list of the Media Type Maintenance
(mediaman) WG.

Messaging Layer Security (mls)

------------------------------

"The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin

Beurdouche, Raphael Robert, Jon Millican, Emad Omara, Katriel Cohn-Gordon,
2022-07-11, <draft-ietf-mls-protocol-16.txt>

Messaging applications are increasingly making use of end-to-end

security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in
delivering messages. Establishing keys to provide such protections
is challenging for group chat settings, in which more than two
clients need to agree on a key but may not be online at the same
 time. In this document, we specify a key establishment protocol that
provides efficient asynchronous group key establishment with forward
secrecy and post-compromise security for groups in size ranging from
two to thousands.

"The Messaging Layer Security (MLS) Architecture", Benjamin Beurdouche,

Eric Rescorla, Emad Omara, Srinivas Inguva, Albert Kwon, Alan Duric,
2022-08-19, <draft-ietf-mls-architecture-09.txt>

The Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol]

specification has the role of defining a Group Key Agreement
protocol, including all the cryptographic operations and
serialization/deserialization functions necessary for scalable and
secure group messaging. The MLS protocol is meant to protect against
eavesdropping, tampering, message forgery, and provide further
properties such as Forward Secrecy (FS) and Post-Compromise Security
(PCS) in the case of past or future device compromises.

This document describes a general secure group messaging

infrastructure and its security goals. It provides guidance on
building a group messaging system and discusses security and privacy
tradeoffs offered by multiple security mechanisms that are part of
the MLS protocol (e.g., frequency of public encryption key rotation).

The document also provides guidance for parts of the infrastructure

that are not standardized by the MLS Protocol document and left to
the application or the infrastructure architects to design.

While the recommendations of this document are not mandatory to

follow in order to interoperate at the protocol level, they affect
the overall security guarantees that are achieved by a messaging
application. This is especially true in case of active adversaries
that are able to compromise clients, the delivery service, or the
authentication service.

"The Messaging Layer Security (MLS) Federation", Emad Omara, Raphael

Robert, 2022-05-19, <draft-ietf-mls-federation-01.txt>

This document describes how the Messaging Layer Security (MLS)

protocol can be used in a federated environment.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/mlswg/mls-federation.

"The Messaging Layer Security (MLS) Extensions", Raphael Robert,

2022-05-27, <draft-robert-mls-extensions-00.txt>

This document describes extensions to the Messaging Layer Security

(MLS) protocol.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

 https://github.com/mlswg/mls-extensions.

Media OPerationS (mops)

-----------------------

"Operational Considerations for Streaming Media", Jake Holland, Ali Begen,

Spencer Dawkins, 2022-08-08, <draft-ietf-mops-streaming-opcons-12.txt>

This document provides an overview of operational networking and

transport protocol issues that pertain to the quality of experience
when streaming video and other high-bitrate media over the Internet.

This document is intended to explain the characteristics of streaming

media delivery that have surprised network designers or transport
experts who lack specific media expertise, since streaming media
highlights key differences between common assumptions in existing
networking practices and observations of media delivery issues
encountered when streaming media over those existing networks.

"Media Operations Use Case for an Extended Reality Application on Edge

Computing Infrastructure", Renan Krishna, Akbar Rahman, 2022-08-08,
<draft-ietf-mops-ar-use-case-06.txt>

This document explores the issues involved in the use of Edge

Computing resources to operationalize media use cases that involve
Extended Reality (XR) applications. In particular, we discuss those
applications that run on devices having different form factors and
need Edge computing resources to mitigate the effect of problems such
as a need to support interactive communication requiring low latency,
limited battery power, and heat dissipation from those devices. The
intended audience for this document are network operators who are
interested in providing edge computing resources to operationalize
the requirements of such applications. We discuss the expected
behavior of XR applications which can be used to manage the traffic.
In addition, we discuss the service requirements of XR applications
to be able to run on the network.

Multiprotocol Label Switching (mpls)

------------------------------------

"Refresh-interval Independent FRR Facility Protection", Chandrasekar R,

Tarek Saad, Ina Minei, Dante Pacella, 2022-06-19,
<draft-ietf-mpls-ri-rsvp-frr-13.txt>

RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two

local repair techniques to reroute Label Switched Path (LSP) traffic
over pre-established backup tunnel. Facility backup method allows
one or more LSPs traversing a connected link or node to be protected
using a bypass tunnel. The many-to-one nature of local repair
technique is attractive from scalability point of view. This
document enumerates facility backup procedures in RFC 4090 that rely
on refresh timeout and hence make facility backup method refresh-
interval dependent. The RSVP-TE extensions defined in this document
will enhance the facility backup protection mechanism by making the
corresponding procedures refresh-interval independent and hence
compatible with Refresh-interval Independent RSVP (RI-RSVP) specified
in RFC 8370. Hence, this document updates RFC 4090 in order to
support RI-RSVP capability specified in RFC 8370.
"RFC6374 Synonymous Flow Labels", Stewart Bryant, George Swallow, Mach
Chen, Giuseppe Fioccola, Greg Mirsky, 2021-03-05,
<draft-ietf-mpls-rfc6374-sfl-10.txt>

RFC 6374 describes methods of making loss and delay measurements on

Label Switched Paths (LSPs) primarily as used in MPLS Transport
Profile (MPLS-TP) networks. This document describes a method of
extending RFC 6374 performance measurements from flows carried over
MPLS-TP to flows carried over generic MPLS LSPs. In particular, it
extends the technique to allow loss and delay measurements to be made
on multi-point to point LSPs and introduces some additional
techniques to allow more sophisticated measurements to be made in
both MPLS-TP and generic MPLS networks.

"Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress
Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes",
Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Xiaohu Xu,
2022-05-01, <draft-ietf-mpls-sr-epe-oam-05.txt>

Egress Peer Engineering (EPE) is an application of Segment Routing to

Solve the problem of egress peer selection. The Segment Routing
based BGP-EPE solution allows a centralized controller, e.g. a
Software Defined Network (SDN) controller to program any egress peer.
The EPE solution requires a node to program the PeerNode Segment
Identifier(SID) describing a session between two nodes, the PeerAdj
SID describing the link (one or more) that is used by sessions
between peer nodes, and the PeerSet SID describing an arbitrary set
of sessions or links between a local node and its peers. This
document provides new sub-TLVs for EPE Segment Identifiers (SID) that
would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and
Traceroute procedures.

"Performance Measurement Using RFC 6374 for Segment Routing Networks with
MPLS Data Plane", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Stefano
Salsano, Mach Chen, 2022-08-23, <draft-ietf-mpls-rfc6374-sr-06.txt>

Segment Routing (SR) leverages the source routing paradigm. RFC 6374
specifies protocol mechanisms to enable the efficient and accurate
measurement of packet loss, one-way and two-way delay, as well as
related metrics such as delay variation in MPLS networks. This
document utilizes these mechanisms for Performance Delay and Loss
Measurements in SR networks with MPLS data plane (SR-MPLS), for both
SR-MPLS links and end-to-end SR-MPLS paths including Policies. In
addition, this document defines Return Path TLV and Block Number TLV
extensions for RFC 6374.

"A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow,
Siva Sivabalan, 2022-08-06, <draft-ietf-mpls-sfl-control-03.txt>

In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was
introduced. This document describes a simple control protocol that
runs over an associated control header to request, withdraw, and
extend the lifetime of such labels. It is not the only control
protocol that might be used to support SFL, but it has the benefit of
being able to be used without modifying of the existing MPLS control
protocols. The existence of this design is not intended to restrict
the ability to enhance an existing MPLS control protocol to add a
similar capability.
 A Querier MUST wait a configured time (suggested wait of 60 seconds)
before re-attempting a Withdraw request. No more than three Withdraw
requests SHOULD be made. These restrictions are to prevent
overloading the control plane of the actioning router.

"Encapsulation For MPLS Performance Measurement with Alternate Marking

Method", Weiqiang Cheng, Xiao Min, Tianran Zhou, Ximing Dong, Yoav Peleg,
2022-07-01, <draft-ietf-mpls-inband-pm-encapsulation-03.txt>

This document defines the encapsulation for MPLS performance

measurement with alternate marking method, which performs flow-based
packet loss, delay, and jitter measurements on live traffic.

"Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute
Mechanisms", Deepti Rathi, Kapil Arora, Shraddha Hegde, Zafar Ali, Nagendra
Nainar, 2022-03-30, <draft-ietf-mpls-egress-tlv-for-nil-fec-04.txt>

MPLS ping and traceroute mechanism as described in RFC 8029 and

related extensions for SR as defined in RFC 8287 is very useful to
precisely validate the control plane and data plane synchronization.
There is a possibility that all intermediate or transit nodes may not
have been upgraded to support these validation procedures. A simple
mpls ping and traceroute mechanism comprises of ability to traverse
any path without having to validate the control plane state. RFC
8029 supports this mechanism with Nil FEC. The procedures described
in RFC 8029 are mostly applicable when the Nil FEC is used as
intermediate FEC in the label stack. When all labels in label stack
are represented using single Nil FEC, it poses some challenges.

This document introduces new TLV as additional extension to exisiting

Nil FEC and describes mpls ping and traceroute procedures using Nil
FEC with this additional extensions to overcome these challenges.

"PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks",

Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra
Nainar, 2022-06-13, <draft-ietf-mpls-spring-inter-domain-oam-03.txt>

Segment Routing (SR) architecture leverages source routing and

tunneling paradigms and can be directly applied to the use of a
Multiprotocol Label Switching (MPLS) data plane. A network may
consist of multiple IGP domains or multiple ASes under the control of
same organization. It is useful to have the Label switched Path
(LSP) Ping and traceroute procedures when an SR end-to-end path spans
across multiple ASes or domains. This document describes mechanisms
to facilitae LSP ping and traceroute in inter-AS/inter-domain SR-MPLS
networks in an efficient manner with simple Operations,
Administration, and Maintenance (OAM) protocol extension which uses
dataplane forwarding alone for sending echo reply.

"BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Greg

Mirsky, Gyan Mishra, Donald Eastlake, 2022-08-18,
<draft-ietf-mpls-p2mp-bfd-02.txt>

This document describes procedures for using Bidirectional Forwarding

Detection (BFD) for multipoint networks to detect data plane failures
in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
Label Switched Paths (LSPs) and Segment Routing (SR) point-to-
multipoint policies with SR-MPLS data plane.
 It also describes the applicability of LSP Ping, as in-band, and the
control plane, as out-band, solutions to bootstrap a BFD session.

It also describes the behavior of the active tail for head

notification.

"Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data",
Tarek Saad, Kiran Makhijani, Haoyu Song, Greg Mirsky, 2022-05-19,
<draft-ietf-mpls-mna-usecases-00.txt>

This document presents a number of use cases that have a common need
for encoding network action indicators and associated ancillary data
inside MPLS packets. There has been significant recent interest in
extending the MPLS data plane to carry such indicators and ancillary
data to address a number of use cases that are described in this
document.

The use cases described in this document are not an exhaustive set,
but rather the ones that are actively discussed by members of the
IETF MPLS, PALS and DETNET working groups participating in the MPLS
Open Design Team.

"Requirements for MPLS Network Action Indicators and MPLS Ancillary Data",
Matthew Bocci, Stewart Bryant, John Drake, 2022-08-19,
<draft-ietf-mpls-mna-requirements-03.txt>

This document specifies requirements for MPLS network actions which

affect the forwarding or other processing of MPLS packets. These
requirements are derived from a number of proposals for additions to
the MPLS label stack to allow forwarding or other processing
decisions to be made, either by a transit or terminating LSR (i.e.
the LER).

"mLDP Extensions for Multi-Topology Routing", IJsbrand Wijnands, Syed Raza,

Mankamana Mishra, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko, 2022-07-26,
<draft-ietf-mpls-mldp-multi-topology-01.txt>

Multi-Topology Routing (MTR) is a technology to enable service

differentiation within an IP network. Flexible Algorithm (FA) is
another mechanism of creating a sub-topology within a topology using
defined topology constraints and computation algorithm. In order to
deploy mLDP in a network that supports MTR and/or FA, mLDP is
required to become topology and FA aware. This document specifies
extensions to mLDP to support MTR with FA such that when building a
Multi-Point LSPs it can follow a particular topology and algorithm.

"MPLS Network Actions Framework", Loa Andersson, Stewart Bryant, Matthew

Bocci, Tony Li, 2022-07-26, <draft-ietf-mpls-mna-fwk-00.txt>

This document specifies an architectural framework for the MPLS

Network Actions (MNA) technologies. MNA technologies are used to
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
and to transfer data needed for these actions.

The document describes a common set of network actions and

information elements supporting additional operational models and
capabilities of MPLS networks. Some of these actions are defined in
existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements found in
 "Requirements for MPLS Network Action Indicators and Ancillary Data".

Network Configuration (netconf)

-------------------------------

"YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, 2022-08-30,
<draft-ietf-netconf-tls-client-server-30.txt>

This document defines three YANG 1.1 modules: the first defines
features and groupings common to both TLS clients and TLS servers,
the second defines a grouping for a generic TLS client, and the third
defines a grouping for a generic TLS server.

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements:

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* BBBB --> the assigned RFC value for draft-ietf-netconf-trust-

anchors

* CCCC --> the assigned RFC value for draft-ietf-netconf-keystore

* DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-

server

* FFFF --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-08-30 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix B. Change Log

"RESTCONF Client and Server Models", Kent Watsen, 2022-05-24,

<draft-ietf-netconf-restconf-client-server-26.txt>

This document defines two YANG modules, one module to configure a

RESTCONF client and the other module to configure a RESTCONF server.
Both modules support the TLS transport protocol with both standard
RESTCONF and RESTCONF Call Home connections.

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.
 Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements (note: not all may
be present):

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* BBBB --> the assigned RFC value for draft-ietf-netconf-trust-

anchors

* CCCC --> the assigned RFC value for draft-ietf-netconf-keystore

* DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-

server

* EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client-

server

* FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client-

server

* GGGG --> the assigned RFC value for draft-ietf-netconf-http-

client-server

* HHHH --> the assigned RFC value for draft-ietf-netconf-netconf-

client-server

* IIII --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-05-24 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix A. Change Log

"YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, 2022-08-30,
<draft-ietf-netconf-ssh-client-server-30.txt>

This document defines three YANG 1.1 modules: the first defines
features and groupings common to both SSH clients and SSH servers,
the second defines a grouping for a generic SSH client, and the third
defines a grouping for a generic SSH server.

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements:

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types
 * BBBB --> the assigned RFC value for draft-ietf-netconf-trust-
anchors

* CCCC --> the assigned RFC value for draft-ietf-netconf-keystore

* DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-

server

* EEEE --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-08-30 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix B. Change Log

"NETCONF Client and Server Models", Kent Watsen, 2022-05-24,

<draft-ietf-netconf-netconf-client-server-26.txt>

This document defines two YANG modules, one module to configure a

NETCONF client and the other module to configure a NETCONF server.
Both modules support both the SSH and TLS transport protocols, and
support both standard NETCONF and NETCONF Call Home connections.

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements (note: not all may
be present):

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* BBBB --> the assigned RFC value for draft-ietf-netconf-trust-

anchors

* CCCC --> the assigned RFC value for draft-ietf-netconf-keystore

* DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-

server

* EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client-

server

* FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client-

server

* GGGG --> the assigned RFC value for draft-ietf-netconf-http-

client-server
 * HHHH --> the assigned RFC value for this draft
Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:

* 2022-05-24 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix A. Change Log

"A YANG Data Model for a Keystore", Kent Watsen, 2022-05-24,

<draft-ietf-netconf-keystore-25.txt>

This document defines a YANG module called "ietf-keystore" that

enables centralized configuration of both symmetric and asymmetric
keys. The secret value for both key types may be encrypted or
hidden. Asymmetric keys may be associated with certificates.
Notifications are sent when certificates are about to expire.

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements:

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* CCCC --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-05-24 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix A. Change Log

"YANG Data Types and Groupings for Cryptography", Kent Watsen, 2022-07-07,
<draft-ietf-netconf-crypto-types-24.txt>

This document presents a YANG 1.1 (RFC 7950) module defining

identities, typedefs, and groupings useful to cryptographic
applications.

"A YANG Data Model for a Truststore", Kent Watsen, 2022-05-24,

<draft-ietf-netconf-trust-anchors-18.txt>

This document defines a YANG module for configuring bags of

certificates and bags of public keys that can be referenced by other
data models for trust. Notifications are sent when certificates are
about to expire.

Editorial Note (To be removed by RFC Editor)

 This draft contains placeholder values that need to be replaced with
finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements:

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* BBBB --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-05-24 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix A. Change Log

"YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael
Scharf, 2022-05-24, <draft-ietf-netconf-tcp-client-server-13.txt>

This document defines three YANG 1.1 modules to support the

configuration of TCP clients and TCP servers. The modules include
basic parameters of a TCP connection relevant for client or server
applications, as well as client configuration required for traversing
proxies. The modules can be used either standalone or in conjunction
with configuration of other stack protocol layers.

"An HTTPS-based Transport for YANG Notifications", Mahesh Jethanandani,

Kent Watsen, 2022-08-22, <draft-ietf-netconf-https-notif-12.txt>

This document defines a protocol for sending notifications over

HTTPS. YANG modules for configuring publishers are also defined.
Examples are provided illustrating how to configure various
publishers.

This document requires that the publisher is a "server" (e.g., a

NETCONF or RESTCONF server), but does not assume that the receiver is
a server.

"YANG Groupings for HTTP Clients and HTTP Servers", Kent Watsen,
2022-05-24, <draft-ietf-netconf-http-client-server-10.txt>

This document defines two YANG modules: the first defines a minimal
grouping for configuring an HTTP client, and the second defines a
minimal grouping for configuring an HTTP server. It is intended that
these groupings will be used to help define the configuration for
simple HTTP-based protocols (not for complete web servers or
browsers).

Editorial Note (To be removed by RFC Editor)

This draft contains placeholder values that need to be replaced with

finalized values at the time of publication. This note summarizes
 all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.

Artwork in this document contains shorthand references to drafts in

progress. Please apply the following replacements (note: not all may
be present):

* AAAA --> the assigned RFC value for draft-ietf-netconf-crypto-

types

* DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client-

server

* FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client-

server

* GGGG --> the assigned RFC value for this draft

Artwork in this document contains placeholder values for the date of

publication of this draft. Please apply the following replacement:

* 2022-05-24 --> the publication date of this draft

The following Appendix section is to be removed prior to publication:

* Appendix A. Change Log

"Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch

Provisioning (SZTP) Bootstrapping Request", Kent Watsen, Russ Housley, Sean
Turner, 2022-03-02, <draft-ietf-netconf-sztp-csr-14.txt>

This draft extends the input to the "get-bootstrapping-data" RPC

defined in RFC 8572 to include an optional certificate signing
request (CSR), enabling a bootstrapping device to additionally obtain
an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part
of the "onboarding information" response provided in the RPC-reply.

"Subscription to Distributed Notifications", Tianran Zhou, Guangying Zheng,

Eric Voit, Thomas Graf, Pierre Francois, 2022-07-08,
<draft-ietf-netconf-distributed-notif-04.txt>

This document describes extensions to the YANG notifications

subscription to allow metrics being published directly from
processors on line cards to target receivers, while subscription is
still maintained at the route processor in a distributed forwarding
system.

"UDP-based Transport for Configured Subscriptions", Guangying Zheng,

Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente,
2022-07-11, <draft-ietf-netconf-udp-notif-07.txt>

This document describes an UDP-based notification mechanism to

collect data from networking devices. A shim header is proposed to
facilitate the data streaming directly from the publishing process on
network processor of line cards to receivers. The objective is to
provide a lightweight approach to enable higher frequency and less
performance impact on publisher and receiver processes compared to
already established notification mechanisms.
 "Adaptive Subscription to YANG Notification", Qin WU, Wei Song, Peng Liu,
Qiufang Ma, Wei Wang, Zhixiong Niu, 2022-06-23,
<draft-ietf-netconf-adaptive-subscription-00.txt>

This document defines a YANG data model and associated mechanism

enabling the subscriber's adaptive subscriptions to a publisher's
event streams with various different period intervals to report
updates. Applying these elements allows servers automatically adjust
the rate and volume of telemetry traffic sent from a publisher to
receivers.

"List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Olof
Hagsand, Hongwei Li, Per Andersson, 2022-07-24,
<draft-ietf-netconf-list-pagination-00.txt>

In some circumstances, instances of YANG modeled "list" and "leaf-

list" nodes may contain numerous entries. Retrieval of all the
entries can lead to inefficiencies in the server, the client, and the
network in between.

This document defines a model for list pagination that can be

implemented by YANG-driven management protocols such as NETCONF and
RESTCONF. The model supports paging over optionally filtered and/or
sorted entries. The solution additionally enables servers to
constrain query expressions on some "config false" lists or leaf-
lists.

"NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
Hagsand, Hongwei Li, Per Andersson, 2022-07-24,
<draft-ietf-netconf-list-pagination-nc-00.txt>

This document defines a mapping of the list pagination mechanism

defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241].

This document updates [RFC6241], to augment the <get> and <get-

config> "rpc" statements, and [RFC8526], to augment the <get-data>
"rpc" statement, to define input parameters necessary for list
pagination.

"RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
Hagsand, Hongwei Li, Per Andersson, 2022-07-24,
<draft-ietf-netconf-list-pagination-rc-00.txt>

This document defines a mapping of the list pagination mechanism

defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040].

This document updates RFC 8040, to declare "list" and "leaf-list" as

valid resource targets for the RESTCONF GET and DELETE operations, to
define GET query parameters necessary for list pagination, and to
define a media-type for XML-based lists.

Network Modeling (netmod)

-------------------------

"A YANG Data Model for Syslog Configuration", Joe Clarke, Mahesh
Jethanandani, Clyde Wildes, Kiran Koushik, 2022-04-06,
<draft-ietf-netmod-syslog-model-27.txt>

This document defines a YANG data model for the configuration of a

 syslog process. It is intended this model be used by vendors who
implement syslog in their systems.

"YANG Module Versioning Requirements", Joe Clarke, 2022-07-10,

<draft-ietf-netmod-yang-versioning-reqs-07.txt>

This document describes the problems that can arise because of the
YANG language module update rules, that require all updates to YANG
module preserve strict backwards compatibility. It also defines the
requirements on any solution designed to solve the stated problems.
This document does not consider possible solutions, nor endorse any
particular solution.

"Common YANG Data Types", Juergen Schoenwaelder, 2022-03-22,

<draft-ietf-netmod-rfc6991-bis-13.txt>

This document defines a collection of common data types to be used

with the YANG data modeling language. This document obsoletes RFC
6991.

"Updated YANG Module Revision Handling", Robert Wilton, Reshad Rahman,

Balazs Lengyel, Joe Clarke, Jason Sterne, 2022-07-10,
<draft-ietf-netmod-yang-module-versioning-06.txt>

This document specifies a new YANG module update procedure that can
document when non-backwards-compatible changes have occurred during
the evolution of a YANG module. It extends the YANG import statement
with an earliest revision filter to better represent inter-module
dependencies. It provides guidelines for managing the lifecycle of
YANG modules and individual schema nodes. It provides a mechanism,
via the revision-label YANG extension, to specify a revision
identifier for YANG modules and submodules. This document updates
RFC 7950, RFC 6020, RFC 8407 and RFC 8525.

"YANG Packages", Robert Wilton, Reshad Rahman, Joe Clarke, Jason Sterne, Bo
Wu, 2022-03-04, <draft-ietf-netmod-yang-packages-03.txt>

This document defines YANG packages; a versioned organizational

structure used to manage schema and conformance of YANG modules as a
cohesive set instead of individually.

It describes how packages: are represented on a server, can be

defined in offline YANG instance data files, and can be used to
define the content schema associated with YANG instance data files.

"YANG Semantic Versioning", Joe Clarke, Robert Wilton, Reshad Rahman,

Balazs Lengyel, Jason Sterne, Benoit Claise, 2022-07-10,
<draft-ietf-netmod-yang-semver-07.txt>

This document specifies a scheme and guidelines for applying an

extended set of semantic versioning rules to revisions of YANG
artifacts (e.g., modules and packages). Additionally, this document
defines an RFCAAAA-compliant revision-label-scheme for this YANG
semantic versioning scheme.

"Node Tags in YANG Modules", Qin WU, Benoit Claise, Peng Liu, Zongpeng Du,
Mohamed Boucadair, 2022-06-22, <draft-ietf-netmod-node-tags-08.txt>

This document defines a method to tag nodes that are associated with
 operation and management data in YANG modules. This method for
tagging YANG nodes is meant to be used for classifying either data
nodes or instances of data nodes from different YANG modules and
identifying their characteristic data. Tags may be registered as
well as assigned during the definition of the module, assigned by
implementations, or dynamically defined and set by users.

This document also provides guidance to future YANG data model

writers; as such, this document updates RFC 8407.

Network File System Version 4 (nfsv4)

-------------------------------------

"Towards Remote Procedure Call Encryption By Default", Trond Myklebust,

Chuck Lever, 2020-11-23, <draft-ietf-nfsv4-rpc-tls-11.txt>

This document describes a mechanism that, through the use of

opportunistic Transport Layer Security (TLS), enables encryption of
Remote Procedure Call (RPC) transactions while they are in-transit.
The proposed mechanism interoperates with ONC RPC implementations
that do not support it. This document updates RFC 5531.

"Extending the Opening of Files in NFSv4.2", Thomas Haynes, Trond

Myklebust, 2022-06-02, <draft-ietf-nfsv4-delstid-01.txt>

The Network File System v4 (NFSv4) allows a client to both open a

file and be granted a delegation of that file. This provides the
client the right to cache metadata on the file locally. This
document presents several refinements to both the opening and
delegating of the file to the client.

"RPC-over-RDMA Version 2 Protocol", Chuck Lever, David Noveck, 2022-06-28,

<draft-ietf-nfsv4-rpcrdma-version-two-07.txt>

This document specifies the second version of a transport protocol

that conveys Remote Procedure Call (RPC) messages using Remote Direct
Memory Access (RDMA). This version of the protocol is extensible.

"Network File System (NFS) Upper-Layer Binding To RPC-Over-RDMA Version 2",

Chuck Lever, 2022-05-13, <draft-ietf-nfsv4-nfs-ulb-v2-07.txt>

This document specifies Upper-Layer Bindings of Network File System

(NFS) protocol versions to RPC-over-RDMA version 2.

Network Management (nmrg)

-------------------------

"Intent-Based Networking - Concepts and Definitions", Alexander Clemm,

Laurent Ciavaglia, Lisandro Granville, Jeff Tantsura, 2022-03-24,
<draft-irtf-nmrg-ibn-concepts-definitions-09.txt>

Intent and Intent-Based Networking (IBN) are taking the industry by

storm. At the same time, IBN-related terms are often used loosely
and inconsistently, in many cases overlapping and confused with other
concepts such as "Policy." This document clarifies the concept of
"Intent" and provides an overview of the functionality that is
associated with it. The goal is to contribute towards a common and
shared understanding of terms, concepts, and functionality that can
be used as the foundation to guide further definition of associated
 research and engineering problems and their solutions.

This document is a product of the IRTF Network Management Research

Group (NMRG). It reflects the consensus of the research group,
having received many detailed and positive reviews by RG
participants. It is published for informational purposes.

"Intent Classification", Chen Li, Olga Havel, Adriana Olariu, Pedro

Martinez-Julia, Jeferson Nobre, Diego Lopez, 2022-05-18,
<draft-irtf-nmrg-ibn-intent-classification-08.txt>

Intent is an abstract, high-level policy used to operate the network.

Intent-based management system includes an interface for users to
input requests and an engine to translate the intents into the
network configuration and manage their life-cycle.

This document discusses mostly the concept of network intents, but

other types of intents are also being considered. Specifically, it
highlights stakeholder perspectives of intent, methods to classify
and encode intent, the associated intent taxonomy, and defines
relevant intent terms where necessary. This document provides a
foundation for intent related research and facilitates solution
development.

This document is a product of the IRTF Network Management Research

Group (NMRG).

"Digital Twin Network: Concepts and Reference Architecture", Cheng Zhou,

Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed
Boucadair, Christian Jacquenet, 2022-07-11,
<draft-irtf-nmrg-network-digital-twin-arch-01.txt>

Digital Twin technology has been seen as a rapid adoption technology

in Industry 4.0. The application of Digital Twin technology in the
networking field is meant to develop various rich network
applications and realize efficient and cost effective data driven
network management and accelerate network innovation.

This document presents an overview of the concepts of Digital Twin

Network, provides the basic definitions and a reference architecture,
lists a set of application scenarios, and discusses the benefits and
key challenges of such technology.

Individual Submissions (none)

-----------------------------

"Mapping Between MIME Types, Content-Types, and URIs", Donald Eastlake,

2022-06-04, <draft-eastlake-cturi-07.txt>

Multipurpose Internet Mail Extension (MIME) Content-Type headers, the

MIME types used therein, and Uniform Resource Identifiers (URIs) are
being used, in different contexts, to label entities. A mapping is
specified from each kind of label into the other. This makes it
possible to express the meaning of almost any URI or Content-Type in
the syntax of the other.

"The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2022-07-25,

<draft-kunze-ark-35.txt>
 The ARK (Archival Resource Key) naming scheme is designed to
facilitate the high-quality and persistent identification of
information objects. The label "ark:" marks the start of a core ARK
identifier that can be made actionable by prepending the beginning of
a URL. Meant to be usable after today's networking technologies
become obsolete, that core should be recognizable in the future as a
globally unique ARK independent of the URL hostname, HTTP, etc. A
founding principle of ARKs is that persistence is purely a matter of
service and neither inherent in an object nor conferred on it by a
particular naming syntax. The best any identifier can do is lead
users to services that support robust reference. A full-functioning
ARK leads the user to the identified object and, with the "?info"
inflection appended, returns a metadata record and a commitment
statement that is both human- and machine-readable. Tools exist for
minting, binding, and resolving ARKs.

"An IPv4 Flowlabel Option", Thomas Dreibholz, 2022-03-21,

<draft-dreibholz-ipv4-flowlabel-35.txt>

This draft defines an IPv4 option containing a flowlabel that is

compatible to IPv6. It is required for simplified usage of IntServ
and interoperability with IPv6.

"Prepaid Extensions to Remote Authentication Dial-In User Service

(RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig,
Andreas Pashalidis, 2013-02-25,
<draft-lior-radius-prepaid-extensions-22.txt>

This document specifies an extension to the Remote Authentication

Dial-In User Service (RADIUS) protocol that enables service providers
to charge for prepaid services. The supported charging models
supported are volume-based, duration-based, and based on one-time
events.

"Applicability of Reliable Server Pooling for Real-Time Distributed

Computing", Thomas Dreibholz, 2022-03-21,
<draft-dreibholz-rserpool-applic-distcomp-32.txt>

This document describes the applicability of the Reliable Server

Pooling architecture to manage real-time distributed computing pools
and access the resources of such pools.

"Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz,

2022-03-21, <draft-hohendorf-secure-sctp-33.txt>

This document explains the reason for the integration of security

functionality into SCTP, and gives a short description of S-SCTP and
its services. S-SCTP is fully compatible with SCTP defined in
RFC4960, it is designed to integrate cryptographic functions into
SCTP.

"Applicability of Reliable Server Pooling for SCTP-Based Endpoint

Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2022-03-21,
<draft-dreibholz-rserpool-applic-mobility-31.txt>

This document describes a novel mobility concept based on a

combination of SCTP with Dynamic Address Reconfiguration extension
and Reliable Server Pooling (RSerPool).
"Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz,
Michael Tuexen, 2022-03-21, <draft-dreibholz-rserpool-score-30.txt>

This memo describes some of the scoring to be used in the testing of

Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.

"Considerations for Information Services and Operator Services Using SIP",

John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell, 2011-08-15,
<draft-haluska-sipping-directory-assistance-11.txt>

Information Services are services whereby information is provided in

response to user requests, and may include involvement of a human or
automated agent. A popular existing Information Service is Directory
Assistance (DA). Moving ahead, Information Services providers
envision exciting multimedia services that support simultaneous
voice and data interactions with full operator backup at any time
during the call. Information Services providers are planning to
migrate to SIP based platforms, which will enable such advanced
services, while continuing to support traditional DA services.

Operator Services are traditional PSTN services which often involve

providing human or automated assistance to a caller, and often
require the specialized capabilities traditionally provided by an
operator services switch. Market and/or regulatory factors in some
jurisdictions dictate that some subset of Operator Services continue
to be provided going forward.

This document aims to identify how Operator and Information Services

can be implemented using existing or currently proposed SIP
mechanisms, to identity existing protocol gaps, and to provide a set
of Best Current Practices to facilitate interoperability. For
Operator Services, the intention is to describe how current operator
services can continue to be provided to PSTN based subscribers via a
SIP based operator services architecture. It also looks at how
current operator services might be provided to SIP based subscribers
via such an architecture, but does not consider the larger question
of the need for or usefulness or suitability of each of these
services for SIP based subscribers.

This document addresses the needs of current Operator and

Information Services providers; as such, the intended audience
includes vendors of equipment and services to such providers.

"Handle Resolution Option for ASAP", Thomas Dreibholz, 2022-03-21,

<draft-dreibholz-rserpool-asap-hropt-30.txt>

This document describes the Handle Resolution option for the ASAP
protocol.

"Definition of a Delay Measurement Infrastructure and Delay-Sensitive

Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing
Zhou, 2022-03-21, <draft-dreibholz-rserpool-delay-29.txt>

This document contains the definition of a delay measurement

infrastructure and a delay-sensitive Least-Used policy for Reliable
Server Pooling.

"Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas
Dreibholz, Xing Zhou, 2022-03-21,
<draft-dreibholz-rserpool-enrp-takeover-27.txt>

This document describes the Takeover Suggestion Flag for the

ENRP_HANDLE_UPDATE message of the ENRP protocol.

"A Record of Discussions of Graceful Restart Extensions for Bidirectional

Forwarding Detection (BFD)", Palanivelan Appanasamy, 2011-11-17,
<draft-palanivelan-bfd-v2-gr-13.txt>

This document is a historical record of discussions about extending

the Bidirectional Forwarding Detection (BFD) protocol to provide
additional capabilities to handle Graceful Restart.

These discussions took place in the context of the IETF's BFD working
group, and the consensus in that group was that these extensions
should not be made.

This document presents a summary of the challenges to BFD in

surviving a graceful restart, and outlines a potential protocol
solution that was discussed and rejected within the BFD working
group. The purpose of this document is to provide a record of the
work done so that future effort will not be wasted. This document
does not propose or document any extensions to BFD, and there is no
intention that it should be implemented in its current form.

"The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14,

<draft-hoehrmann-cp-collation-01.txt>

This memo describes the "i;codepoint" collation. Character strings

are compared based on the Unicode scalar values of the characters.
The collation supports equality, substring, and ordering operations.

"A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)",
PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2022-03-22,
<draft-spinosa-urn-lex-15.txt>

This document describes a Uniform Resource Name (URN) Namespace

Identification (NID) convention for identifying, naming, assigning,
and managing persistent resources in the legal domain. This
specification is published to allow adoption of a common convention
by multiple jurisdictions to facilitate ease of reference and access
to resources in the legal domain.

"Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards,
2010-03-23, <draft-edwards-telnet-xon-xoff-state-control-00.txt,.pdf>

This document defines new values for use with the telnet com port
control option's SET-CONTROL sub-command defined in RFC2217. These
new values provide a mechanism for the telnet client to control and
query the outbound Xon/Xoff flow control state of the telnet server's
physical serial port. This capability is exposed in the serial port
API on some operating systems and is needed by telnet clients that
implement a port-redirector service which provides applications local
to the redirector/telnet-client with transparent access to the remote
serial port on the telnet server.

"Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul
Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi
Natarajan, Randall Stewart, Michael Tuexen, 2022-08-23,
<draft-tuexen-tsvwg-sctp-multipath-24.txt>

The Stream Control Transmission Protocol (SCTP) supports multi-homing

for providing network fault tolerance. However, mainly one path is
used for data transmission. Only timer-based retransmissions are
carried over other paths as well.

This document describes how multiple paths can be used simultaneously

for transmitting user messages.

"Clarification of Proper Use of "@" (at sign) in URI-style Components",

Robert Simpson, 2010-07-30, <draft-accilent-at-sign-00.txt>

Defacto standards have evolved that conflict with existing standards,

specifically RFC 3986. This document clarifies the use of the "@"
(at sign) in URIs and partial URI-like addresses.

"Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G

Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14,
<draft-morand-http-digest-2g-aka-05.txt>

This document specifies a one-time password generation mechanism for

Hypertext Transfer Protocol (HTTP) Digest access authentication based
on Global System for Mobile Communications (GSM) authentication and
key generation functions A3 and A8, also known as GSM AKA or 2G AKA.
The HTTP Authentication Framework includes two authentication
schemes: Basic and Digest. Both schemes employ a shared secret based
mechanism for access authentication. The GSM AKA mechanism performs
user authentication and session key distribution in GSM and Universal
Mobile Telecommunications System (UMTS) networks. GSM AKA is a
challenge-response based mechanism that uses symmetric cryptography.

"Extensions to Path Computation Element Communication Protocol (PCEP) for

Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen,
2022-07-11, <draft-chen-pce-compute-backup-ingress-20.txt>

This document presents extensions to the Path Computation Element

Communication Protocol (PCEP) for a PCC to send a request for
computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P
LSP to a PCE and for a PCE to compute the backup ingress and reply to
the PCC with a computation result for the backup ingress.

"Extensions to the Path Computation Element Communication Protocol (PCEP)

for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo
Chen, 2022-07-11, <draft-chen-pce-compute-backup-egress-20.txt>

This document presents extensions to the Path Computation Element

Communication Protocol (PCEP) for a PCC to send a request for
computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P
LSP to a PCE and for a PCE to compute the backup egress and reply to
the PCC with a computation result for the backup egress.

"OSPF Abnormal State Information", Huaimo Chen, 2022-08-15,

<draft-chen-ospf-abnormal-state-info-08.txt>

This document describes a couple of options for an OSPF router to

advertise its abnormal state information in a routing domain.

"Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin
Seggelmann, Martin Becke, 2022-03-21,
<draft-dreibholz-tsvwg-sctpsocket-sqinfo-24.txt>

This document describes an extension to the SCTP sockets API for

querying information about the sender queue.

"SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas

Dreibholz, Martin Becke, Hakim Adhari, 2022-03-21,
<draft-dreibholz-tsvwg-sctpsocket-multipath-24.txt>

This document describes extensions to the SCTP sockets API for

configuring the CMT-SCTP and CMT/RP-SCTP extensions.

"Encoding the graphemes of the SignWriting Script with the x-ISWA-2010",

Stephen Slevinski, Valerie Sutton, 2011-01-03,
<draft-slevinski-iswa-2010-00.txt>

For concreteness, because the universal character set is not yet

universal, because an undocumented and unlabeled coded character set
hampers information interchange, a 12-bit coded character set has
been created that encodes the graphemes of the SignWriting script as
described in the open standard of the International SignWriting
Alphabet 2010. The x-ISWA-2010 coded character set is defined with
hexadecimal characters and described with Unicode characters, either
proposed characters on plane 1 or interchange characters on plane 15.

This memo defines a standard coded character set for the Internet
community. It is published for reference, examination,
implementation, and evaluation. Distribution of this memo is
unlimited.

"The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll,

Kiem-Phong Vo, Donald Eastlake, Tony Hansen, 2022-07-11,
<draft-eastlake-fnv-18.txt>

FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with

good dispersion. The purpose of this document is to make information
on FNV and open source code performing FNV conveniently available to
the Internet community.

"A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen,

2022-07-11, <draft-chen-pce-forward-search-p2p-path-computation-23.txt>

This document presents a forward search procedure for computing paths

for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched
Paths (LSPs) crossing a number of domains using multiple Path
Computation Elements (PCEs). In addition, extensions to the Path
Computation Element Communication Protocol (PCEP) for supporting the
forward search procedure are described.

"Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi

Kawamura, Randy Bush, Cristel Pelsser, 2012-06-21,
<draft-shishio-grow-isp-rfd-implement-survey-05.txt>

BGP Route Flap Damping [RFC2439] is a mechanism that targets route

stability. It penalyzes routes that flap with the aim of reducing
CPU load on the routers.

But it has side-effects. Thus, in 2006, RIPE recommended not to use

 Route Flap Damping (see [RIPE-378]).

Now, some researchers propose to turn RFD, with less aggressive

parameters, back on [draft-ymbk-rfd-usable].

This document describes results of a survey conducted among service

provider on their use of BGP Route Flap Damping.

"A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen,

2022-07-11, <draft-chen-pce-forward-search-p2mp-path-22.txt>

This document presents a forward search procedure for computing a

path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label
Switched Path (LSP) crossing a number of domains through using
multiple Path Computation Elements (PCEs). In addition, extensions
to the Path Computation Element Communication Protocol (PCEP) for
supporting the forward search procedure are described.

"A SAVI Solution for WLAN", Jun Bi, Jianping Wu, Tao Lin, You Wang, Lin He,
2022-05-11, <draft-bi-savi-wlan-23.txt>

This document describes a source address validation solution for

WLANs where 802.11i or other security mechanisms are enabled to
secure MAC addresses. This mechanism snoops NDP and DHCP packets to
bind IP addresses to MAC addresses, and relies on the security of MAC
addresses guaranteed by 802.11i or other mechanisms to filter IP
spoofing packets. It can work in the special situations described in
the charter of SAVI (Source Address Validation Improvements)
workgroup, such as multiple MAC addresses on one interface. This
document describes three different deployment scenarios, with
solutions for migration of binding entries when hosts move from one
access point to another.

"Unified User-Agent String", Mateusz Karcz, 2014-11-10,

<draft-karcz-uuas-01.txt>

User-Agent is a HTTP request-header field. It contains information

about the user agent originating the request, which is often used by
servers to help identify the scope of reported interoperability
problems, to work around or tailor responses to avoid particular user
agent limitations, and for analytics regarding browser or operating
system use. Over the years contents of this field got complicated
and ambiguous. That was the reaction for sending altered version of
websites to web browsers other than popular ones. During the
development of the WWW, authors of the new web browsers used to
construct User-Agent strings similar to Netscape's one. Nowadays
contents of the User-Agent field are much longer than 15 years ago.
This Memo proposes the Uniform User-Agent String as a way to simplify
the User-Agent field contents, while maintaining the previous
possibility of their use.

"SNMPD to use cache and shared database based on MIB Classification",

Haresh Khandelwal, 2012-03-29,
<draft-haresh-sushrut-mib-classification-01.txt>

This memo defines classification of SNMP MIBs to either use SNMP

cache database and shared database (SDB) mechanism to reduce high CPU
usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are
continuously performed from network management system (NMS)/SNMP
 manager/SNMP MIB browser to managed device.

"Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya

Murakami, Simon Perreault, 2013-05-17,
<draft-tsou-softwire-port-set-algorithms-analysis-04.txt>

This memo analyzes some port set definition algorithms used for
stateless IPv4 to IPv6 transition technologies. The transition
technologies using port set algorithms can be divided into two
categories: fully stateless approach and binding approach. Some
algorithms can work for both approaches.

"Two Dimensional IP Routing Architecture", Mingwei Xu, Jianping Wu, Shu

Yang, Laizhong Cui, Dan Wang, 2022-03-24,
<draft-xu-rtgwg-twod-ip-routing-01.txt>

This document describes Two Dimensional IP (TwoD-IP) routing, a new

Internet routing architecture which makes forwarding decisions based
on both source address and destination address. This presents a
fundamental extension for traditional routing mechanism, which makes
forwarding decisions based on destination addresses to provides
reachability services. Such extension provides rooms to solve
fundamental problems of the past and foster great innovations in the
future.

"The Applicability of the PCE to Computing Protection and Recovery Paths

for Single Domain and Multi-Domain Networks.", Huaimo Chen, 2022-04-18,
<draft-chen-pce-protection-applicability-18.txt>

The Path Computation Element (PCE) provides path computation

functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.

A link or node failure can significantly impact network services in

large-scale networks. Therefore it is important to ensure the
survivability of large scale networks which consist of various
connections provided over multiple interconnected networks with
varying technologies.

This document examines the applicability of the PCE architecture,

protocols, and procedures for computing protection paths and
restoration services, for single and multi-domain networks.

This document also explains the mechanism of Fast Re-Route (FRR)

where a point of local repair (PLR) needs to find the appropriate
merge point (MP) to do bypass path computation using PCE.

"An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina
Tsou, Simon Perreault, Jing Huang, 2013-09-16,
<draft-tsou-behave-ftp46-01.txt>

An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited
to an IPv6 client connecting to an IPv4 server. This memo supports
the case of an IPv4 client connecting to an IPv6 server.

"A Framework for Energy Aware Control Planes", Alvaro Retana, Russ White,
Manuel Paul, 2022-08-22, <draft-retana-rtgwg-eacp-05.txt>

Energy is a primary constraint in large-scale network design,

 particularly in cloud-scale data center fabrics. While compute and
storage clearly consume the largest amounts of energy in large-scale
networks, the optics and electronics used in transporting data also
contribute to energy usage and heat generation.

This document provides an overview of various areas of concern in the

interaction between network performance and efforts at energy aware
control planes, as a guide for those working on modifying current
control planes or designing new ones to improve the energy efficiency
of high density, highly complex, network deployments.

"Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan,

2012-08-02, <draft-mclaggan-wccp-v2rev1-00.txt>

This document describes version 2 of the Web Cache Communication

Protocol (WCCP). The WCCP V2 protocol specifies interactions between
one or more routers and one or more web-caches. The interaction may
take place within an IPv4 or IPv6 network. The purpose of the
interaction is to establish and maintain the transparent redirection
of selected types of traffic flowing through a group of routers (or
similar devices). The selected traffic is redirected to a group of
web-caches (or other traffic optimisation devices) with the aim of
optimising resource usage and lowering response times.

The protocol does not specify any interaction between the web-caches
within a group or between a web-cache and a web-server.

"The application/stream+json Media Type", James Snell, 2012-10-11,

<draft-snell-activity-streams-type-01.txt>

This specification defines and registers the application/stream+json

Content Type for the JSON Activity Streams format.

"Cryptographic Security Characteristics of 802.11 Wireless LAN Access

Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 2012-10-15,
<draft-orr-wlan-security-architectures-00.txt>

This note identifies all of the places that cryptography is used in

Wireless Local Area Network (WLAN) architectures, to simplify the
task of selecting the protocols, algorithms, and key sizes needed to
achieve a consistent security level across the entire architecture.

"Observations on the experience and nature of Large Interim Meetings", Joel

Jaeggli, Jari Arkko, 2013-01-14, <draft-jaeggli-interim-observations-04.txt>

Planning, particpipation and conclusions from the experience of

participating in the IETF LIM activity on september 29th 2012.

"I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung

Kwon, Hyojin Yoon, Sang Kim, 2013-05-03, <draft-kwon-yoon-kim-ipake-01.txt>

Although password authentication is the most widespread user

authentication method today, cryptographic protocols for mutual
authentication and key agreement, i.e., password authenticated key
exchange (PAKE), in particular authenticated key exchange (AKE) based
on a password only, are not actively used in the real world. This
document introduces a quite novel form of PAKE protocols that employ
a particular concept of ID-based encryption (IBE). The resulting
cryptographic protocol is the ID-based password authenticated key
 exchange (I-PAKE) protocol which is a secure and efficient PAKE
protocol in both soft- and hard-augmented models. I-PAKE achieves the
security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also
achieves the great efficiency by allowing the whole pre-computation
of the ephemeral Diffie-Hellman public keys by both server and
client.

"remoteStorage", Michiel de Jong, F. Kooman, S. Kippe, 2022-06-13,

<draft-dejong-remotestorage-19.txt>

This draft describes a protocol by which client-side applications,

running inside a web browser, can communicate with a data storage
server that is hosted on a different domain name. This way, the
provider of a web application need not also play the role of data
storage provider. The protocol supports storing, retrieving, and
removing individual documents, as well as listing the contents of an
individual folder, and access control is based on bearer tokens.

"Ruoska Encoding", Jukka-Pekka Makela, 2013-10-12,

<draft-ruoska-encoding-06.txt>

This document describes hierarchically structured binary encoding

format called Ruoska Encoding (later RSK). The main design goals are
minimal resource usage, well defined structure with good selection of
widely known data types, and still extendable for future usage.

The main benefit when compared to non binary hierarchically

structured formats like XML is simplicity and minimal resource
demands. Even basic XML parsing is time and memory consuming
operation.

When compared to other binary formats like BER encoding of ASN.1 the
main benefit is simplicity. ASN.1 with many different encodings is
complex and even simple implementation needs a lot of effort. RSK is
also more efficient than BER.

"Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu,

Jianping Wu, Shu Yang, Laizhong Cui, Dan Wang, 2022-03-24,
<draft-xu-homenet-twod-ip-routing-02.txt>

Home network design faces many challenges currently. Two of them are
multi-homing and policy enforcement. Different with other types of
networks, home network operators are usually not professional
technicians or geeks. The problems we face are fundamentally related
with the poor semantics provided by current destination-based routing
protocol.

TwoD-IP routing protocol is a link state routing protocol that makes

routing decisions based on both destination and source addresses.
This document describes the mechanism for supporting flexible multi-
homing and policy routing across home networks.

"ICANN Registry Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2022-03-22,

<draft-lozano-icann-registry-interfaces-17.txt>

This document describes the technical details of the interfaces

provided by the Internet Corporation for Assigned Names and Numbers
(ICANN) to its contracted parties to fulfill reporting requirements.
The interfaces provided by ICANN to Data Escrow Agents and Registry
 Operators to fulfill the requirements of Specifications 2 and 3 of
the gTLD Base Registry Agreement are described in this document.
Additionally, interfaces for retrieving the IP addresses of the probe
nodes used in the SLA Monitoring System (SLAM) and interfaces for
supporting maintenance window objects are described in this document.

"Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D",

Phillip Hallam-Baker, 2022-04-20, <draft-hallambaker-jsonbcd-22.txt>

Three binary encodings for JavaScript Object Notation (JSON) are

presented. JSON-B (Binary) is a strict superset of the JSON encoding
that permits efficient binary encoding of intrinsic JavaScript data
types. JSON-C (Compact) is a strict superset of JSON-B that supports
compact representation of repeated data strings with short numeric
codes. JSON-D (Data) supports additional binary data types for
integer and floating-point representations for use in scientific
applications where conversion between binary and decimal
representations would cause a loss of precision.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html.

"QoS-level aware Transmission Protocol (QTP) for virtual networks", Julong

Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan, 2022-04-12,
<draft-lan-nvo3-qtp-15.txt>

This document provides a QoS-level aware Transmission Protocol (QTP)

for virtual networks.

"Remote APDU Call Secure (RACS)", Pascal Urien, 2022-04-03,

<draft-urien-core-racs-16.txt>

This document describes the Remote APDU Call Protocol Secure (RACS)
protocol, dedicated to Grid of Secure Elements (GoSE). These servers
host Secure Elements (SE), i.e. tamper resistant chips offering
secure storage and cryptographic resources.

Secure Elements are microcontrollers whose chip area is about 25mm2;

they deliver trusted computing services in constrained environments.

RACS supports commands for GoSE inventory and data exchange with
secure elements. It is designed according to the representational
State Transfer (REST) architecture. RACS resources are identified by
dedicated URIs. An HTTP interface is also supported.

An open implementation [OPENRACS] is available

(https://github.com/purien) for various OS.

"Use of the WebSocket Protocol as a Transport for the Remote Framebuffer

Protocol", Nicholas Wilson, 2013-10-07, <draft-realvnc-websocket-02.txt>

The Remote Framebuffer protocol (RFB) enables clients to connect to

and control remote graphical resources. This document describes a
transport for RFB using the WebSocket protocol, and defines a
corresponding WebSocket subprotocol, enabling an RFB server to offer
resources to clients with WebSocket connectivity, such as web-
browsers.

"Metadata Query Protocol", Ian Young, 2022-07-07,

<draft-young-md-query-17.txt>

This document defines a simple protocol for retrieving metadata about

named entities, or named collections of entities. The goal of the
protocol is to profile various aspects of HTTP to allow requesters to
rely on certain, rigorously defined, behaviour.

This document is a product of the Research and Education Federations

(REFEDS) Working Group process.

"Ideas for a Next Generation of the Reliable Server Pooling Framework",

Thomas Dreibholz, 2022-03-21,
<draft-dreibholz-rserpool-nextgen-ideas-17.txt>

This document collects some idea for a next generation of the

Reliable Server Pooling framework.

"Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen,

Autumn Liu, Mehmet Toy, Vic liu, 2022-07-11,
<draft-chen-pce-label-x-domains-15.txt>

This document specifies extensions to PCEP for distributing labels

crossing domains for an inter-domain Point-to-Point (P2P) or Point-
to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path
(LSP).

"Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol
and/or the Transport Layer Security (TLS) Protocol", Walter Hoehlhubmer,
2013-11-25, <draft-hoehlhubmer-https-addon-07.txt>

This document describes an Add-on for websites providing encrypted

connectivity (HTTP over TLS).

The Add-on has two parts, one for the Domain Name System (DNS) -
storing the X.509 certificate hashes - and one for the webserver
itself - an additional webpage providing specific informations.

"Generic Fault-Avoidance Routing Protocol for Data Center Networks", Bin

Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish, 2022-06-01,
<draft-sl-rtgwg-far-dcn-18.txt>

This document describes a generic routing method and protocol for a

regular data center network, named the Fault-Avoidance Routing (FAR)
protocol. The FAR protocol provides a generic routing method for all
types of regular topology network architectures that have been
proposed for large-scale cloud-based data centers over the past few
years. The FAR protocol is designed to leverage any regularity in
the topology and compute its routing table in a concise manner. Fat-
tree is taken as an example architecture to illustrate how the FAR
protocol can be applied in real operational scenarios.

"An IP option for describing the traffic flow", Robert Chodorek,

2022-08-14, <draft-chodorek-traffic-flow-option-10.txt>

Information about the behavior of the stream that will be

transmitted in the near future will allow for better management
of queues in the router and thus improve QoS and reduce the
potential for a serious overload. Such information is often
available in the transmitter. The proposed IP option allows for
 the sending of information about forthcoming traffic from the
transmitter to the intermediate nodes.

"SAML Profile for the Metadata Query Protocol", Ian Young, 2022-07-07,
<draft-young-md-query-saml-17.txt>

This document profiles the Metadata Query Protocol for use with SAML
metadata.

This document is a product of the Research and Education Federations

(REFEDS) Working Group process.

Editorial Note (To be removed by RFC Editor before publication)

Discussion of this draft takes place on the MDX mailing list

(mdx@lists.iay.org.uk), which is accessed from [MDX.list].

XML versions, latest edits and the issues list for this document are
available from [md-query].

The changes in this draft are summarized in Appendix A.18.

"BGP Auto Discovery", Robert Raszuk, Jon Mitchell, Warren Kumari, Keyur
Patel, John Scudder, 2022-04-29,
<draft-raszuk-idr-bgp-auto-discovery-08.txt>

This document describes a method for automating portions of a

router's BGP configuration via discovery of BGP peers with which to
establish further sessions from an initial "bootstrap" router. This
method can apply for establishment of either Internal or External BGP
peering sessions.

"ESP Header Compression and Diet-ESP", Daniel Migault, Tobias Guggemos,

Carsten Bormann, David Schinazi, 2022-05-13,
<draft-mglt-ipsecme-diet-esp-08.txt>

With the use of encrypted ESP for secure IP communication, the

compression of IP payload is only possible with complex frameworks,
such as RObust Header Compression (ROHC). Such frameworks are too
complex for numerous use cases and especially for IoT scenarios,
which makes IPsec not being used here, although it offers
architectural benefits.

ESP Header Compression (EHC) defines a flexible framework to compress

communications protected with IPsec/ESP. Compression and
decompression is defined by EHC Rules orchestrated by EHC Strategies.
The necessary state is hold within the IPsec Security Association and
can be negotiated during key agreement, e.g. with IKEv2.

The document specifies the necessary parameters of the EHC Context to

allow compression of ESP and the most common included protocols, such
as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. It also
defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per
packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent
over a single TCP or UDP session.

"Just because it's an Internet-Draft doesn't mean anything... at all...",

Warren Kumari, 2022-05-09, <draft-wkumari-not-a-draft-16.txt>
 Anyone can publish an Internet Draft (ID). This doesn't mean that
the "IETF thinks" or that "the IETF is planning..." or anything
similar.

"PCAP Next Generation (pcapng) Capture File Format", Michael Tuexen, Fulvio
Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Eelco Chaudron, Michael
Richardson, 2022-07-29, <draft-tuexen-opsawg-pcapng-05.txt>

This document describes a format to record captured packets to a

file. This format is extensible; Wireshark can currently read and
write it, and libpcap can currently read some pcapng files.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the OPSAWG Working Group

mailing list (opsawg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/opsawg/.

Source for this draft and an issue tracker can be found at

https://github.com/pcapng/pcapng.

"Ideas for a Next Generation of the Stream Control Transmission Protocol

(SCTP)", Thomas Dreibholz, 2022-03-21,
<draft-dreibholz-tsvwg-sctp-nextgen-ideas-15.txt>

This document collects some ideas for a next generation of the Stream
Control Transmission Protocol (SCTP) for further discussion. It is a
result of lessons learned from more than one decade of SCTP
deployment.

"TCP SYN Extended Option Space Using an Out-of-Band Segment", Joseph Touch,
Ted Faber, 2022-04-15, <draft-touch-tcpm-tcp-syn-ext-opt-11.txt>

This document describes an experimental method to extend the option

space for connection parameters within the initial TCP SYN segment,
at the start of a TCP connection. This method effectively extends
the option space of an initial SYN by using an additional coupled
segment that is sent 'out-of-band'. It complements the proposed
Extended Data Offset (EDO) option that is applicable only after the
initial segment.

"Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen

Cheng, Peng Wang, Tong Duan, 2022-04-12,
<draft-lan-sfp-establishment-13.txt>

Service Function Chain architecture leads to more adaptive network

nodes. It allows splitting the network function into fine-grained
build blocks --- service function, and combining the network
functions into service function chain to formulate complicated
services. Further, the service function chain should be instantiated
by selecting the optimal instance from the candidates for each
service function in it. This document discusses the required
components during the instantiation of service function chain in the
network.

"SMTP Service Extension for Client Identity", William Storey, 2022-05-30,

<draft-storey-smtp-client-id-13.txt>
 This document defines an extension for the Simple Mail Transfer
Protocol (SMTP) called "CLIENTID" to provide a method for clients to
indicate an identity to the server.

This identity is an additional token that may be used for security

and/or informational purposes, and with it a server may optionally
apply heuristics using this token.

"PCEP extensions for Distribution of Link-State and TE Information", Dhruv

Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan
Mishra, Siva Sivabalan, 2022-03-05, <draft-dhodylee-pce-pcep-ls-23.txt>

In order to compute and provide optimal paths, a Path Computation

Elements (PCEs) require an accurate and timely Traffic Engineering
Database (TED). Traditionally, this TED has been obtained from a
link state (LS) routing protocol supporting the traffic engineering
extensions.

This document extends the Path Computation Element Communication

Protocol (PCEP) with Link-State and TE Information as an experimental
extension.

"Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan,

Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2022-04-12,
<draft-lanzhangwang-rtgwg-npmnrp-13.txt>

The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP)

bases on the idea of "hop-by-hop routing forwarding, multi-backup
next hop" and combines with the phenomena that water flows from
higher place to lower. NP-MNRP defines a metric named as node
potential, which is based on hop count and the actual link bandwidth,
and calculates multiple next-hops through the potential difference
between the nodes.

"Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix",

Naoki Matsuhira, 2022-04-03, <draft-matsuhira-me6e-fp-13.txt>

This document specifies Multiple Ethernet - IPv6 address mapping

encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP
makes expantion ethernet network over IPv6 backbone network with
encapsuation technoogy. And also, E6ME-FP can stack multiple
Ethernet networks. ME6E-FP work on own routing domain.

"Multiple Ethernet - IPv6 address mapping encapsulation - prefix

resolution", Naoki Matsuhira, 2022-04-03, <draft-matsuhira-me6e-pr-13.txt>

This document specifies Multiple Ethernet - IPv6 address mapping

encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR
makes expantion ethernet network over IPv6 backbone network with
encapsuation technoogy. And also, E6ME-PR can stack multiple
Ethernet networks. ME6E-PR work on non own routing domain.

"BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li,
Yanhe Fan, Mehmet Toy, Lei Liu, 2022-04-18,
<draft-wu-idr-bgp-segment-allocation-ext-09.txt>

This document describes extensions to the BGP for IDs allocation.

The IDs are SIDs for segment routing (SR), including SR for IPv6
 (SRv6). They are distributed to their domains if needed.

"A MILP Model to Solve the Problem of Loading Balance of Routing and
Wavelength Assignment for Optical Transport Networks", Shan Yin, Shanguo
Huang, Dajiang Wang, Xuan Wang, Yu Zhang, 2022-04-21,
<draft-yin-milp-rwa-otn-14.txt>

The RWA problem can be formulated as a Mixed-Integer linear program.

Load balancing is a key factor for the optical transport networks.
However, the existed approaches using mixed-Integer linear program to
solve the RWA problem are not perfect enough without considering the
load balancing of the networks.

This documentary provides a model of Mixed-Integer Linear Programming

to solve the problem of load balancing needed by routing and
wavelength assignment (RWA) process in optical transport networks.

"Mathematical Mesh 3.0 Part I: Architecture Guide", Phillip Hallam-Baker,

2022-04-20, <draft-hallambaker-mesh-architecture-20.txt>

The Mathematical Mesh is a Threshold Key Infrastructure that makes

computers easier to use by making them more secure. Application of
threshold cryptography to key generation and use enables users to
make use of public key cryptography across multiple devices with
minimal impact on the user experience.

This document provides an overview of the Mesh data structures,

protocols and examples of its use.

[Note to Readers] Discussion of this draft takes place on the

MATHMESH mailing list (mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-
architecture.html.

"Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira,

2022-04-03, <draft-matsuhira-m46a-12.txt>

This document specifies Multiple IPv4 - IPv6 mapped IPv6

address(M46A) spefification. M46A is IPv4 mapped IPv6 address with
plane ID. Unique allocation of plane id value enable IPv4 private
address unique in IPv6 address space. This address may use IPv4 over
IPv6 encapsulation and IPv4 - IPv6 translation.

"Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix

(M46E-FP)", Naoki Matsuhira, 2022-04-03, <draft-matsuhira-m46e-fp-12.txt>

This document specifies Multiple IPv4 - IPv6 address mapping

encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes
backbone network to IPv6 only. And also, M46E-FP can stack many IPv4
networks, i.e. the networks using same IPv4 (private) addresses,
without interdependence.

"Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution

(M46E-PR)", Naoki Matsuhira, 2022-04-03, <draft-matsuhira-m46e-pr-12.txt>

This document specifies M46E Prefix Resolution (M46E-PR)

 specification. M46E-PR connect IPv4 stub networks between IPv6
backbone network. And also, M46E-PR can stack many IPv4 networks,
i.e. the nwtworks using same IPv4 private addresses without
interdependence.

"Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator

(M46E-PT)", Naoki Matsuhira, 2022-04-03, <draft-matsuhira-m46e-pt-12.txt>

This document specifies Multiple IPv4 - IPv6 mapping encapsulation -

Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4
network plane by connecting M46E-FP domain and M46E-PR domain. M46E-
PT translate prefix part of M46E-FP address and M46E-PR address both
are IPv6 address. M46E-PT does not translate IPv4 packet which is
encapsulated, so transparency of IPv4 packet is not broken.

"Multiple IPv4 - IPv6 address mapping translator (M46T)", Naoki Matsuhira,

2022-04-03, <draft-matsuhira-m46t-12.txt>

This document specifies Multiple IPv4 - IPv6 address mapping

Translator (M46T) specification. M46T enable access to IPv4 only
host from IPv6 host. IPv4 host is identified as M46 address in IPv6
address space. The address assigned to IPv4 host may be global IPv4
address or private IPv4 address. M46T does not support access to
IPv6 host from IPv4 only host.

"Multiple IPv4 address and port number - IPv6 address mapping encapsulation
(M4P6E)", Naoki Matsuhira, 2022-04-03, <draft-matsuhira-m4p6e-12.txt>

This document specifies Multiple IPv4 address and port number - IPv6
address mapping encapulation (M4P6E) specification.

"Publishing Organization Boundaries in the DNS", John Levine, 2022-08-28,

<draft-levine-dbound-dns-06.txt>

The organization that manages a subtree in the DNS is often different

from the one that manages the tree above it. We describe an
architecture to publish in the DNS the boundaries between
organizations that can be adapted to various policy models and can be
queried with a small number of DNS lookups.

"Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira,

2022-04-03, <draft-matsuhira-mslb-12.txt>

This document specifies Multi-Stage Transparent Server Load Balancing

(MSLB) specification. MSLB make server load balancing over Layer3
network without packet header change at client and server. MSLB make
server load balancing with any protocol and protocol with encription
such as IPsec ESP, SSL/TLS.

"Conveying Vendor-Specific Information in the Path Computation Element

(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.", Cheng
Li, Haomian Zheng, Siva Sivabalan, Samuel Sidor, Zafar Ali, 2022-07-10,
<draft-dhody-pce-stateful-pce-vendor-15.txt>

A Stateful Path Computation Element (PCE) maintains information on

the current network state, including computed Label Switched Path
(LSPs), reserved resources within the network, and the pending path
computation requests. This information may then be considered when
computing new traffic engineered LSPs, and for the associated and the
 dependent LSPs, received from a Path Computation Client (PCC).

RFC 7470 defines a facility to carry vendor-specific information in

Path Computation Element Communication Protocol (PCEP).

This document extends this capability for the Stateful PCEP messages.

"Additional Considerations for UDP Encapsulation of Stream Control

Transmission Protocol (SCTP) Packets", Michael Tuexen, Randall Stewart,
2022-09-01, <draft-tuexen-tsvwg-sctp-udp-encaps-cons-06.txt>

RFC 6951 specifies the UDP encapsulation of SCTP packets. The

described handling of received packets requires the check of the
verification tag. However, RFC 6951 misses a specification of the
handling of received packets for which this check is not possible.

This document updates RFC 6951 by specifying the handling of received

packets for which the verification tag can not be checked.

"LISP Distinguished Name Encoding", Dino Farinacci, 2022-07-24,

<draft-farinacci-lisp-name-encoding-15.txt>

This draft defines how to use the AFI=17 Distinguished Names in LISP.

"LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2022-03-20,

<draft-farinacci-lisp-geo-13.txt>

This draft describes how Geo-Coordinates can be used in the LISP

Architecture and Protocols.

"Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira,

2022-04-03, <draft-matsuhira-me6a-12.txt>

This document specifies Multiple Ethernet - IPv6 mapped IPv6

address(ME6A) spefification. ME6A is Ethernet mapped IPv6 address
with plane ID. Unique allocation of plane id value enable duplicated
MAC address unique in IPv6 address space. This address may use
Ethernet over IPv6 encapsulation.

"ICANN TMCH functional specifications", Gustavo Ibarra, 2022-08-23,

<draft-ietf-regext-tmch-func-spec-15.txt>

This document describes the requirements, the architecture and the

interfaces between the ICANN Trademark Clearinghouse (TMCH) and
Domain Name Registries as well as between the ICANN TMCH and Domain
Name Registrars for the provisioning and management of domain names
during Sunrise and Trademark Claims Periods.

"OpenPGP Web Key Directory", Werner Koch, 2022-05-13,

<draft-koch-openpgp-webkey-service-14.txt>

This specification describes a service to locate OpenPGP keys by mail

address using a Web service and the HTTPS protocol. It also provides
a method for secure communication between the key owner and the mail
provider to publish and revoke the public key.

"Multi-site EVPN based VXLAN using Border Gateways", Rajesh Sharma, Ayan
Banerjee, Raghava Sivaramu, Ali Sajassi, 2022-06-23,
<draft-sharma-multi-site-evpn-04.txt>
 This document described the procedures for interconnecting two or
more Network Virtualization Overlays (NVOs) via NVO over IP-only
network. The solution interconnects Ethernet VPN network by using
NVO with Ethernet VPN (EVPN) to facilitate the interconnect in a
scalable fashion. The motivation is to support extension of Layer-2
and Layer-3, Unicast and Multicast, VPNs without having to rely on
typical Data Center Interconnect (DCI) technologies like MPLS/VPLS.
The requirements for the interconnect are similar to the ones
specified in RFC7209 [RFC7209] "Requirements for Ethernet VPN
(EVPN)". In particular, this document describes the difference of
the Gateways (GWs) procedure and incremental functionality from
[RFC9014] "Interconnect Solution for Ethernet VPN (EVPN) Overlay
Networks", which this solution is interoperable with. This document
is OBSOLETE and replaced by [SHARMA-BESS-MULTI-SITE].

"IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802
Parameters", Donald Eastlake, Joe Abley, Yizhou Li, 2022-08-07,
<draft-eastlake-rfc7042bis-09.txt>

Some IETF protocols make use of Ethernet frame formats and IEEE 802
parameters. This document discusses several aspects of such
parameters, their use in IETF protocols, specifies IANA
considerations for assignment of points under the IANA OUI
(Organizationally Unique Identifier), and provides some values for
use in documentation. This document obsoletes RFC 7042.

"Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei
Liu, Zhenqiang Li, 2022-07-11, <draft-chen-pce-h-discovery-11.txt>

This document presents extensions to the Path Computation Element

Communication Protocol (PCEP) for determining parent child relations
and exchanging the information between a parent and a child PCE in a
hierarchical PCE system.

"PCEP Link State Abstraction", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei
Liu, Zhenqiang Li, 2022-07-11, <draft-chen-pce-h-connect-access-11.txt>

This document presents extensions to the Path Computation Element

Communication Protocol (PCEP) for a child PCE to abstract its domain
information to its parent for supporting a hierarchical PCE system.

"Static PCEP Link State", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu,
Zhenqiang Li, 2022-07-11, <draft-chen-pce-pcc-ted-11.txt>

This document presents extensions to the Path Computation Element

Communication Protocol (PCEP) for a PCC to advertise the information
about the links without running IGP and for a PCE to build a TED
based on the information received.

"Using the Parallel NFS (pNFS) SCSI Layout with NVMe", Christoph Hellwig,
Chuck Lever, Sorin Faibish, David Black, 2022-07-08,
<draft-hellwig-nfsv4-scsi-layout-nvme-03.txt>

This document explains how to use the Parallel Network File System
(pNFS) SCSI Layout Type with transports using the NVMe or NVMe over
Fabrics protocol.

"PCEP Extension for Distribution of Link-State and TE Information for

Optical Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang,
Peter Park, Bin-Yeong Yoon, 2022-03-07,
<draft-lee-pce-pcep-ls-optical-11.txt>

In order to compute and provide optimal paths, Path Computation

Elements (PCEs) require an accurate and timely Traffic Engineering
Database (TED). Traditionally this Link State and TE information has
been obtained from a link state routing protocol (supporting traffic
engineering extensions).

An existing experimental document extends the Path Computation

Element Communication Protocol (PCEP) with Link-State and Traffic
Engineering (TE) Information. This document provides further
experimental extensions to collect Link-State and TE information for
optical networks.

"Fast HIP Host Mobility", Robert Moskowitz, Stuart Card, Adam Wiethuechter,
2022-06-17, <draft-moskowitz-hip-fast-mobility-04.txt>

This document describes mobility scenarios and how to aggressively

support them in HIP. The goal is minimum lag in the mobility event.

"Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense

Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the
application code of optical interface parameters in DWDM application",
Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze,
2022-07-01, <draft-ggalimbe-ccamp-flex-if-lmp-14.txt>

This experimental memo defines extensions to LMP(rfc4209) for

managing Optical parameters associated with Wavelength Division
Multiplexing (WDM) adding a set of parameters related to multicarrier
DWDM interfaces to be used in Spectrum Switched Optical Networks
(sson).

"BIER in BABEL", Zheng Zhang, Tony Przygienda, 2022-05-01,

<draft-zhang-bier-babel-extensions-07.txt>

BIER introduces a novel multicast architecture. It does not require

a signaling protocol to explicitly build multicast distribution
trees, nor does it require intermediate nodes to maintain any per-
flow state.

Babel defines a distance-vector routing protocol that operates in a

robust and efficient fashion both in wired as well as in wireless
mesh networks. This document defines a way to carry necessary BIER
signaling information in Babel.

"Encapsulating IPsec ESP in UDP for Load-balancing", Xiaohu Xu, Shraddha

Hegde, Paul Bottorff, Boris Pismenny, Dacheng Zhang, Liang Xia, Mahendra
Puttaswamy, 2022-03-07, <draft-xu-ipsecme-esp-in-udp-lb-09.txt>

IPsec Virtual Private Network (VPN) is widely used by enterprises to

interconnect their geographical dispersed branch office locations
across the Wide Area Network (WAN) or the Internet, especially in the
Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also
increasingly used by cloud providers to encrypt IP traffic traversing
data center networks and data center interconnect WANs so as to meet
the security and compliance requirements, especially in financial
cloud and governmental cloud environments. To fully utilize the
 bandwidth available in the data center network, the data center
interconnect WAN or the Internet, load balancing of IPsec traffic
over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG)
is much attractive to those enterprises and cloud providers. This
document defines a method to encapsulate IPsec Encapsulating Security
Payload (ESP) packets over UDP tunnels for improving load-balancing
of IPsec ESP traffic.

"Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff

Tantsura, 2022-07-06, <draft-lapukhov-bgp-ecmp-considerations-09.txt>

BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to

select a single best path among multiple paths available, known as
BGP best path selection. At the same time, it has become a common
practice to allow for "equal-cost multipath" (ECMP) selection and
programming of multiple next-hops in routing tables. This document
summarizes some common considerations for the ECMP logic when BGP is
used as the routing protocol, with the intent of providing common
reference for otherwise unstandardized set of features.

"Adaptive IPv4 Address Space", Abraham Chen, Ramamurthy Ati, Abhay

Karandikar, David Crowe, 2022-06-10,
<draft-chen-ati-adaptive-ipv4-address-space-11.txt>

This document describes a solution to the Internet address depletion

issue through the use of an existing Option mechanism that is part of
the original IPv4 protocol. This proposal, named EzIP (phonetic for
Easy IPv4), outlines the IPv4 public address pool expansion and the
Internet system architecture enhancement considerations. EzIP may
expand an IPv4 address by a factor of 256M without affecting the
existing IPv4 based Internet, or the current private networks. It is
in full conformance with the IPv4 protocol, and supports not only
both direct and private network connectivity, but also their
interoperability. EzIP deployments may coexist with existing Internet
traffic and IoTs (Internet of Things) operations without perturbing
their setups, while offering end-users the freedom to indepdently
choose which service. EzIP may be implemented as a software or
firmware enhancement to Internet edge routers or private network
routing gateways, wherever needed, or simply installed as an inline
adjunct hardware module between the two, enabling a seamless
introduction. The 256M case detailed here establishes a complete
spherical layer of an overlay of routers for interfacing between the
Internet fabic (core plus edge routers) and the end user premises or
IoTs. Incorporating caching proxy technology in the gateway, a fairly
large geographical region may enjoy address expansion based on as few
as one ordinary IPv4 public address utilizing IP packets with
degenerated EzIP header. If IPv4 public pool allocations were
reorganized, the assignable pool could be multiplied 512M fold or
even more. Enabling hierarchical address architecture which
facilitates both hierarchical and mesh routing, EzIP can provide
nearly the same order of magnitude of address pool resources as IPv6
while streamlining the administrative aspects of it. The basic EzIP
will immediately resolve the local IPv4 address shortage, while being
transparent to the rest of the Internet as a new parallel facility.
Under the Dual-Stack environment, these proposed interim facilities
will relieve the IPv4 address shortage issue, while affording IPv6
more time to reach maturity for providing the availability levels
required for delivering a long-term general service.
"Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue,
Richard Bradbury, Sam Hurst, 2022-07-04,
<draft-pardue-quic-http-mcast-11.txt>

This document specifies a profile of the QUIC protocol and the HTTP/3
mapping that facilitates the transfer of HTTP resources over
multicast IP using the QUIC transport as its framing and
packetisation layer. Compatibility with the QUIC protocol's syntax
and semantics is maintained as far as practical and additional
features are specified where this is not possible.

"Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon

Jeong, Yiwen Shen, JuneHee Kwon, Sandra Cespedes, 2022-07-25,
<draft-jeong-ipwave-vehicular-neighbor-discovery-14.txt>

This document specifies a Vehicular Neighbor Discovery (VND) as an

extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular
networks. An optimized Address Registration and a multihop Duplicate
Address Detection (DAD) mechanism are performed for having operation
efficiency and also saving both wireless bandwidth and vehicle
energy. In addition, three new ND options for prefix discovery,
service discovery, and mobility information report are defined to
announce the network prefixes and services inside a vehicle (i.e., a
vehicle's internal network).

"DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based

Vehicular Networks", Jaehoon Jeong, Yoseop Ahn, Sejun Lee, J., PARK,
2022-08-21, <draft-jeong-ipwave-iot-dns-autoconf-13.txt>

This document specifies an autoconfiguration scheme for device

discovery and service discovery in IP-based vehicular networks.
Through the device discovery, this document supports the global (or
local) DNS naming of Internet-of-Things (IoT) devices, such as
sensors, actuators, and in-vehicle units. By this scheme, the DNS
name of an IoT device can be autoconfigured with the device's model
information in wired and wireless target networks (e.g., vehicle,
road network, home, office, shopping mall, and smart grid). Through
the service discovery, IoT users (e.g., drivers, passengers, home
residents, and customers) in the Internet (or local network) can
easily identify each device for monitoring and remote-controlling it
in a target network.

"Signaling extensions for Media Channel sub-carriers configuration in

Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC)
Optical Line Systems.", Gabriele Galimberti, Domenico Fauci, Andrea
Zanardi, Lorenzo Galvagni, Julien Meuric, 2022-07-01,
<draft-ggalimbe-ccamp-flexigrid-carrier-label-13.txt>

This memo defines the signaling extensions for managing Spectrum

Switched Optical Network (SSON) parameters shared between the Client
and the Network and inside the Network in accordance to the model
described in [RFC7698]. The extensions are in accordance and
extending the parameters defined in ITU-T Recommendation
G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].

"OSPF Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy,
Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2022-07-11,
<draft-chen-ospf-ias-lk-09.txt>
 This document presents extensions to the Open Shortest Path First
(OSPF) for advertising broadcast inter-AS Traffic Engineering (TE)
links.

"ISIS Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy,
Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2022-07-11,
<draft-chen-isis-ias-lk-09.txt>

This document presents extensions to the ISIS protocol for

advertising broadcast inter-AS Traffic Engineering (TE) links.

"BGP Logical Link Discovery Protocol (LLDP) Peer Discovery", Acee Lindem,
Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu, 2022-07-29,
<draft-acee-idr-lldp-peer-discovery-13.txt>

Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is

implemented in networking equipment from many vendors. It is natural
for IETF protocols to avail this protocol for simple discovery tasks.
This document describes how BGP would use LLDP to discover directly
connected and 2-hop peers when peering is based on loopback
addresses.

"Short-Lived Certificates for Secure Telephone Identity", Jon Peterson,

2022-04-21, <draft-peterson-stir-certificates-shortlived-03.txt>

When certificates are used as credentials to attest the assignment of

ownership of telephone numbers, some mechanism is required to provide
certificate freshness. This document specifies short-lived
certificates as a means of guaranteeing certificate freshness for
secure telephone identity (STIR), in particular relying on the
Automated Certificate Management Environment (ACME) to allow signers
to acquire certifcates as needed.

"NEAT Sockets API", Thomas Dreibholz, 2022-08-23,

<draft-dreibholz-taps-neat-socketapi-11.txt>

This document describes a BSD Sockets-like API on top of the

callback-based NEAT User API. This facilitates porting existing
applications to use a subset of NEAT's functionality.

"Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks",

Zhiwei Yan, Jian Weng, Guanggang Geng, Jong-Hyouk Lee, Jaehoon Jeong,
2022-05-10, <draft-yan-ipwave-nd-10.txt>

For Cooperative Adaptive Cruise Control (C-ACC), platooning and other

typical use cases in Intelligent Transportation System (ITS), IPv6
communication between neighbor vehicles and between vehicle and
server pose the following two issues: 1) how to discover a neighbor
vehicle and the demanded service; and 2) how to discover the link-
layer address and other metadata of the neighbor vehicle and selected
server. This document presents a solution to these problems based on
DNS-SD/mDNS [RFC6762][RFC6763].

"Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils,

Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak,
2022-06-21, <draft-bashandy-rtgwg-segment-routing-uloop-13.txt>

This document presents a mechanism aimed at providing loop avoidance

in the case of IGP network convergence event. The solution relies on
 the temporary use of SR policies ensuring loop-freeness over the
post-convergence paths from the converging node to the destination.

"IPv6 is Classless", Nicolas Bourbaki, 2022-04-18,

<draft-bourbaki-6man-classless-ipv6-06.txt>

Over the history of IPv6, various classful address models have been
proposed, none of which has withstood the test of time. The last
remnant of IPv6 classful addressing is a rigid network interface
identifier boundary at /64. This document removes the fixed position
of that boundary for interface addressing.

"BFD in Demand Mode over Point-to-Point MPLS LSP", Greg Mirsky, 2022-03-07,
<draft-mirsky-bfd-mpls-demand-11.txt>

This document describes procedures for using Bidirectional Forwarding

Detection (BFD) in Demand mode to detect data plane failures in
Multiprotocol Label Switching (MPLS) point-to-point Label Switched
Paths.

"MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi,

Ferenc Fejes, Marius Georgescu, 2022-06-17, <draft-lencse-tsvwg-mpt-10.txt>

Although several contemporary IT devices have multiple network

interfaces, communication sessions are restricted to use only one of
them at a time due to the design of the TCP/IP protocol stack: the
communication endpoint is identified by an IP address and a TCP or
UDP port number. The simultaneous use of these multiple interfaces
for a communication session would improve user experience through
higher throughput and improved resilience to network failures.

MPT is a network layer multipath solution, which provides a tunnel

over multiple paths using the GRE-in-UDP specification, thus being
different from both MPTCP and Huawei's GRE Tunnel Bonding Protocol.

MPT can also be used as a router, routing the packets among several
networks between the tunnel endpoints, thus establishing a multipath
site-to-site connection.

The version of tunnel IP and the version of path IP are independent

from each other, therefore MPT can also be used for IPv6 transition
purposes.

"EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Ali

Sajassi, Gaurav Badoni, Priyanka Warade, S. Pasupula, Lukas Krattiger, John
Drake, Jorge Rabadan, 2022-09-02,
<draft-sajassi-bess-evpn-ip-aliasing-05.txt>

This document proposes an EVPN extension to allow several of its

multihoming functions, fast convergence and aliasing/backup path, to
be used in conjunction with inter-subnet forwarding.

"BBR Congestion Control", Neal Cardwell, Yuchung Cheng, Soheil Yeganeh, Ian
Swett, Van Jacobson, 2022-03-07,
<draft-cardwell-iccrg-bbr-congestion-control-02.txt>

This document specifies the BBR congestion control algorithm. BBR

("Bottleneck Bandwidth and Round-trip propagation time") uses recent
measurements of a transport connection's delivery rate, round-trip
 time, and packet loss rate to build an explicit model of the network
path. BBR then uses this model to control both how fast it sends
data and the maximum volume of data it allows in flight in the
network at any time. Relative to loss-based congestion control
algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers
substantially higher throughput for bottlenecks with shallow buffers
or random losses, and substantially lower queueing delays for
bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be
implemented in any transport protocol that supports packet-delivery
acknowledgment. Thus far, open source implementations are available
for TCP [RFC793] and QUIC [RFC9000]. This document specifies version
2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2.

"Delivery Rate Estimation", Yuchung Cheng, Neal Cardwell, Soheil Yeganeh,

Van Jacobson, 2022-03-07,
<draft-cheng-iccrg-delivery-rate-estimation-02.txt>

This document describes a generic algorithm for a transport protocol

sender to estimate the current delivery rate of its data. At a high
level, the algorithm estimates the rate at which the network
delivered the most recent flight of outbound data packets for a
single flow. In addition, it tracks whether the rate sample was
application-limited, meaning the transmission rate was limited by the
sending application rather than the congestion control algorithm.
This algorithm can be implemented in any transport protocol that
supports packet-delivery acknowledgment (thus far, open source
implementations are available for TCP [RFC793] and QUIC [RFC9000]).

"LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma
Chunduri, 2022-03-20, <draft-farinacci-lisp-mobile-network-14.txt>

This specification describes how the LISP architecture and protocols

can be used in a LTE/5G mobile network to support session survivable
EID mobility. A recommendation is provided to SDOs on how to
integrate LISP into the mobile network.

"Reassignment of System Ports to the IESG", Mirja Kuehlewind, Sabrina

Tanamal, 2020-02-10, <draft-kuehlewind-system-ports-05.txt>

In the IANA Service Name and Transport Protocol Port Number Registry,
a large number of System Ports are currently assigned to individuals
or companies who have registered the port for the use with a certain
protocol before RFC6335 was published. For some of these ports, RFCs
exist that describe the respective protocol; for others, RFCs are
under development that define, re-define, or assign the protocol used
for the respective port, such as in case of so-far unused UDP ports
that have been registered together with the respective TCP port. In
these cases the IESG has the change control about the protocol used
on the port (as described in the corresponding RFC) but change
control for the port allocation iis designated to others. Under
existing operational procedures, this means the original assignee
needs to be involved in chnage to the port assignment. As it is not
always possible to get in touch with the original assignee,
particularly because of out-dated contact information, this current
practice of handling historical allocation of System Ports does not
scale well on a case-by-case basis. To address this, this document
instructs IANA to perform actions with the goal to reassign System
Ports to the IESG that were assigned to individuals prior to the
publication of RFC6335, where appropriate.
"IPv6 Source Routing for ultralow Latency", Andreas Foglar, Mike Parker,
Theodoros Rokkas, Mikhail Khokhlov, 2022-05-24,
<draft-foglar-ipv6-ull-routing-11.txt>

This Internet-Draft describes a hierarchical addressing scheme

for IPv6, intentionally very much simplified to allow for ultralow
latency source routing experimentation using simple forwarding
nodes. Research groups evaluate achievable latency reduction for
special applications such as radio access networks, industrial net-
works or other networks requiring very low latency.

"Simple Group Keying Protocol (SGKP)", Donald Eastlake, Dacheng Zhang,

2022-05-23, <draft-ietf-trill-group-keying-10.txt>

This document specifies a simple general group keying protocol that

provides for the distribution of shared secret keys to group members
and the management of such keys. It assumes that secure pairwise keys
can be created between any two group members.

"Registration Procedures for Private Enterprise Numbers (PENs)", Amanda

Baber, Paul Hoffman, 2022-08-15, <draft-pti-pen-registration-07.txt>

This document describes how Private Enterprise Numbers (PENs) are

registered by IANA. It shows how to request a new PEN and how to
request an update to a current PEN. It also gives a brief overview
of PEN uses.

"BlackBerry's Elliptic Curve 2y^2=x^3+x over Field Size 8^91+5", Daniel

Brown, 2022-03-21, <draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-09.txt>

Multi-curve elliptic curve cryptography with curve

2y^2=x^3+x/GF(8^91+5) hedges a risk of new curve-specific attacks.
This curve features: isomorphism to Miller's curve from 1985; low
Kolmogorov complexity (little room for embedded weaknesses of
Gordon, Young-Yung, or Teske); similarity to a Bitcoin curve;
Montgomery form; complex multiplication by i
(Gallant-Lambert-Vanstone); prime field; easy reduction, inversion,
Legendre symbol, and square root; five 64-bit-word field arithmetic;
string-as-point encoding; and 34-byte keys.

This document aims to contribute to multi-curve Elliptic Curve

Cryptography by describing how to use this curve for elliptic curve
Diffie--Hellman. Reports of experience and experiments with this
curve are encouraged to better understand its security and utility.

This document was produced outside the IETF and is not an IETF
standard. Publication of this document does not imply endorsement
by the IETF of the curve described in this document.

"A YANG Data Model for Client-layer Tunnel", Haomian Zheng, Aihua Guo,
Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2022-03-07,
<draft-zheng-ccamp-client-tunnel-yang-10.txt>

A transport network is a server-layer network to provide connectivity

services to its client. In this draft the tunnel of client is
described, with the definition of client tunnel YANG model.

"Internet Key Exchange version 2 (IKEv2) extension for the ESP Header
Compression (EHC) Strategy", Daniel Migault, Tobias Guggemos, David
Schinazi, 2022-05-13, <draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt>

ESP Header Compression (EHC) reduces the ESP overhead by compressing

ESP fields. Compression results from a coordination of various EHC
Rules designed as EHC Strategies. An EHC Strategy may require to be
configured with some configuration parameters.

When a Security Association (SA) is enabling EHC, the two peers need
to agree which EHC Strategy is applied as well as its associated
configuration parameters.

This document describes an extension of IKEv2 that enables two peers

to agree on a specific EHC Strategy as well as its associated
configuration parameters.

"I2NSF on the NFV Reference Architecture", Hyunsik Yang, Sun Kj, Younghan
Kim, Jaehoon Jeong, 2022-05-20, <draft-yang-i2nsf-nfv-architecture-08.txt>

This document describes the integration of Interface to Network

Security Functions (I2NSF) Framework into the Network Functions
Virtualization (NFV) Reference Model. This document explains how the
components and interfaces in the I2NSF Framework can be placed in the
NFV reference architecture, and also explains the procedures of the
lifecycle management of Network Security Functions (NSFs) according
to a user's security policy specification in the I2NSF framework on
the NFV system.

"YANG Model for QoS Operational Parameters", Aseem Choudhary, Ing-Wher

Chen, 2022-03-07, <draft-asechoud-rtgwg-qos-oper-model-10.txt>

This document describes a YANG model for Quality of Service (QoS)

operational parameters.

"DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling

Protocol (GRASP)", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet,
Michael Behringer, 2022-03-04, <draft-eckert-anima-grasp-dnssd-03.txt>

DNS Service Discovery (DNS-SD) defines a framework for applications

to announce and discover services. This includes service names,
service instance names, common parameters for selecting a service
instance (weight or priority) as well as other service-specific
parameters. For the specific case of autonomic networks, GeneRic
Autonomic Signaling Protocol (GRASP) intends to be used for service
discovery in addition to the setup of basic connectivity.
Reinventing advanced service discovery for GRASP with a similar set
of features as DNS-SD would result in duplicated work. To avoid
that, this document defines how to use GRASP to announce and discover
services relying upon DNS-SD features while maintaining the intended
simplicity of GRASP. To that aim, the document defines name
discovery and schemes for reusable elements in GRASP objectives.

"Ground-Based LISP for the Aeronautical Telecommunications Network",

Bernhard Haindl, Manfred Lindner, Victor Moreno, Marc Portoles-Comeras,
Fabio Maino, Balaji Venkatachalapathy, 2022-03-22,
<draft-haindl-lisp-gb-atn-07.txt>

This document describes the use of the LISP architecture and

protocols to address the requirements of the worldwide Aeronautical
 Telecommunications Network with Internet Protocol Services, as
articulated by the International Civil Aviation Organization.

The ground-based LISP overlay provides mobility and multi-homing

services to the IPv6 networks hosted on commercial aircrafts, to
support Air Traffic Management communications with Air Traffic
Controllers and Air Operation Controllers. The proposed architecture
doesn't require support for LISP protocol in the airborne routers,
and can be easily deployed over existing ground infrastructures.

"HTTP Live Streaming 2nd Edition", Roger Pantos, 2022-05-11,

<draft-pantos-hls-rfc8216bis-11.txt>

This document obsoletes RFC 8216. It describes a protocol for

transferring unbounded streams of multimedia data. It specifies the
data format of the files and the actions to be taken by the server
(sender) and the clients (receivers) of the streams. It describes
version 10 of this protocol.

"A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin

Cantrell, 2022-08-15, <draft-farinacci-lisp-decent-10.txt>

This draft describes how the LISP mapping system designed to be

distributed for scale can also be decentralized for management and
trust.

"IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2022-07-30,

<draft-tang-ipv4plus-09.txt>

This document specifies version 4+ of the Internet Protocol

(IPv4+). IPv4 is very successful,simple and elegant.
continuation and expansion of the IPv4 is necessary. Existing
systems, devices only need to upgrade the software to support
IPv4+, without the need to update new hardwares,saving
investment costs. Ipv4+ is also an interstellar Protocol,
so the Internet will evolve into a star Internet.

"Hybrid Two-Step Performance Measurement Method", Greg Mirsky, Wang

Lingqiang, Guo Zhui, Haoyu Song, Pascal Thubert, 2022-04-25,
<draft-mirsky-ippm-hybrid-two-step-13.txt>

Development of, and advancements in, automation of network operations

brought new requirements for measurement methodology. Among them is
the ability to collect instant network state as the packet being
processed by the networking elements along its path through the
domain. This document introduces a new hybrid measurement method,
referred to as hybrid two-step, as it separates the act of measuring
and/or calculating the performance metric from the act of collecting
and transporting network state.

"Hierarchy of IP Controllers (HIC)", Zhenbin Li, Dhruv Dhody, Huaimo Chen,

2022-03-07, <draft-li-teas-hierarchy-ip-controllers-09.txt>

This document describes the interactions between various IP

controllers in a hierarchical fashion to provide various IP services.
It describes how the Abstraction and Control of Traffic Engineered
Networks (ACTN) framework is applied to the Hierarchy of IP
controllers (HIC) as well as document the interactions with other
protocols like BGP, Path Computation Element Communication Protocol
 (PCEP) to provide end to end dynamic services spanning multiple
domains and controllers (e.g. Layer 3 Virtual Private Network
(L3VPN), Seamless MPLS etc).

"Blockchain Transaction Protocol for Constraint Nodes", Pascal Urien,

2022-06-18, <draft-urien-core-blockchain-transaction-protocol-08.txt>

The goal of the blockchain transaction protocol for constraint nodes

is to enable the generation of blockchain transactions by constraint
nodes, according to the following principles:
- transactions are triggered by Provisioning-Messages that include
the needed blockchain parameters.
- binary encoded transactions are returned in Transaction-Messages,
which include sensors/actuators data. Constraint nodes, associated
with blockchain addresses, compute the transaction signature.

"BGP Extended Community for Identifying the Target Nodes", Jie Dong,
Shunwan Zhuang, Gunter Van de Velde, 2022-07-11,
<draft-dong-idr-node-target-ext-comm-05.txt>

BGP has been used to distribute different types of routing and policy
information. In some cases, the information distributed may be only
intended for one or a particular group of BGP nodes in the network.
Currently BGP does not have a generic mechanism of designating the
target nodes of the routing information. This document defines a new
type of BGP Extended Community called "Node Target". The mechanism
of using the Node Target Extended Community to steer BGP route
distribution to particular BGP nodes is specified.

"EVPN All Active Usage Enhancement", Donald Eastlake, Zhenbin Li, Haibo
Wang, Russ White, 2022-06-08,
<draft-eastlake-bess-enhance-evpn-all-active-09.txt>

A principal feature of EVPN is the ability to support multihoming

from a customer equipment (CE) to multiple provider edge equipment
(PE) active with all-active links. This draft specifies an
improvement to load balancing such links.

"Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for

Traffic Engineering", Zafar Ali, Ketan Talaulikar, Clarence Filsfils,
Nagendra Nainar, Carlos Pignataro, 2022-05-08,
<draft-ali-spring-bfd-sr-policy-09.txt>

Segment Routing (SR) allows a headend node to steer a packet flow

along any path using a segment list which is referred to as a SR
Policy. Intermediate per-flow states are eliminated thanks to source
routing. The header of a packet steered in an SR Policy is augmented
with the ordered list of segments associated with that SR Policy.
Bidirectional Forwarding Detection (BFD) is used to monitor different
kinds of paths between node. BFD mechanisms can be also used to
monitor the availability of the path indicated by a SR Policy and to
detect any failures. Seamless BFD (S-BFD) extensions provide a
simplified mechanism which is suitable for monitoring of paths that
are setup dynamically and on a large scale.

This document describes the use of Seamless BFD (S-BFD) mechanism to

monitor the SR Policies that are used for Traffic Engineering (TE) in
SR deployments.
"EVPN VXLAN Bypass VTEP", Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ
White, 2022-06-04, <draft-eastlake-bess-evpn-vxlan-bypass-vtep-10.txt>

A principal feature of EVPN is the ability to support multihoming

from a customer equipment (CE) to multiple provider edge equipment
(PE) with all-active links. This draft specifies a mechanism to
simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active
reliability.

"Origin Validation Policy Considerations for Dropping Invalid Routes",

Kotikalapudi Sriram, Oliver Borchert, Doug Montgomery, 2022-05-29,
<draft-sriram-sidrops-drop-invalid-policy-09.txt>

Deployment of Resource Public Key Infrastructure (RPKI) and Route

Origin Authorizations (ROAs) is expected to occur gradually over
several or many years. During the incremental deployment period,
network operators would wish to have a meaningful policy for dropping
Invalid routes. Their goal is to balance (A) dropping Invalid routes
so hijacked routes can be eliminated, versus (B) tolerance for
missing or erroneously created ROAs for customer prefixes. This
document considers a Drop Invalid if Still Routable (DISR) policy
that is based on these considerations. The key principle of DISR
policy is that an Invalid route can be dropped if a Valid or NotFound
route exists for a subsuming less specific prefix.

"Traffic Accounting in Segment Routing Networks", Zafar Ali, Clarence

Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert
Raszuk, Stephane Litkowski, Dan Voyer, Rick Morton, 2022-05-08,
<draft-ali-spring-sr-traffic-accounting-07.txt>

Capacity planning is the continuous art of forecasting traffic

load and failures to evolve the network topology, its capacity,
and its routing to meet a defined Service-Level Agreement (SLA).
This document takes a holistic view of network capacity planning
and identifies the role of traffic accounting in network
operation and capacity planning, without creating any additional
states in the SR fabric.

"ICANN Registrar Interfaces", Gustavo Ibarra, Eduardo Alvarez, 2022-03-22,

<draft-icann-registrar-interfaces-08.txt>

This document describes the interfaces provided by ICANN to

Registrars and Data Escrow Agents to fulfill the data escrow
requirements of the Registrar Accreditation Agreement and the
Registrar Data Escrow Specifications.

"Optimization of RWA Problem through OSNR", Shan Yin, Shanguo Huang, Shuang
Zhou, Xiangkai Meng, Rong Ma, 2022-05-12, <draft-yin-rwa-osnr-10.txt>

This documentary provides a kind of routing optimization method. In

the basic of RWA solution method, both the output power of the route
and the OSNR value of the optical signal noise ratio are considered.
The selected optimal route has a lower bit error rate and the whole
communication network performance is improved.

"PASETO (Platform-Agnostic SEcurity TOkens)", Robyn Terjesen, Steven

Haussmann, Scott Arciszewski, 2022-05-24, <draft-paragon-paseto-rfc-01.txt>

Platform-Agnostic SEcurity TOkens (PASETOs) provide a

 cryptographically secure, compact, and URL-safe representation of
claims that may be transferred between two parties. The claims are
encoded in JavaScript Object Notation (JSON), version-tagged, and
either encrypted using shared-key cryptography or signed using
public-key cryptography.

"SR Policy Implementation and Deployment Considerations", Clarence

Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes,
2022-04-24, <draft-filsfils-spring-sr-policy-considerations-09.txt>

Segment Routing (SR) allows a headend node to steer a packet flow

along any path. Intermediate per-flow states are eliminated thanks
to source routing. SR Policy framework enables the instantiation and
the management of necessary state on the headend node for flows along
a source routed paths using an ordered list of segments associated
with their specific SR Policies. This document describes some of the
implementation and deployment aspects that are useful for
operationalizing the SR Policy architecture.

"RSCA method with Dividing Frequency Slots Area in Space Division

Multiplexing Elastic Optical Networks", Shanguo Huang, Shan Yin, Shuang
Zhou, 2022-05-12, <draft-huang-rsca-sdm-eon-08.txt>

This documentary provides a routing, spectrum and core assignment

method with the dividing frequency slots area for space division
multiplexing elastic optical networks. This effective RSCA method to
solve this problem better. The proposed method utilizes the Frequency
Slots Area (FSA) concept and first-last fit policy of frequency slots
assignment to have less spectrum fragments, lower crosstalk, smaller
traffic blocking probability and higher spectrum resource utilization.

"IMAP Service Extension for Client Identity", Deion Yu, 2022-05-24,

<draft-yu-imap-client-id-08.txt>

This document defines an Internet Message Access Protocol (IMAP)

service extension called "CLIENTID" which provides a method for
clients to indicate an identity to the server.

This identity is an additional token that may be used for security

and/or informational purposes, and with it a server may optionally
apply heuristics using this token.

"The IPv6 Tunnel Payload Forwarding (TPF) Option", Ron Bonica, Yuji Kamite,
Luay Jalil, Yifeng Zhou, Gang Chen, 2022-07-27,
<draft-bonica-6man-vpn-dest-opt-18.txt>

This document explains how IPv6 options can be used in IPv6 tunnels.
It also defines the IPv6 Tunnel Payload Forwarding (TPF) option.

"DNS Web Service Discovery", Phillip Hallam-Baker, 2022-04-20,

<draft-hallambaker-web-service-discovery-07.txt>

This document describes a standardized approach to discovering Web

Service Endpoints from a DNS name. Services are advertised using the
DNS SRV and TXT records and the HTTP Well Known Service conventions.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-web-service-
discovery.html.
"Preferred Path Routing (PPR) in IS-IS", Uma Chunduri, Richard Li, Russ
White, Luis Contreras, Jeff Tantsura, Yingzhen Qu, 2022-07-11,
<draft-chunduri-lsr-isis-preferred-path-routing-08.txt>

This document specifies a Preferred Path Routing (PPR), a routing

protocol mechanism to simplify the path description using IS-IS
protocol. PPR builds on existing encapsulation to add the path
identity to the packet and supports further extensions along the
preferred paths. PPR aims to provide path steering, services and
support further extensions along the paths. Preferred path routing
is achieved through the addition of path descriptions to the IS-IS
advertised prefixes, and mapping those to a PPR data-plane
identifier.

"Path Computation Element Communication Protocol (PCEP) extension to

advertise the PCE Controlled Identifier Space", Cheng Li, Hang Shi, Aijun
Wang, Weiqiang Cheng, Chao Zhou, 2022-07-24,
<draft-li-pce-controlled-id-space-12.txt>

The Path Computation Element Communication Protocol (PCEP) provides a

mechanisms for the Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. Furthermore, PCE can be used for computing paths
in the SR networks.

Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a
model where the PCC delegates control over one or more locally
configured LSPs to the PCE. Further, stateful PCE could also create
and remove PCE-initiated LSPs by itself. A PCE-based Central
Controller (PCECC) simplify the processing of a distributed control
plane by integrating with elements of Software-Defined Networking
(SDN).

In some use cases, such as PCECC or Binding Segment Identifier (SID)

for Segment Routing (SR), there are requirements for a stateful PCE
to make allocation of labels, SIDs, etc. These use cases require PCE
aware of various identifier spaces from where to make allocations on
behalf of a PCC. This document describes a generic mechanism for a
PCC to inform the PCE of the an identifier space set aside for the
PCE control via PCEP. The identifier could be an MPLS label, a SID
or any other to-be-defined identifier that can be allocated and
managed by the PCE.

"IGP Extensions for Scalable Segment Routing based Enhanced VPN", Jie Dong,
Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Stewart Bryant, 2022-07-11,
<draft-dong-lsr-sr-enhanced-vpn-08.txt>

Enhanced VPN (VPN+) aims to provide enhanced VPN services to support

some application's needs of enhanced isolation and stringent
performance requirements. VPN+ requires integration between the
overlay VPN connectivity and the characteristics provided by the
underlay network. A Virtual Transport Network (VTN) is a virtual
underlay network which has a customized network topology and a set of
network resources allocated from the physical network. A VTN could
be used to support one or a group of VPN+ services. In the context
of network slicing, a VTN could be instantiated as a network resource
 partition (NRP).

This document specifies the IGP mechanisms with necessary extensions

to advertise the associated topology and resource attributes for
scalable Segment Routing (SR) based NRPs. Each NRP can have a
customized topology and a set of network resources allocated from the
physical network. Multiple NRPs may shared the same topology, and
multiple NRPs may share the same set of network resources on some
network segments. This allows flexible combination of the network
topology and network resource attributes to build a relatively large
number of NRPs with a relatively small number of logical topologies.
A group of resource-aware SIDs and SRv6 Locators can be assigned to
each NRP. The proposed mechanism is applicable to both Segment
Routing with MPLS data plane (SR-MPLS) and Segment Routing with IPv6
data plane (SRv6). This document also describes the mechanism of
using dedicated NRP ID in the data plane instead of the per-NRP
resource-aware SIDs and SRv6 Locators to further reduce the control
plane and data plane overhead of maintaining a large number of NRPs.

"Multi-Site Solution for Ethernet VPN (EVPN) Overlay", Lukas Krattiger,

Ayan Banerjee, Ali Sajassi, Rajesh Sharma, Raghava Sivaramu, 2022-05-12,
<draft-sharma-bess-multi-site-evpn-02.txt>

This document describes the procedures for interconnecting two or

more Network Virtualization Overlays (NVOs) via NVO over IP-only
network. The solution interconnects Ethernet VPN network by using NVO
with Ethernet VPN (EVPN) to facilitate the interconnect in a scalable
fashion. The motivation is to support extension of Layer-2 and Layer-
3, Unicast & Multicast, VPNs without having to rely on typical Data
Center Interconnect (DCI) technologies like MPLS/VPLS. The
requirements for the interconnect are similar to the ones specified
in [RFC7209] "Requirements for Ethernet VPN (EVPN)". In particular,
this document describes the difference of the Gateways (GWs)
procedure and incremental functionality from [RFC9014] "Interconnect
Solution for Ethernet VPN (EVPN) Overlay Networks", which this
solution is interoperable to. This document updates and replaces all
previous version of [SHARMA-MULTI-SITE].

"LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark,

2022-05-09, <draft-farinacci-lisp-telemetry-08.txt>

This draft specs a JSON formatted RLOC-record for telemetry data

which decapsulating xTRs include in RLOC-probe Map Reply messages.

"Guidelines for Security Policy Translation in Interface to Network

Security Functions", Jaehoon Jeong, Patrick Lingga, Jinhyuk Yang,
jeonghyeon kim, 2022-04-28,
<draft-yang-i2nsf-security-policy-translation-11.txt>

This document proposes the guidelines for security policy translation

in Interface to Network Security Functions (I2NSF) Framework. When
I2NSF User delivers a high-level security policy for a security
service, Security Policy Translator in Security Controller translates
it into a low-level security policy for Network Security Functions
(NSFs). For this security policy translation, this document
specifies the relation between a high-level security policy based on
the Consumer-Facing Interface YANG data model and a low-level
security policy based on the NSF-Facing Interface YANG data model.
Also, it describes an architecture of a security policy translator
 along with an NSF database, and the process of security policy
translation with the NSF database.

"Design Discussion of Route Leaks Solution Methods", Kotikalapudi Sriram,

2022-03-07, <draft-sriram-idr-route-leak-solution-discussion-07.txt>

This document captures the design rationale of the route leaks

solution document (see draft-ietf-idr-route-leak-detection-
mitigation, draft-ietf-grow-route-leak-detection-mitigation). The
designers needed to balance many competing factors, and this document
provides insights into the design questions and their resolution.

"LURK Extension version 1 for (D)TLS 1.3 Authentication", Daniel Migault,

2022-08-24, <draft-mglt-lurk-tls13-06.txt>

This document defines a LURK extension for TLS 1.3 [RFC8446], with
the specification of a Cryptographic Service (CS) for both the TLS
client and the TLS server.

"Support MPLS Network Actions using Post-Stack Extension Headers", Haoyu

Song, Zhenbin Li, Tianran Zhou, Loa Andersson, Zhaohui Zhang, Rakesh
Gandhi, Jaganbabu Rajamanickam, Jisu Bhattacharya, 2022-09-01,
<draft-song-mpls-extension-header-10.txt>

Motivated by the need to support multiple in-network services and

functions in an MPLS network (a.k.a. MPLS Network Actions (MNA)),
this document describes a generic and extensible method to
encapsulate MNA instructions as well as possible ancillary data in an
MPLS packet. All the post-stack MNAs are encapsulated in a structure
called Post-stack MNA Header (PAH). A PAH is composed of a common
header plus a chain of extension headers; each extension header is a
container for an MNA. The encapsulation method allows chaining
multiple post-stack extension headers and provides the means to
enable fast access to them as well as the original upper layer
headers. This document confines to the solution of PAH encoding and
leaves the specification of PAH indicator to the overall MNA
solution. We show how PAH can be used to support several new MNAs as
a generic post-stack mechanism.

"Flexible Session Protocol", Jun-an Gao, 2022-04-18,

<draft-gao-flexible-session-protocol-08.txt>

FSP is a connection-oriented transport layer protocol that provides

mobility and multihoming support by introducing the concept of 'upper
layer thread ID', which is associated with some shared secret that is
applied with some secure hash or authenticated encryption algorithm
to protect authenticity of the origin of the FSP packets. It is able
to provide following services to the upper layer application:

o Stream-oriented send-receive with native message boundary

o Flexibility to exploit authenticated encryption
o On-the-wire compression
o Light-weight session management

"The Multihash Data Format", Juan Benet, Manu Sporny, 2022-08-20,

<draft-multiformats-multihash-05.txt>

Cryptographic hash functions often have multiple output sizes and

encodings. This variability makes it difficult for applications to
 examine a series of bytes and determine which hash function produced
them. Multihash is a universal data format for encoding outputs from
hash functions. It is useful to write applications that can
simultaneously support different hash function outputs as well as
upgrade their use of hashes over time; Multihash is intended to
address these needs.

"Access Extensions for ANCP", Hongyu Li, Thomas Haag, Birgit Witschurke,
2022-03-31, <draft-lihawi-ancp-protocol-access-extension-08.txt>

The purpose of this document is to specify extensions to ANCP (Access

Node Control Protocol) (RFC6320) to support PON as described in
RFC6934 and some other DSL Technologies including G.fast. This
document updates RFC6320 by modifications to terminologies, flows and
specifying new TLV types.

This document updates RFC6320 by modifications to terminologies,

flows and specifying new TLV types.

"Discovery of OSCORE Groups with the CoRE Resource Directory", Marco

Tiloca, Christian Amsuess, Peter van der Stok, 2022-03-07,
<draft-tiloca-core-oscore-discovery-11.txt>

Group communication over the Constrained Application Protocol (CoAP)

can be secured by means of Group Object Security for Constrained
RESTful Environments (Group OSCORE). At deployment time, devices may
not know the exact security groups to join, the respective Group
Manager, or other information required to perform the joining
process. This document describes how a CoAP endpoint can use
descriptions and links of resources registered at the CoRE Resource
Directory to discover security groups and to acquire information for
joining them through the respective Group Manager. A given security
group may protect multiple application groups, which are separately
announced in the Resource Directory as sets of endpoints sharing a
pool of resources. This approach is consistent with, but not limited
to, the joining of security groups based on the ACE framework for
Authentication and Authorization in constrained environments.

"Inband Flow Analyzer", Jai Kumar, Surendra Anubolu, John Lemon, Rajeev
Manur, Hugh Holbrook, Anoop Ghanwani, Dezhong Cai, Heidi Ou, Yizhou Li,
Xiaojun Wang, 2022-08-12, <draft-kumar-ippm-ifa-05.txt>

Inband Flow Analyzer (IFA) records flow specific information from an

end station and/or switches across a network. This document
discusses the method to collect data on a per hop basis across a
network and perform localized or end to end analytics operations on
the data. This document also describes a transport-agnostic header
definition that may be used for tunneled and non-tunneled flows
alike.

"Marking-based Direct Export for On-path Telemetry", Haoyu Song, Greg

Mirsky, Clarence Filsfils, Ahmed Abdelsalam, Tianran Zhou, Zhenbin Li,
Thomas Graf, Gyan Mishra, Jongyoon Shin, Kyungtae Lee, 2022-08-16,
<draft-song-ippm-postcard-based-telemetry-13.txt>

The document describes a packet-marking variation of the IOAM DEX

option, referred to as PBT-M (i.e., Postcard-Based Telemetry by
Marking). Similar to IOAM DEX, PBT-M does not carry the telemetry
data in user packets but send the telemetry data through a dedicated
 packet. Unlike IOAM DEX, PBT-M does not require an extra instruction
header. However, PBT-M raises some unique issues that need to be
considered. This document formally describes the high level scheme
and cover the common requirements and issues when applying PBT-M in
different networks. PBT-M is complementary to the other on-path
telemetry schemes such as IOAM trace and E2E options.

"Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola,

Yisong Liu, Mauro Cociglio, Shinyoung Lee, Weidong Li, 2022-08-29,
<draft-zhou-ippm-enhanced-alternate-marking-11.txt>

This document extends the IPv6 Alternate Marking Option to provide

enhanced capabilities and allow advanced functionalities. With this
extension, it can be possible to perform thicker packet loss
measurements and more dense delay measurements with no limitation for
the number of concurrent flows under monitoring.

"Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs",

Mallory Knodel, Niels ten Oever, 2022-07-11,
<draft-knodel-terminology-10.txt>

This document argues for more inclusive language conventions

sometimes used by RFC authors and the RFC Production Centre in
Internet-Drafts that are work in progress, and in new RFCs that may
be published in any of the RFC series, in order to foster greater
knowledge transfer and improve diversity of participation in the
IETF.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6
(SRv6) Segment Identifier (SID) Allocation and Distribution.", Zhenbin Li,
Shuping Peng, Xuesong Geng, Mahendra Negi, 2022-07-10,
<draft-dhody-pce-pcep-extension-pce-controller-srv6-09.txt>

The Path Computation Element (PCE) is a core component of Software-

Defined Networking (SDN) systems.

A PCE-based Central Controller (PCECC) can simplify the processing of

a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. This document specifies
the procedures and Path Computation Element Communication Protocol
(PCEP) extensions when a PCE-based controller is also responsible for
configuring the forwarding actions on the routers, in addition to
computing the paths for packet flows in the for Segment Routing (SR)
in IPv6 (SRv6) network and telling the edge routers what instructions
to attach to packets as they enter the network. PCECC is further
enhanced for SRv6 SID (Segment Identifier) allocation and
distribution.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP)
LSPs", Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi, 2022-07-10,
<draft-dhody-pce-pcep-extension-pce-controller-p2mp-09.txt>

The Path Computation Element (PCE) is a core component of Software-

Defined Networking (SDN) systems.

The PCE has been identified as an appropriate technology for the

determination of the paths of point-to-multipoint (P2MP) TE Label
 Switched Paths (LSPs).

A PCE-based Central Controller (PCECC) can simplify the processing of

a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the P2MP LSP can
be calculated/set up/initiated and the label-forwarding entries can
also be downloaded through a centralized PCE server to each network
device along the P2MP path, while leveraging the existing PCE
technologies as much as possible.

This document specifies the procedures and Path Computation Element

Communication Protocol (PCEP) extensions for using the PCE as the
central controller for provisioning labels along the path of the
static P2MP LSP.

"Architecture for Use of BGP as Central Controller", Yujia Luo, Liang Ou,
Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li,
2022-08-15, <draft-cth-rtgwg-bgp-control-09.txt>

BGP is a core part of a network including Software-Defined Networking

(SDN) system. It has the traffic engineering information on the
network topology and can compute optimal paths for a given traffic
flow across the network.

This document describes some reference architectures for BGP as a

central controller. A BGP-based central controller can simplify the
operations on the network and use network resources efficiently for
providing services with high quality.

"SR-TE Path Midpoint Restoration", Zhibo Hu, Huaimo Chen, Junda Yao, Chris
Bowers, Yongqing Zhu, Yisong Liu, 2022-08-18,
<draft-hu-spring-segment-routing-proxy-forwarding-20.txt>

Segment Routing Traffic Engineering (SR-TE) supports explicit paths

using segment lists containing adjacency-SIDs, node-SIDs and binding-
SIDs. The current SR FRR such as TI-LFA provides fast re-route
protection for the failure of a node along a SR-TE path by the direct
neighbor or say point of local repair (PLR) to the failure. However,
once the IGP converges, the SR FRR is no longer sufficient to forward
traffic of the path around the failure, since the non-neighbors of
the failure will no longer have a route to the failed node. This
document describes a mechanism for the restoration of the routes to
the failure of a SR-MPLS TE path after the IGP converges. It
provides the restoration of the routes to an adjacency segment, a
node segment and a binding segment of the path. With the restoration
of the routes to the failure, the traffic is continuously sent to the
neighbor of the failure after the IGP converges. The neighbor as a
PLR fast re-routes the traffic around the failure.

"SRIFT: Segment Routing in Fat Trees", Zhaohui Zhang, Jeff Tantsura, Jordan
Head, Don Fedyk, 2022-05-26, <draft-zzhang-rift-sr-04.txt>

This document specifies signaling procedures for Segment Routing in

RIFT. Each node's loopback address, Segment Routing Global Block
(SRGB) and Node Segment Identifier (Node-SID), which are typically
assigned by a configuration management system and distibuted by
routing protocols, are distributed southbound from the Top Of Fabric
(TOF) nodes via RIFT's Key-Value distribution mechanism, so that each
node can compute how to reach a segment represented by the active SID
 in a packet. An SR controller signals SR policies to ingress nodes
so that they can send packets with a desired segment list to steer
traffic.

"Multicast/BIER As A Service", Zhaohui Zhang, Eric Rosen, Daniel Awduche,

Greg Shepherd, 2022-05-26, <draft-zzhang-bier-multicast-as-a-service-04.txt>

This document describes a framework for providing multicast as a

service via Bit Index Explicit Replication (BIER) [RFC7279], and
specifies a few enhancements to [draft-ietf-bier-idr-extensions]
[RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service.

"Flowspec Indirection-id Redirect for SRv6", Gunter Van de Velde, Keyur

Patel, Zhenbin Li, Huaimo Chen, 2022-07-11,
<draft-ietf0-idr-srv6-flowspec-path-redirect-08.txt>

This document defines extensions to "FlowSpec Redirect to

indirection-id Extended Community" for SRv6. This extended community
can trigger advanced redirection capabilities to flowspec clients for
SRv6. When activated, this flowspec extended community is used by a
flowspec client to retrieve the corresponding next-hop and encoding
information within a localised indirection-id mapping table.

The functionality detailed in this document allows a network

controller to decouple the BGP flowspec redirection instruction from
the operation of the available paths.

"SRv6 and MPLS interworking", Swadesh Agrawal, Zafar Ali, Clarence

Filsfils, Dan Voyer, Zhenbin Li, 2022-03-07,
<draft-agrawal-spring-srv6-mpls-interworking-08.txt>

This document describes SRv6 and MPLS/SR-MPLS interworking and co-

existence procedures.

"Segment Routing Header encapsulation for In-situ OAM Data", Zafar Ali,
Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Nainar, Carlos
Pignataro, Cheng Li, Mach Chen, Gaurav Dawra, 2022-07-10,
<draft-ali-spring-ioam-srv6-06.txt>

OAM and PM information from the SR endpoints can be piggybacked in

the data packet. The OAM and PM information piggybacking in the data
packets is also known as In-situ OAM (IOAM). IOAM records
operational and telemetry information in the data packet while the
packet traverses a path between two points in the network. This
document defines how IOAM data fields are transported as part of the
Segment Routing with IPv6 data plane (SRv6) header.

"Multiple Layer Resource Optimization for Optical as a Service", Hui Yang,

Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang, 2022-04-22,
<draft-multiple-layer-resource-optimization-07.txt>

We have established a neural network model optimized by adaptive

artificial fish swarm algorithm. Then we propose a novel multi-path
pre-reserved resource allocation strategy to increase resource
utilization. The results prove the effectiveness of our method.

"Security Classes for IoT devices", Pascal Urien, 2022-06-18,

<draft-urien-lwig-security-classes-08.txt>
 This draft attempts to define security classes for constraint IoT
devices. A device security is characterized by five Boolean security
attributes: one time programmable memory (OTP), firmware loader
(FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT-
KEY) and diversified key (DIV-KEY).

This leads to the definition of 6 classes of devices, embedding or

not OTP resource, whose security increases with the class number (0
to 5). The suffix + indicates OTP availability.

"MessageVortex Protocol", Martin Gwerder, 2022-04-06,

<draft-gwerder-messagevortexmain-09.txt,.pdf>

The MessageVortex (referred to as Vortex) protocol achieves different

degrees of anonymity, including sender, receiver, and third-party
anonymity, by specifying messages embedded within the existing
transfer protocols, such as SMTP or XMPP, sent via peer nodes to one
or more recipients.

The protocol outperforms others by decoupling the transport from the

final transmitter and receiver. No trust is placed into any
infrastructure except for that of the sending and receiving parties
of the message. The creator of the routing block (routing block
builder; RBB) has full control over the message flow. Routing nodes
gain no non-obvious knowledge about the messages even when
collaborating. While third-party anonymity is always achieved, the
protocol also allows for either sender or receiver anonymity.

"The Multibase Data Format", Juan Benet, Manu Sporny, 2022-08-20,

<draft-multiformats-multibase-06.txt>

Raw binary data is often encoded using a mechanism that enables the
data to be included in human-readable text-based formats. This
mechanism is often referred to as "base-encoding the data". Base-
encoding is often used when expressing binary data in hyperlinks,
cryptographic keys in web pages, or security tokens in application
software. There are a variety of base-encodings, such as base32,
base58, and base64. It is not always possible to differentiate one
base-encoding from another. The purpose of this specification is to
provide a mechanism to be able to deterministically identify the
base-encoding for a particular string of data.

"CoRE Resource Directory Extensions", Christian Amsuess, 2022-07-11,

<draft-amsuess-core-resource-directory-extensions-07.txt>

A collection of extensions to the Resource Directory [rfc9176] that

can stand on their own, and have no clear future in specification
yet.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Constrained RESTful

Environments Working Group mailing list (core@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/core/.

Source for this draft and an issue tracker can be found at

https://gitlab.com/chrysn/resource-directory-extensions.
"General Guidance for Implementing Branded Indicators for Message
Identification (BIMI)", Alex Brotman, Terry Zink, Marc Bradshaw,
2022-04-10, <draft-brotman-ietf-bimi-guidance-05.txt>

This document is meant to provide guidance to various entities so

that they may implement Brand Indicators for Message Identification
(BIMI). This document is a companion to various other BIMI drafts,
which should first be consulted.

"MPLS Extension Header Architecture", Loa Andersson, Jim Guichard, Haoyu

Song, Stewart Bryant, 2022-04-05,
<draft-andersson-mpls-eh-architecture-03.txt>

Extension Headers (EH) carry information on in-network services and

functions in an MPLS network. This document describes an
architecture for EHs and what actions an EH capable Label Switching
Router (LSR) takes when finding or not finding an EH in the packet.

Multiprotocol Label Switching (MPLS) is a widely deployed forwarding

technology. It uses label stack entries that are pre-pended to
either the EH or the ACH which in turn is pre-pended to the payload.
The label stack entries are used to identify the forwarding actions
by each LSR. Actions may include pushing, swapping or popping the
labels, and using the labels to determine the next hop for forwarding
the packet. Labels may also be used to establish the context under
which the packet is forwarded.

The extension headers are carried after the MPLS Label Stack, and the
presence of EHs are indicated in the label stack by an Extension
Header Indicator (EHI).

"Options for MPLS Extension Header Indicator", Haoyu Song, Zhenbin Li,
Tianran Zhou, Loa Andersson, 2022-06-27,
<draft-song-mpls-eh-indicator-05.txt>

This document enumerates and describes the candidate schemes that can
be used to indicate the presence of the MPLS extension header(s)
following the MPLS label stack. The similar schemes are also
applicable for indicating the potential in-stack extensions. After a
careful evaluation of these options by comparing their pros and cons,
it is expected that one should be chosen as the final standard scheme
for MPLS extension indicator.

"IKEv2 Optional SA&TS Payloads in Child Exchange", Sandeep Kampati, Wei

Pan, Paul Wouters, Bharath Meduri, chenmeiling, 2022-08-16,
<draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-09.txt>

This document describes a method for reducing the size of the

Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges
used for rekeying of the IKE or Child SA by replacing the SA and TS
payloads with a Notify Message payload. Reducing size and complexity
of IKEv2 exchanges is especially useful for low power consumption
battery powered devices.

"MPLS Label Operations in MPLS EH capable networks", Loa Andersson, Jim

Guichard, Haoyu Song, Stewart Bryant, 2022-04-05,
<draft-andersson-mpls-eh-label-stack-operations-03.txt>
 Extension Headers (EH) carry information on in-network services and
functions in an MPLS network. This document describes the operations
on the MPLS label stack when an EH is found in the packet.

"Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip

Hallam-Baker, 2022-04-20, <draft-hallambaker-mesh-udf-16.txt>

This document describes the underlying naming and addressing schemes

used in the Mathematical Mesh. The means of generating Uniform Data
Fingerprint (UDF) values and their presentation as text sequences and
as URIs are described.

A UDF consists of a binary sequence, the initial eight bits of which

specify a type identifier code. For convenience, UDFs are typically
presented to the user in the form of a Base32 encoded string. Type
identifier codes have been selected so as to provide a useful
mnemonic indicating their purpose when presented in Base32 encoding.

Two categories of UDF are described. Data UDFs provide a compact

presentation of a fixed length binary data value in a format that is
convenient for data entry. A Data UDF may represent a cryptographic
key, a nonce value or a share of a secret. Fingerprint UDFs provide
a compact presentation of a Message Digest or Message Authentication
Code value.

A Strong Internet Name (SIN) consists of a DNS name which contains at

least one label that is a UDF fingerprint of a policy document
controlling interpretation of the name. SINs allow a direct trust
model to be applied to achieve end-to-end security in existing
Internet applications without the need for trusted third parties.

UDFs may be presented as URIs to form either names or locators for

use with the UDF location service. An Encrypted Authenticated
Resource Locator (EARL) is a UDF locator URI presenting a service
from which an encrypted resource may be obtained and a symmetric key
that may be used to decrypt the content. EARLs may be presented on
paper correspondence as a QR code to securely provide a machine-
readable version of the same content. This may be applied to
automate processes such as invoicing or to provide accessibility
services for the partially sighted.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html.

"Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)", Phillip
Hallam-Baker, 2022-04-20, <draft-hallambaker-mesh-dare-15.txt>

This document describes the Data At Rest Encryption (DARE) Envelope

and Sequence syntax.

The DARE Envelope syntax is used to digitally sign, digest,

authenticate, or encrypt arbitrary content data.
 The DARE Sequence syntax describes an append-only sequence of
entries, each containing a DARE Envelope. DARE Sequences may support
cryptographic integrity verification of the entire data container
content by means of a Merkle tree.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html.

"The IPv6 Compact Routing Header (CRH)", Ron Bonica, Yuji Kamite, Andrew
Alston, Daniam Henriques, Luay Jalil, 2022-05-18,
<draft-bonica-6man-comp-rtg-hdr-28.txt>

This document defines two new Routing header types. Collectively,

they are called the Compact Routing Headers (CRH). Individually,
they are called CRH-16 and CRH-32.

"Considerations for Benchmarking Network Performance in Containerized

Infrastructures", Sun Kj, Hyunsik Yang, Jangwon Lee, Tran Ngoc, Younghan
Kim, 2022-03-05, <draft-dcn-bmwg-containerized-infra-08.txt>

This draft describes considerations for benchmarking network

performance in containerized infrastructures. In the containerized
infrastructure, Virtualized Network Functions(VNFs) are deployed on
an operating-system-level virtualization platform by abstracting the
user namespace as opposed to virtualization using a hypervisor.
Hence, the system configurations and networking scenarios for
benchmarking will be partially changed by how the resource allocation
and network technologies are specified for containerized VNFs. This
draft compares the state of the art in the container networking
architecture with VM-based virtualized systems networking
architecture and provides several test scenarios for benchmarking
network performance in containerized infrastructures.

"A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6)
support in Path Computation Element Communications Protocol (PCEP)", Cheng
Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor,
2022-07-11, <draft-li-pce-pcep-srv6-yang-07.txt>

This document augments a YANG data model for the management of Path
Computation Element Communications Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs in support for Segment Routing in
IPv6 (SRv6) and SR Policy. The data model includes configuration
data and state data (status information and counters for the
collection of statistics).

"Composite Signatures For Use In Internet PKI", Mike Ounsworth,

Massimiliano Pala, 2022-06-08, <draft-ounsworth-pq-composite-sigs-07.txt>

The migration to post-quantum cryptography is unique in the history

of modern digital cryptography in that neither the old outgoing nor
the new incoming algorithms are fully trusted to protect data for the
required data lifetimes. The outgoing algorithms, such as RSA and
 elliptic curve, may fall to quantum cryptanalysis, while the incoming
post-quantum algorithms face uncertainty about both the underlying
mathematics as well as hardware and software implementations that
have not had sufficient maturing time to rule out classical
cryptanalytic attacks and implementation bugs.

Cautious implementer may wish to layer cryptographic algorithms such

that an attacker would need to break all of them in order to
compromise the data being protected. For digital signatures, this is
referred to as "dual", and for encryption key establishment this as
referred to as "hybrid". This document, and its companions, defines
a specific instantiation of the dual and hybrid paradigm called
"composite" where multiple cryptographic algorithms are combined to
form a single key, signature, or key encapsulation mechanism (KEM)
such that they can be treated as a single atomic object at the
protocol level.

EDNOTE: the terms "dual" and "hybrid" are currently in flux. We

anticipate an Informational draft to normalize terminology, and will
update this draft accordingly.

This document defines the structures CompositeSignatureValue, and

CompositeParams, which are sequences of the respective structure for
each component algorithm. The generic composite variant is defined
which allows arbitrary combinations of signature algorithms to be
used in the CompositeSignatureValue and CompositeParams structures
without needing the combination to be pre-registered or pre-agreed.
The explicit variant is also defined which allows for a set of
signature algorithm identifier OIDs to be registered together as an
explicit composite signature algorithm and assigned an OID.

This document is intended to be coupled with corresponding documents

that define the structure and semantics of composite public and
private keys and encryption [I-D.draft-ounsworth-pq-composite-keys-
01], however may also be used with non-composite keys, such as when a
protocol combines multiple certificates into a single cryptographic
operation.

"SRv6 Midpoint Protection", Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong
Geng, Yisong Liu, Gyan Mishra, 2022-07-11,
<draft-chen-rtgwg-srv6-midpoint-protection-08.txt>

The current local repair mechanism, e.g., TI-LFA, allows local repair
actions on the direct neighbors of the failed node or link to
temporarily route traffic to the destination. This mechanism could
not work properly when the failure happens in the destination point.
In SRv6 TE, the IPv6 destination address in the outer IPv6 header
could be the segment endpoint of the TE path rather than the
destination of the TE path. When the SRv6 endpoint fails, local
repair couldn't work on the direct neighbor of the failed endpoint
either. This document defines midpoint protection for SRv6 TE path,
which enables other nodes on the network to perform endpoint
behaviors instead of the faulty node, Update the IPv6 destination
address to the other endpoint, and choose the next hop based on the
new destination address.

"Requirements and Challenges for User-level Service Managements of IoT

Network by utilizing Artificial Intelligence", Junkyun Choi, Jaeseob Han,
Gyeong Lee, Jae Park, Chan Lee, Jung Lee, Hyeon Seo, 2022-06-28,
<draft-choi-icnrg-aiot-09.txt>

This document describes the requirements and challenges to employ

artificial intelligence (AI) into the constraint Internet of Things
(IoT) service environment for embedding intelligence and increasing
efficiency.

The IoT service environment includes heterogeneous and multiple IoT

devices and systems that work together in a cooperative and
intelligent way to manage homes, buildings, and complex autonomous
systems. Therefore, it is becoming very essential to integrate IoT
and AI technologies to increase the synergy between them. However,
there are several limitations to achieve AI enabled IoT as the
availability of IoT devices is not always high, and IoT networks
cannot guarantee a certain level of performance in real-time
applications due to resource constraints.

This document intends to present a right direction to empower AI in

IoT for learning and analyzing the usage behaviors of IoT
devices/systems and human behaviors based on previous records and
experiences. With AI enabled IoT, the IoT service environment can be
intelligently managed in order to compensate for the unexpected
performance degradation often caused by abnormal situations.

"BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf,
Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2022-03-07,
<draft-xu-grow-bmp-route-policy-attr-trace-06.txt>

The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from

BGP route exchange and route policy processing. BGP Monitoring
Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854],
BGP local-rib [RFC9069] and BGP adj-rib-out [RFC8671]. By monitoring
these BGP RIB's the full state of the network is visible, but how
route-policies affect the route propagation or changes BGP attributes
is still not. This document describes a method of using BMP to
record the trace data on how BGP routes are (not) changed under the
process of route policies.

"Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng

Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde, 2022-04-21,
<draft-li-rtgwg-enhanced-ti-lfa-06.txt>

Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims

at providing protection of node and adjacency segments within the
Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR
path selection approach establishing protection over the expected
post-convergence paths from the point of local repair. However, the
TI-LFA FRR path may skip the node even if it is specified in the SID
list to be traveled.

This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass

indicator for segments to ensure that the FRR route will not bypass
the specific node, such as firewall. Also, this document defines No-
bypass flag and No-FRR flag in SRH to indicate not to bypass nodes
and not to perform FRR on all the nodes along the SRv6 path,
respectively.

"Arm's Platform Security Architecture (PSA) Attestation Token", Hannes

Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati,
2022-03-07, <draft-tschofenig-rats-psa-token-09.txt>

The Platform Security Architecture (PSA) is a family of hardware and

firmware security specifications, as well as open-source reference
implementations, to help device makers and chip manufacturers build
best-practice security into products. Devices that are PSA compliant
are able to produce attestation tokens as described in this memo,
which are the basis for a number of different protocols, including
secure provisioning and network access control. This document
specifies the PSA attestation token structure and semantics.

The PSA attestation token is a profiled Entity Attestation Token

(EAT).

This specification describes what claims are used in an attestation

token generated by PSA compliant systems, how these claims get
serialized to the wire, and how they are cryptographically protected.

"Multi-Subject JSON Web Token (JWT)", Rifaat Shekh-Yusef, 2022-06-14,

<draft-yusef-oauth-nested-jwt-05.txt>

This specification defines a mechanism for including multiple

subjects in a JWT. A primary subject in an enclosing JWT with its
own claims, and a related secondary subject in a nested JWT with its
own claims.

"Autonomic setup of fog monitoring agents", Carlos Bernardos, Alain Mourad,

Pedro Martinez-Julia, 2022-05-24,
<draft-bernardos-anima-fog-monitoring-06.txt>

The concept of fog computing has emerged driven by the Internet of

Things (IoT) due to the need of handling the data generated from the
end-user devices. The term fog is referred to any networked
computational resource in the continuum between things and cloud. In
fog computing, functions can be stiched together composing a service
function chain. These functions might be hosted on resources that
are inherently heterogeneous, volatile and mobile. This means that
resources might appear and disappear, and the connectivity
characteristics between these resources may also change dynamically.
This calls for new orchestration solutions able to cope with dynamic
changes to the resources in runtime or ahead of time (in anticipation
through prediction) as opposed to today's solutions which are
inherently reactive and static or semi-static.

A fog monitoring solution can be used to help predicting events so an

action can be taken before an event actually takes place. This
solution is composed of agents running on the fog nodes plus a
controller hosted at another device (running in the infrastructure or
in another fog node). Since fog environments are inherently volatile
and extremely dynamic, it is convenient to enable the use of
autonomic technologies to autonomously set-up the fog monitoring
platform. This document aims at presenting this use case as well as
specifying how to use GRASP as needed in this scenario.

"Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz, Ira

McDonald, Carsten Bormann, 2022-07-10, <draft-birkholz-rats-tuda-07.txt>

This document defines the method and bindings used to convey Evidence
via Time-based Uni-Directional Attestation (TUDA) in Remote
 ATtestation procedureS (RATS). TUDA does not require a challenge-
response handshake and thereby does not rely on the conveyance of a
nonce to prove freshness of remote attestation Evidence. TUDA
enables the creation of Secure Audit Logs that can constitute
believable Evidence about both current and past operational states of
an Attester. In TUDA, RATS entities require access to a Handle
Distributor to which a trustable and synchronized time-source is
available. The Handle Distributor takes on the role of a Time Stamp
Authority (TSA) to distribute Handles incorporating Time Stamp Tokens
(TST) to the RATS entities. RATS require an Attesting Environment
that generates believable Evidence. While a TPM is used as the
corresponding root of trust in this specification, any other type of
root of trust can be used with TUDA.

"SRv6 Implementation and Deployment Status", Satoru Matsushima, Clarence

Filsfils, Zafar Ali, Zhenbin Li, Kalyani Rajaraman, Amit Dhamija,
2022-04-05, <draft-matsushima-spring-srv6-deployment-status-15.txt>

This draft provides an overview of IPv6 Segment Routing (SRv6)

deployment status. It lists various SRv6 features that have been
deployed in the production networks. It also provides an overview of
SRv6 implementation and interoperability testing status.

"Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon

Jeong, Bien Mugabarigira, Yiwen Shen, Hyeonah Jung, 2022-07-25,
<draft-jeong-ipwave-vehicular-mobility-management-08.txt>

This document specifies a Vehicular Mobility Management (VMM) scheme

for IP-based vehicular networks. The VMM scheme takes advantage of a
vehicular link model based on a multi-link subnet. With a vehicle's
mobility information (e.g., position, speed, acceleration/
deceleration, and direction) and navigation path (i.e., trajectory),
it can provide a moving vehicle with proactive and seamless handoff
along with its trajectory.

"Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip

Hallam-Baker, 2022-04-20, <draft-hallambaker-mesh-cryptography-09.txt>

The Mathematical Mesh 'The Mesh' is an infrastructure that

facilitates the exchange of configuration and credential data between
multiple user devices and provides end-to-end security. This
document describes the cryptographic algorithm suites used in the
Mesh and the implementation of Multi-Party Encryption and Multi-Party
Key Generation used in the Mesh.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html.

"Mathematical Mesh 3.0 Part IX Security Considerations", Phillip

Hallam-Baker, 2022-04-20, <draft-hallambaker-mesh-security-09.txt>

The Mathematical Mesh 'The Mesh' is an end-to-end secure

 infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html.

"Mathematical Mesh 3.0 Part V: Protocol Reference", Phillip Hallam-Baker,

2022-04-20, <draft-hallambaker-mesh-protocol-13.txt>

The Mathematical Mesh 'The Mesh' is an end-to-end secure

infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html.

"Mathematical Mesh 3.0 Part IV: Schema Reference", Phillip Hallam-Baker,

2022-04-20, <draft-hallambaker-mesh-schema-10.txt>

The Mathematical Mesh 'The Mesh' is an end-to-end secure

infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list

(mathmesh@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at

http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.

"Abuse-Resistant OpenPGP Keystores", Daniel Gillmor, 2022-04-28,

<draft-dkg-openpgp-abuse-resistant-keystore-05.txt>

OpenPGP transferable public keys are composite certificates, made up

of primary keys, revocation signatures, direct key signatures, user
IDs, identity certifications ("signature packets"), subkeys, and so
on. They are often assembled by merging multiple certificates that
all share the same primary key, and are distributed in public
keystores.
 Unfortunately, since many keystores permit any third-party to add a
certification with any content to any OpenPGP certificate, the
assembled/merged form of a certificate can become unwieldy or
undistributable. Furthermore, keystores that are searched by user ID
or fingerprint can be made unusable for specific searches by public
submission of bogus certificates. And finally, keystores open to
public submission can also face simple resource exhaustion from
flooding with bogus submissions, or legal or other risks from uploads
of toxic data.

This draft documents techniques that an archive of OpenPGP

certificates can use to mitigate the impact of these various attacks,
and the implications of these concerns and mitigations for the rest
of the OpenPGP ecosystem.

"Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li,

Chongfeng Xie, Hui Tian, Jianwei Mao, 2022-04-21,
<draft-li-spring-srv6-security-consideration-08.txt>

SRv6 inherits potential security vulnerabilities from Source Routing

in general, and also from IPv6. This document describes various
threats and security concerns related to SRv6 networks and existing
approaches to solve these threats.

"Design of the native Cyberspace Map", Jilong Wang, Miao Congcong,

Changqing An, Shuying Zhuang, 2022-05-30,
<draft-jilongwang-opsawg-cybersmap-06.txt>

This memo discusses the design of the native cyberspace map which is
stable and flexible to describe cyberspace. Although we have
accepted the cyberspace as a parallel new world, we even have not
defined its basic coordinate system, which means cyberspace have no
its basic space dimension till now. The objective of this draft is
to illustrate the basic design methodology of the native coordinate
system of cyberspace, and show how to design cyberspace map on this
basis.

"A Framework for Constructing Service Function Chaining Systems Based on

Segment Routing", Cheng Li, Ahmed El Sawaf, Ruizhao Hu, Zhenbin Li,
2022-04-21, <draft-li-spring-sr-sfc-control-plane-framework-06.txt>

Segment Routing (SR) allows for a flexible definition of end-to-end

paths by encoding paths as sequences of topological sub-paths, called
"segments". Segment routing architecture can be implemented over an
MPLS data plane as well as an IPv6 data plane.

Service Function Chaining (SFC) provides support for the creation of

composite services that consist of an ordered set of Service
Functions (SF) that are to be applied to packets and/or frames
selected as a result of classification.

SFC can be implemented based on several technologies, such as Network

Service Header (NSH) and SR. This document describes a framework for
constructing SFC based on Segment Routing. The document reviews the
control plane solutions for route distribution of service function
instance and service function path, and steering packets into a
service function chain.
"Guidelines for Internet Congestion Control at Endpoints", Gorry Fairhurst,
2022-08-29, <draft-fairhurst-tsvwg-cc-06.txt>

This document will provide guidance on the design of methods to avoid

congestion collapse and to react to incipient congestion. The
present document is for discussion and comment by the IETF. If
published, it plans to update or replace the Best Current Practice in
BCP 41, which currently includes "Congestion Control Principles"
provided in RFC2914.

The current recommendations and requirements on this topic are

distributed across many documents in the RFC series. This document
therefore seeks to gather and consolidate these recommendations in an
annexe. Based on these specifications, and Internet engineering
experience, the document provides input to the design of new
congestion control methods in protocols.

This revision updates the source to a modern XML format, and is for
discussion by tsvwg.

"Preferred Path Loop-Free Alternate (pLFA)", Stewart Bryant, Uma Chunduri,

Toerless Eckert, 2022-05-09, <draft-bryant-rtgwg-plfa-04.txt>

Fast re-route (FRR) is a technique that allows productive forwarding

to continue in a network after a failure has occurred, but before the
network has has time to re-converge. This is achieved by forwarding
a packet on an alternate path that will not result in the packet
looping. Preferred Path Routing (PPR) provides a method of injecting
explicit paths into the routing protocol. The use of PPR to support
FRR has a number of advantages. This document describes the
advantages of using PPR to provide a loop-free alternate FRR path,
and provides a framework for its use in this application.

"PCEP Operational Clarification", Mike Koldychev, Siva Sivabalan, Shuping

Peng, Diego Achaval, Hari Kotni, 2022-07-04,
<draft-koldychev-pce-operational-06.txt>

This document updates, simplifies and clarifies certain aspects of

the PCEP protocol. The content of this document has been compiled
based on several interop exercises.

"BMP Extension for Path Status TLV", Camilo Cardona, Paolo Lucente, Pierre
Francois, Yunan Gu, Thomas Graf, 2022-05-10,
<draft-cppy-grow-bmp-path-marking-tlv-10.txt>

The BGP Monitoring Protocol (BMP) provides an interface for obtaining

BGP Path information. BGP Path Information is conveyed within BMP
Route Monitoring (RM) messages. This document proposes an extension
to BMP to convey the status of a BGP path before and after being
processed by the BGP best-path selection algorithm. This extension
makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv
[I-D.ietf-grow-bmp-tlv] and draft-lucente-grow-bmp-tlv-ebit
[I-D.lucente-grow-bmp-tlv-ebit].

"Group OSCORE Profile of the Authentication and Authorization for

Constrained Environments Framework", Marco Tiloca, Rikard Hoeglund, Ludwig
Seitz, Francesca Palombini, 2022-03-07,
<draft-tiloca-ace-group-oscore-profile-08.txt>
 This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. The
profile uses Group OSCORE to provide communication security between a
Client and a (set of) Resource Server(s) as members of an OSCORE
Group. The profile securely binds an OAuth 2.0 Access Token with the
public key of the Client associated with the private key used in the
OSCORE group. The profile uses Group OSCORE to achieve server
authentication, as well as proof-of-possession for the Client's
public key. Also, it provides proof of the Client's membership to
the correct OSCORE group, by binding the Access Token to information
from the Group OSCORE Security Context, thus allowing the Resource
Server(s) to verify the Client's membership upon receiving a message
protected with Group OSCORE from the Client.

"SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang,
Zhenqiang Li, Lei Liu, Xufeng Liu, 2022-04-18,
<draft-chen-idr-sr-ingress-protection-06.txt>

This document describes extensions to Border Gateway Protocol (BGP)

for protecting the ingress node of a Segment Routing (SR) tunnel or
path.

"Path Ingress Protections", Huaimo Chen, Mike McBride, Mehmet Toy, Gyan
Mishra, Aijun Wang, Zhenqiang Li, Yisong Liu, Boris Khasanov, Lei Liu,
Xufeng Liu, 2022-05-15, <draft-chen-pce-sr-ingress-protection-08.txt>

This document describes extensions to Path Computation Element (PCE)

communication Protocol (PCEP) for fast protecting the ingress nodes
of two types of paths or tunnels, which are Segment Routing (SR)
paths and Bit Index Explicit Replication Tree/Traffic Engineering
(BIER-TE) paths. The extensions comprise a foundation for protecting
the ingress nodes of different types of paths. Based on this, the
ingress protection of a new type of paths can be easily supported.

"Test Tools for IoT DDoS vulnerability scanning", Sorin Faibish, Mashruf
Chowdhury, 2022-06-13, <draft-faibish-iot-ddos-usecases-07.txt>

This document specifies several usecases related to the different

ways IoT devices are exploited by malicious adversaries to
instantiate Distributed Denial of Services (DDoS) attacks. The
attacks are generted from IoT devices that have no proper protection
against generating unsolicited communication messages targeting a
certain network and creating large amounts of network traffic. The
attackers take advantage of breaches in the configuration data in
unprotected IoT devices exploited for DDoS attacks. The attackers
take advantage of the IoT devices that can send network packets
that were generated by malicious code that interacts with an OS
implementation that runs on the IoT devices. The prupose of this
draft is to present possible IoT DDoS usecases that need to be
prevented by TEE. The major enabler of such attacks is related to
IoT devices that have no OS or unprotected EE OS and run
code that is downloaded to them from the TA and modified by
man-in-the-middle that inserts malicious code in the OS. This draft
adds list of MUD files for most IoT devices.

"The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency", Bob

Briscoe, Greg White, 2022-05-13, <draft-briscoe-docsis-q-protection-06.txt>

This informational document explains the specification of the queue

 protection algorithm used in DOCSIS technology since version 3.1. A
shared low latency queue relies on the non-queue-building behaviour
of every traffic flow using it. However, some flows might not take
such care, either accidentally or maliciously. If a queue is about
to exceed a threshold level of delay, the queue protection algorithm
can rapidly detect the flows most likely to be responsible. It can
then prevent harm to other traffic in the low latency queue by
ejecting selected packets (or all packets) of these flows. The
document is designed for four types of audience: a) congestion
control designers who need to understand how to keep on the 'good'
side of the algorithm; b) implementers of the algorithm who want to
understand it in more depth; c) designers of algorithms with similar
goals, perhaps for non-DOCSIS scenarios; and d) researchers
interested in evaluating the algorithm.

"Network Programming extension: SRv6 uSID instruction", Clarence Filsfils,

Pablo Camarillo, Dezhong Cai, Dan Voyer, Israel Meilik, Keyur Patel, Wim
Henderickx, Prem Jonnalagadda, David Melman, Yisong Liu, Jim Guichard,
2022-06-13, <draft-filsfils-spring-net-pgm-extension-srv6-usid-13.txt>

The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is
a straightforward extension of the SRv6 Network Programming model:

* The SRv6 Control Plane is leveraged without any change

* The SRH dataplane encapsulation is leveraged without any change

* Any SID in the SID list can carry micro segments

* Based on the Compressed SRv6 Segment List Encoding in SRH

"IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels", Tarek Saad,
Vishnu Beeram, 2022-04-12, <draft-saad-teas-rsvpte-ip-tunnels-02.txt>

This document describes the use of RSVP (Resource Reservation

Protocol), including all the necessary extensions, to establish
Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched
Path (LSP) tunnel(s) for use in native IP forwarding networks.

This document proposes specific extensions to the RSVP protocol to

allow the establishment of explicitly routed IP paths using RSVP as
the signaling protocol. The result is the instantiation of an IP
Path which can be automatically routed away from network failures,
congestion, and bottlenecks.

"Describing Protocol Data Units with Augmented Packet Header Diagrams",

Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins, 2022-03-07,
<draft-mcquistin-augmented-ascii-diagrams-10.txt>

This document describes a machine-readable format for specifying the

syntax of protocol data units within a protocol specification. This
format is comprised of a consistently formatted packet header
diagram, followed by structured explanatory text. It is designed to
maintain human readability while enabling support for automated
parser generation from the specification document. This document is
itself an example of how the format can be used.

"HTTP Transport Authentication", David Schinazi, David Oliver, 2022-07-11,

<draft-schinazi-httpbis-transport-auth-07.txt>
 Existing HTTP authentication mechanisms are probeable in the sense
that it is possible for an unauthenticated client to probe whether an
origin serves resources that require authentication. It is possible
for an origin to hide the fact that it requires authentication by not
generating Unauthorized status codes, however that only works with
non-cryptographic authentication schemes: cryptographic schemes (such
as signatures or message authentication codes) require a fresh nonce
to be signed, and there is no existing way for the origin to share
such a nonce without exposing the fact that it serves resources that
require authentication. This document proposes a new non-probeable
cryptographic authentication scheme.

"SRv6 for Inter-Layer Network Programming", Jie Dong, Liuyan Han, Zongpeng
Du, Minxue Wang, 2022-07-10,
<draft-dong-spring-srv6-inter-layer-programming-03.txt>

This document defines a new SRv6 function which can be used for SRv6
based inter-layer network programming. It is a variant of the End.X
behavior. Instead of pointing to an interface with layer-3
adjacency, this new End.XU behavior points to an underlay interface
which connects to a remote layer-3 node via underlying links or
connections that may be invisible in the L3 topology.

"PCEP Extension for SR-MPLS Entropy Label Position", Quan Xiong, Shaofu
Peng, Fengwei Qin, 2022-08-29,
<draft-peng-pce-entropy-label-position-08.txt>

This document proposes a set of extensions for PCEP to configure the

entropy label position for SR-MPLS networks.

"Maintaining CCNx or NDN flow balance with highly variable data object
sizes", David Oran, 2022-05-05, <draft-oran-icnrg-flowbalance-07.txt>

Deeply embedded in some ICN architectures, especially Named Data

Networking (NDN) and Content-Centric Networking (CCNx) is the notion
of flow balance. This captures the idea that there is a one-to-one
correspondence between requests for data, carried in Interest
messages, and the responses with the requested data object, carried
in Data messages. This has a number of highly beneficial properties
for flow and congestion control in networks, as well as some
desirable security properties. For example, neither legitimate users
nor attackers are able to inject large amounts of un-requested data
into the network.

Existing congestion control approaches however have a difficult time

dealing effectively with a widely varying MTU of ICN data messages,
because the protocols allow a dynamic range of 1-64K bytes. Since
Interest messages are used to allocate the reverse link bandwidth for
returning Data, there is large uncertainty in how to allocate that
bandwidth. Unfortunately, most current congestion control schemes in
CCNx and NDN only count Interest messages and have no idea how much
data is involved that could congest the inverse link. This document
proposes a method to maintain flow balance by accommodating the wide
dynamic range in Data message size.

"Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish,
Philip Shilane, 2022-06-13,
<draft-faibish-nfsv4-data-reduction-attributes-07.txt>
 This document proposes extending NFSv4 operations to add new
RECOMMENDED attributes to be used in the protocol to provide
information about the data reduction properties of files. The new
data reduction attributes are proposed to allow the client
application to communicate to the NFSv4 server data reduction
attributes associated with files and directories using new metadata,
communicated to the Block Storage data reduction engines.
Corresponding new RECOMMENDED attributes are proposed to allow
clients and client applications to query the server for data
reduction attributes support and allow to get and set data reduction
attributes on files and directories. Such data reduction
metadata is used as hints to the file server about what type of data
reduction to apply. The proposed data reduction attributes include
achievable ratios for compression and deduplication plus whether
each data reduction technique applies to a file or directory.

"YANG Data Model for OSPFv3 Segment Routing", Acee Lindem, Yingzhen Qu,
2022-04-21, <draft-acee-lsr-ospfv3-sr-yang-07.txt>

This document defines a YANG data module augmenting the IETF OSPF
Segment Routing (SR) YANG model to support OSPFv3 extensions for SR.
It can be used to configure and manage OSPFv3 Segment Routing in MPLS
data plane.

"SRv6 NET-PGM extension: Insertion", Clarence Filsfils, Pablo Camarillo,

John Leddy, Dan Voyer, Satoru Matsushima, Zhenbin Li, 2022-08-16,
<draft-filsfils-spring-srv6-net-pgm-insertion-07.txt>

Traffic traversing an SR domain is encapsulated in an outer IPv6

header for its journey through the SR domain.

To implement transport services strictly within the SR domain, the SR

domain may require insertion or deletion of an SRH after the outer
IPv6 header of the SR domain. Any segment within the SRH is strictly
contained within the SR domain.

This document extends SRv6 Network Programming [RFC8986] with new SR

endpoint and transit behaviors to be performed only within the SR
domain in any packet owned by the domain.

"Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2022-05-05,
<draft-oran-icnrg-pathsteering-06.txt>

Path Steering is a mechanism to discover paths to the producers of

ICN content objects and steer subsequent Interest messages along a
previously discovered path. It has various uses, including the
operation of state-of-the-art multipath congestion control algorithms
and for network measurement and management. This specification
derives directly from the design published in _Path Switching in
Content Centric and Named Data Networks_ (4th ACM Conference on
Information-Centric Networking - ICN'17) and therefore does not
recapitulate the design motivations, implementation details, or
evaluation of the scheme. Some technical details are different
however, and where there are differences, the design documented here
is to be considered definitive.

"LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay

Hooda, 2022-04-19, <draft-jain-lisp-site-external-connectivity-05.txt>
 This draft defines how to register/retrieve pETR mapping information
in LISP when the destination is not registered/known to the local
site and its mapping system (e.g. the destination is an internet or
external site destination).

"Prefix Unreachable Announcement", Aijun Wang, Gyan Mishra, Zhibo Hu, Yaqun
Xiao, 2022-07-10, <draft-wang-lsr-prefix-unreachable-annoucement-10.txt>

This document describes a mechanism that can trigger the switchover

of the services which rely on the reachability of the peer endpoints,
for example the BGP or the tunnel services. It is mainly used in the
scenarios that the summary prefixes are advertised at the border
routers whereas the services endpoints are located in different IGP
areas or levels, whose reachabilities are covered by the summary
prefixes.

It introduces a new signaling mechanism using a negative prefix

announcement called Prefix Unreachable Announcement Mechanism(PUAM),
utilized to detect a link or node down event and signal the overlay
services that the event has occurred to force immediate switchover.

"Lzip Compressed Format and the 'application/lzip' Media Type", Antonio

Diaz, 2022-04-24, <draft-diaz-lzip-05.txt>

Lzip is a lossless compressed data format designed for data sharing,

long-term archiving, and parallel compression/decompression. Lzip
uses a simplified form of the LZMA stream format and provides a 3
factor integrity checking to maximize interoperability and optimize
safety. Lzip can achieve higher compression ratios than gzip. This
document describes the lzip format and registers a media type, a
content encoding, and a structured syntax suffix to be used when
transporting lzip-compressed content via MIME or HTTP.

"PEM file format for ECH", Stephen Farrell, 2022-05-22,

<draft-farrell-tls-pemesni-03.txt>

Encrypted ClientHello (ECH) key pairs need to be configured into TLS

servers, that can be built using different TLS libraries, so there is
a benefit and little cost in documenting a file format to use for
these key pairs, similar to how RFC7468 defines other PEM file
formats.

"Stateless OpenPGP Command Line Interface", Daniel Gillmor, 2022-05-15,

<draft-dkg-openpgp-stateless-cli-04.txt>

This document defines a generic stateless command-line interface for

dealing with OpenPGP messages, known as sop. It aims for a minimal,
well-structured API covering OpenPGP object security.

"The Computerate Specifying Paradigm", Marc Petit-Huguenin, 2022-08-07,

<draft-petithuguenin-computerate-specifying-17.txt>

This document specifies a paradigm named Computerate Specifying,

designed to simultaneously document and formally specify
communication protocols. This paradigm can be applied to any
document produced by any Standard Developing Organization (SDO), but
this document targets specifically documents produced by the IETF.
"GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version
1.3", Stanislav Smyshlyaev, Evgeny Alekseev, Ekaterina Griboedova,
Alexandra Babueva, Lidiya Nikiforova, 2022-05-13,
<draft-smyshlyaev-tls13-gost-suites-06.txt>

The purpose of this document is to make the Russian cryptographic

standards available to the Internet community for their
implementation in the Transport Layer Security (TLS) Protocol Version
1.3.

This specification defines four new cipher suites, seven new

signature schemes and a key exchange mechanism for the TLS 1.3
protocol, that are based on Russian cryptographic standards (called
GOST algorithms). Additionally, this document specifies a profile of
TLS 1.3 with GOST algorithms so that implementers can produce
interoperable implementations. This document does not imply IETF
endorsement of the cipher suites, signature schemes key exchange
mechanism.

"EVPN-VPWS Seamless Integration with L2VPN VPWS", Patrice Brissette, Ali

Sajassi, Luc Burdet, Wen Lin, Jorge Rabadan, Jim Uttaro, Dan Voyer, Iman
Ghamari, Eddie Leyton, Bin Wen, Voitek Kozak, 2022-03-28,
<draft-brissette-bess-evpn-vpws-seamless-05.txt>

This document presents a solution for migrating L2VPN Virtual Private

Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service
(EVPN-VPWS) services. The solution allows the coexistence of EVPN
and L2VPN services under the same point-to-point VPN instance. By
using this seamless integration solution, a service provider can
introduce EVPN into their existing L2VPN network or migrate from an
existing L2VPN based network to EVPN. The migration may be done per
pseudowire or flexible-crossconnext (FXC) service basis. This
document specifies control-plane and forwarding behaviors.

"Using GOST Algorithms for XML Digital Signatures", Pavel Smirnov, Maria
Paramonova, Mikhail Khomenko, Artyom Makarov, 2022-05-05,
<draft-smirnov-xmldsig-05.txt>

This document defines new algorithm identifiers for GOST

cryptographic algorithms and methods of including GOST-based digital
signature and hash-based message authentication code (HMAC) within
the XML document. All statements in this document are techically
equivalent to [R1323565.1.033-2020].

"DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6",
Xueshun Wang, Jinyou Dai, Jianhua Liu, Feng Zhang, 2022-06-18,
<draft-wang-detnet-tsn-over-srv6-05.txt>

This document specifies the Deterministic Networking data plane when

TSN networks interconnected over an Segment Routing IPv6 Packet
Switched Networks.

"Performance Measurement for Geneve", Xiao Min, Greg Mirsky, Santosh

Pallagatti, 2022-05-15, <draft-xiao-nvo3-pm-geneve-05.txt>

This document describes the method to achieve Performance Measurement

(PM) in point-to-point Generic Network Virtualization Encapsulation
(Geneve) tunnels used to make up an overlay network.
"A YANG Data Model for Client Signal Performance Monitoring", Haomian
Zheng, Italo Busi, Zheng Yanlei, Victor Lopez, Oscar de Dios, 2022-07-10,
<draft-zheng-ccamp-client-pm-yang-06.txt>

A transport network is a server-layer network to provide connectivity

services to its client. Given the client signal is configured, the
followup function for performance monitoring, such as latency and bit
error rate, would be needed for network operation.

This document describes the data model to support the performance

monitoring functionalities.

"BGP-LS Extensions for Scalable Segment Routing based Enhanced VPN", Jie
Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, 2022-03-04,
<draft-dong-idr-bgpls-sr-enhanced-vpn-04.txt>

Enhanced VPN (VPN+) aims to provide enhanced VPN services to support

some applications' needs of enhanced isolation and stringent
performance requirements. VPN+ requires integration between the
overlay VPN connectivity and the resources and characteristics
provided by the underlay network. A Virtual Transport Network (VTN)
is a virtual underlay network which can be used to support one or a
group of VPN+ services. In the context of network slicing, a VTN
could be instantiated as a network resource partition (NRP).

This document specifies the BGP-LS mechanisms with necessary

extensions to advertise the information of scalable Segment Routing
(SR) based NRPs to a centralized network controller. Each NRP can
have a customized topology and a set of network resources allocated
from the physical network. Multiple NRPs may shared the same
topology, and multiple NRPs may share the same set of network
resources on specific network segments. This allows flexible
combination of network topology and network resource attributes to
build a large number of NRPs with a relatively small number of
logical topologies. The proposed mechanism is applicable to both
segment routing with MPLS data plane (SR-MPLS) and segment routing
with IPv6 data plane (SRv6).

"Context-Aware Navigation Protocol for IP-Based Vehicular Networks",

Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, JuneHee Kwon, Zeung Kim,
2022-07-25, <draft-jeong-ipwave-context-aware-navigator-06.txt>

This document proposes a Context-Aware Navigation Protocol (CNP) for

IP-based vehicular networks for cooperative navigation among vehicles
in road networks. This CNP aims at the enhancement of driving safety
through a light-weight driving information sharing method. The CNP
protocol uses an IPv6 Neighbor Discovery (ND) option to convey
driving information such as a vehicle's position, speed,
acceleration/deceleration, and direction, and a driver's driving
action (e.g., braking and accelerating).

"Basic Support for Security and Privacy in IP-Based Vehicular Networks",

Jaehoon Jeong, Yiwen Shen, Hyeonah Jung, J., PARK, Tae Oh, 2022-07-25,
<draft-jeong-ipwave-security-privacy-06.txt>

This document describes possible attacks of security and privacy in

IP Wireless Access in Vehicular Environments (IPWAVE). It also
proposes countermeasures for those attacks.
"Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang,
Aijun Wang, Shunwan Zhuang, 2022-08-24,
<draft-wang-idr-flowspec-dip-origin-as-filter-06.txt>

BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both

traffic Flow Specifications and Traffic Filtering Actions by making
use of the BGP NLRI and the BGP Extended Community encoding formats.
This document specifies a new BGP-FS component type to support AS-
level filtering. The match field is the origin AS number of the
destination IP address that is encoded in the Flowspec NLRI. This
function is applied in a single administrative domain.

"IETF Network Slice YANG Data Model", Xufeng Liu, Jeff Tantsura, Igor
Bryskin, Luis Contreras, Qin WU, Sergio Belotti, Reza Rokui, 2022-03-06,
<draft-liu-teas-transport-network-slice-yang-05.txt>

This document describes a YANG data model for managing and

controlling IETF network slices, defined in
[I-D.ietf-teas-ietf-network-slices].

"Use of ALTO for Determining Service Edge", Luis Contreras, Danny Perez,
Christian Rothenberg, Sabine Randriamasy, 2022-07-11,
<draft-contreras-alto-service-edge-05.txt>

Service providers are starting to deploy and interconnect computing

capabilities across the network for hosting network functions and
applications. In distributed computing environments, both computing
and topological information are necessary in order to determine the
more convenient infrastructure where to deploy such a service or
application. This document proposes an initial approach towards the
use of ALTO to provide such information and assist the selection of
appropriate deployment locations for services and applications.

"Bijective MAC for Constraint Nodes", Pascal Urien, 2022-06-18,

<draft-urien-core-bmac-10.txt>

In this draft context, things are powered by micro controllers units

(MCU) comprising a set of memories such as static RAM (SRAM), FLASH
and EEPROM. The total memory size, ranges from 10KB to a few
megabytes. In this context code and data integrity are major
security issues, for the deployment of Internet of Things
infrastructure. The goal of the bijective MAC (bMAC) is to compute
an integrity value, which cannot be guessed by malicious software.
In classical keyed MACs, MAC is computing according to a fixed
order.
In the bijective MAC, the content of N addresses is hashed according
to a permutation P (i.e. bijective application).
The bijective MAC key is the permutation P.
The number of permutations for N addresses is N!. So the computation
of the bMAC requires the knowledge of the whole space memory; this
is trivial for genuine software, but could very difficult for
corrupted software, especially for time stamped bMAC.

"User Plane Message Encoding", Tetsuya Murakami, Satoru Matsushima, Kentaro

Ebisawa, Pablo Camarillo, Ravi Shekhar, 2022-03-05,
<draft-murakami-dmm-user-plane-message-encoding-05.txt,.pdf>

This document defines the encoding of User Plane messages into

Segment Routing Header (SRH). The SRH carries the User Plane
 messages over SRv6 Network.

"Deadline-aware Transport Protocol", Yong Cui, Chuan Ma, Hang Shi, Kai
Zheng, Wei Wang, 2022-07-26, <draft-shi-quic-dtp-06.txt>

This document defines Deadline-aware Transport Protocol (DTP) to

provide block-based deliver-before-deadline transmission. The
intention of this memo is to describe a mechanism to fulfill
unreliable transmission based on QUIC as well as how to enhance
timeliness of data delivery.

"Data Aggregation in IPv6-based Vehicular Networks", Zhiwei Yan, Jong-Hyouk

Lee, Jaehoon Jeong, Hidenori Nakazato, Yong-Jin Park, 2022-05-10,
<draft-yan-ipwave-aggregation-05.txt>

Considering the large-scale but small-sized information exchange in

the vehicular information network, this draft document aims at
outlining the requirements to support the data aggregation in
vehicular networks based on the concept of Information-centric
networking (ICN), in order to make the information retrieval and
dissemination in an efficient way.

"Delivering Functions over Networks: Traffic and Performance Optimization

for Edge Computing using ALTO", Shu Yang, Laizhong Cui, Mingwei Xu, Y.
Yang, Wei Xiao, 2022-03-21,
<draft-yang-alto-deliver-functions-over-networks-03.txt>

As the rapid development of internet, massive data are produced.

Service providers typically need to deploy services near the edge
networks to better satisfy user_s demand. In order to obtain better
quality of the networks, computing functions and user traffic need to
be scheduled properly. However, it is challenging to efficiently
schedule resources among the distributed edge servers because of the
lack of network information, such as network topology, traffic
distribution, link delay/bandwidth and utilization/capability of
computing servers. In this standard, we employed the ALTO protocol
to help deliver functions and schedule traffic at the edge computing
platform. This protocol supplied information of multiple resources
for the distributed edge computing platform, thus enhancing the
efficiency of function delivery in edge computing platform.

"Operational Considerations for BRSKI Registrar", Michael Richardson, Wei

Pan, 2022-03-06, <draft-richardson-anima-registrar-considerations-05.txt>

This document describes a number of operational modes that a BRSKI

Registration Authority (Registrar) may take on.

Each mode is defined, and then each mode is given a relevance within
an over applicability of what kind of organization the Registrar is
deployed into. This document does not change any protocol
mechanisms.

This document includes operational advice about avoiding unwanted

consequences.

"Operatonal Considerations for Voucher infrastructure for BRSKI MASA",

Michael Richardson, Wei Pan, 2022-07-11,
<draft-richardson-anima-masa-considerations-07.txt>
 This document describes a number of operational modes that a BRSKI
Manufacturer Authorized Signing Authority (MASA) may take on.

Each mode is defined, and then each mode is given a relevance within
an over applicability of what kind of organization the MASA is
deployed into. This document does not change any protocol
mechanisms.

"RPKI validated cache Update in SLURM over HTTPs (RUSH)", Di Ma, Hanbing
Yan, Melchior Aelmans, 2022-05-09, <draft-madi-sidrops-rush-06.txt>

This document defines a method for transferring RPKI validated cache

update information in JSON object format over HTTPs.

"Abstract", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2022-06-17,
<draft-wu-identifier-sln-objects-mapping-05.txt>

This document specifies the format, contents and semantics of data

escrow deposits for Industrial Internet Identifier Second-level Node
(SLN). SLN directly serves enterprises and provides services such as
identifier registration, identifier resolution, data sharing, etc.
The mapping objects in this document mainly refers to the enterprise
registration information of the SLN and the Enterprise-level Node
(ELN) registered in the SLN.

"Abstract", Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan, 2022-06-17,
<draft-industrial-internet-identifier-data-escrow-05.txt>

This document specifies the format and contents of data escrow

deposits targeted primarily for Industrial Internet Identifier Node
(IIIN) which provides identifier registration. However, this
specification was designed to be independent of the underlying
objects that are being escrowed, therefore it could be used for
purposes other than IIIN.

"HTTP Usage in the Industrial Internet Identifier Data Access Protocol

(IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li,
2022-06-19, <draft-ma-identifier-access-http-05.txt>

This document describes an Extensible Provisioning Protocol (EPP)

for the provisioning and management of enterprises and identifiers
between the server which is called Business Management System (BMS)
and is entitled to manage the identifier top-level node and the
client which is also referred to as Second Node Management System
(SNMS). Specified in XML, the mapping defines EPP command syntax and
semantics as applied to enterprise and identifier management.

"Security Services for the Industrial Internet Identifier Data Access

Protocol (IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen,
Zhiping Li, 2022-06-19, <draft-mcd-identifier-access-security-05.txt>

The Industrial Internet Identifier Data Access Protocol (IIIDAP)

provides "RESTful" web services to retrieve identifier metadata from
Second-Level Node (SLN). This document describes information
security services, including access control, authentication,
authorization, availability, data confidentiality, and data
integrity for IIIDAP.

"JSON Responses for the Industrial Internet Identifier Data Access Protocol
(IIIDAP)", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, 2022-06-19,
<draft-mcd-identifier-access-responce-05.txt>

This document describes JSON data structures representing identifier

information maintained by Second-Level Nodes (SLN). These data
structures are used to form Industrial Internet Identifier Data
Access Protocol (IIIDAP) query responses.

"Finding the Authoritative Registration Data (IIIDAP) Service", Chendi Ma,

Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li, 2022-06-19,
<draft-mcd-identifier-access-authority-05.txt>

This document specifies a method to find which Industrial Internet

Identifier Data Access Protocol (IIIDAP) server is authoritative to
answer queries for a request of identifier data.

"Industrial Internet Identifier Data Access Protocol (IIIDAP) Query

Format", Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li,
2022-06-19, <draft-mcd-identifier-access-query-05.txt>

This document describes uniform patterns to construct HTTP URLs that

may be used to retrieve identifier information from Second-Level
Nodes (SLN) using "RESTful" web access patterns. These uniform
patterns define the query syntax for the Industrial Internet
Identifier Data Access Protocol (IIIDAP).

"Resource Allocation Model for Hybrid Switching Networks", Weiqiang Sun,

Junyi Shao, Weisheng Hu, 2022-05-29,
<draft-sun-nmrg-hybrid-switching-05.txt>

The fast increase in traffic volumn within and outside Datacenters is

placing an unprecendented challenge on the underline network, in both
the capacity it can provide, and the way it delivers traffic. When a
large portion of network traffic is contributed by large flows,
providing high capacity and slow to change optical circuit switching
along side fine-granular packet services may potentially improve
network utility and reduce both CAPEX and OpEX. This gives rise to
the concept of hybrid switching - a paradigm that seeks to make the
best of packet and circuit switching.

However, the full potential of hybrid switching networks (HSNs) can

only be realized when such a network is optimally designed and
operated, in the sense that "an appropriate amount of resource is
used to handle an appropriate amount of traffic in both switching
planes." The resource allocation problem in HSNs is in fact complex
ineractions between three components: resource allocation between the
two switching planes, traffic partitioning between the two switching
planes, and the overall cost or performance constraints.

In this memo, we explore the challenges of planning and operating

hybrid switching networks, with a particular focus on the resource
allocation problem, and provide a high-level model that may guide
resource allocation in future hybrid switching networks.

"Inter-domain Network Slicing via BGP-LU", Ran Chen, Chunning Dai, Shaofu
Peng, 2022-03-07, <draft-zhou-idr-inter-domain-lcu-04.txt>

This document aims to solve inter-domain network slicing problems

using existing technologies. It attempts to establish multiple BGP-
 LU LSPs of different colors for a/multiple prefix to stitch multiple
network segments.

"Threshold Modes in Elliptic Curves", Phillip Hallam-Baker, 2022-04-20,

<draft-hallambaker-threshold-07.txt>

Threshold cryptography operation modes are described with application

to the Ed25519, Ed448, X25519 and X448 Elliptic Curves. Threshold
key generation allows generation of keypairs to be divided between
two or more parties with verifiable security guaranties. Threshold
decryption allows elliptic curve key agreement to be divided between
two or more parties such that all the parties must co-operate to
complete a private key agreement operation. The same primitives may
be applied to improve resistance to side channel attacks. A
Threshold signature scheme is described in a separate document.

https://mailarchive.ietf.org/arch/browse/cfrg/
(http://whatever)Discussion of this draft should take place on the
CFRG mailing list (cfrg@irtf.org), which is archived at .

"OSPF Graceful Restart Enhancements", Sami Boutros, Ankur Dubey,

Vijayalaxmi Basavaraj, Acee Lindem, 2022-06-05,
<draft-basavaraj-lsr-ospf-gr-enhancements-05.txt>

This document describes enhancements to the OSPF graceful restart

procedures to improve routing convergence in some OSPF network
deployments. This document updates RFC 3623 and RFC 5187.

"(strong) AuCPace, an augmented PAKE", Bjoern Haase, 2022-07-24,

<draft-haase-aucpace-06.txt>

This document describes AuCPace which is an augmented PAKE protocol

for two parties. The protocol was tailored for constrained devices
and smooth migration for compatibility with legacy user credential
databases. It is designed to be compatible with any group of both
prime- and non-prime order and comes with a security proof providing
composability guarantees.

"Stateless and Scalable Network Slice Identification for SRv6", Clarence

Filsfils, Francois Clad, Pablo Camarillo, Syed Raza, Dan Voyer, Reza Rokui,
2022-07-29, <draft-filsfils-spring-srv6-stateless-slice-id-06.txt>

This document defines a stateless and scalable solution to achieve

network slicing with SRv6.

"SRv6 vSID: Network Programming extension for variable length SIDs", Bruno
Decraene, Robert Raszuk, Zhenbin Li, Cheng Li, 2022-03-07,
<draft-decraene-spring-srv6-vlsid-07.txt>

This document proposes an extension to Segment Routing IPv6 (SRv6)

Network Programming to allow for SRv6 Segment Identifier (SID) of
smaller variable length. The use of smaller SRv6 SID reduces the
size the SRv6 Header (SRH). This reduces the overhead for both the
traffic volume and the network processor. It is a straightforward
extension to the SRv6 Network Programming model and its SRH
encapsulation.

"BGP-LS Extensions for SR Network Resource Partition SIDs", Ran Chen,

Shaofu Peng, Tarek Saad, Vishnu Beeram, 2022-07-11,
<draft-chen-idr-bgp-ls-transport-slice-05.txt>

This document specifies extensions to the BGP Link-state address-

family in order to advertise the information of Network Resource
Partition SIDs. An external component (e.g., a controller) then can
collect Network Resource Partition SIDs in the "northbound"
direction. The draft is applicable to both SR-MPLS and SRv6
dataplanes.

"Lightweight Authorization for Authenticated Key Exchange.", Goeran

Selander, John Mattsson, Malisa Vucinic, Michael Richardson, Aurelio
Schellenbaum, 2022-04-18, <draft-selander-ace-ake-authz-05.txt>

This document describes a procedure for augmenting the lightweight

authenticated Diffie-Hellman key exchange protocol EDHOC with third
party assisted authorization, targeting constrained IoT deployments
(RFC 7228).

"Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol

Version 2 (IKEv2)", Valery Smyslov, 2022-05-04,
<draft-smyslov-ike2-gost-08.txt>

This document defines a set of cryptographic transforms for use in

the Internet Key Exchange protocol version 2 (IKEv2). The transforms
are based on Russian cryptographic standard algorithms (GOST). Using
GOST ciphers in IKEv2 was defined in RFC 9227, this document aims to
define using GOST algorithms for the rest of cryptographic transforms
used in IKEv2.

This specification was developed to facilitate implementations that

wish to support the GOST algorithms. This document does not imply
IETF endorsement of the cryptographic algorithms used in this
document.

"5G End-to-end Network Slice Mapping from the view of Transport Network",
Xuesong Geng, Jie Dong, Ran Pang, Liuyan Han, Reza Rokui, Jaewhan Jin, Jeff
Tantsura, 2022-03-07, <draft-geng-teas-network-slice-mapping-05.txt>

Network Slicing is one of the core features in 5G. End-to-end

network slice consists of 3 major types of network segments: Access
Network (AN), Mobile Core Network (CN) and Transport Network (TN).
This draft describes the procedure of mapping 5G end-to-end network
slice to transport network slice defined in IETF. This draft also
intends to expose some gaps in the existing network management plane
and data plane technologies to support inter-domain network slice
mapping. Further work may require collaboration between IETF and
3GPP (or other standard organizations). Data model specification,
signaling protocol extension and new encapsulation definition are out
of the scope of this draft.

"BGP Extension for SR-MPLS Entropy Label Position", Liu Yao, Shaofu Peng,
2022-06-07, <draft-zhou-idr-bgp-srmpls-elp-05.txt>

This document proposes extensions for BGP to indicate the entropy

label position in the SR-MPLS label stack when delivering SR Policy
via BGP.

"New UUID Formats", Brad Peabody, Kyzer Davis, 2022-06-23,

<draft-peabody-dispatch-new-uuid-format-04.txt>
 This document presents new Universally Unique Identifier (UUID)
formats for use in modern applications and databases.

"Quic Timestamps For Measuring One-Way Delays", Christian Huitema,

2022-08-28, <draft-huitema-quic-ts-08.txt>

The TIMESTAMP frame can be added to Quic packets when one way delay
measurements are useful. The timestamp is set to the number of
microseconds from the beginning of the node's epoch to the time at
which the packet is sent. The draft defines the "enable_timestamp"
transport parameter for negotiating the use of this extension frame,
and the TIMESTAMP frame.

"CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Christian

Amsuess, 2022-07-11, <draft-amsuess-core-coap-over-gatt-02.txt>

Interaction from computers and cell phones to constrained devices is

limited by the different network technologies used, and by the
available APIs. This document describes a transport for the
Constrained Application Protocol (CoAP) that uses Bluetooth GATT
(Generic Attribute Profile) and its use cases.

"Application-aware Networking (APN) Framework", Zhenbin Li, Shuping Peng,

Dan Voyer, Cong Li, Peng Liu, Chang Cao, Gyan Mishra, 2022-03-07,
<draft-li-apn-framework-05.txt>

A multitude of applications are carried over the network, which have

varying needs for network bandwidth, latency, jitter, and packet
loss, etc. Some new emerging applications have very demanding
performance requirements. However, in current networks, the network
and applications are decoupled, that is, the network is not aware of
the applications' requirements in a fine granularity. Therefore, it
is difficult to provide truly fine-granularity traffic operations for
the applications and guarantee their SLA requirements.

This document proposes a new framework, named Application-aware

Networking (APN), where application-aware information (i.e. APN
attribute) including APN identification (ID) and/or APN parameters
(e.g. network performance requirements) is encapsulated at network
edge devices and carried in packets traversing an APN domain in order
to facilitate service provisioning, perform fine-granularity traffic
steering and network resource adjustment.

"Problem Statement and Use Cases of Application-aware Networking (APN)",

Zhenbin Li, Shuping Peng, Dan Voyer, Chongfeng Xie, Peng Liu, Zhuangzhuang
Qin, Gyan Mishra, 2022-03-07,
<draft-li-apn-problem-statement-usecases-06.txt>

Network operators are facing the challenge of providing better

network services for users. As the ever-developing 5G and industrial
verticals evolve, more and more services that have diverse network
requirements such as ultra-low latency and high reliability are
emerging, and therefore differentiated service treatment is desired
by users. On the other hand, as network technologies such as
Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep
evolving, the network has the capability to provide more fine-
granularity differentiated services. However, network operators are
typically unware of the applications that are traversing their
 network infrastructure, which means that not very effective
differentiated service treatment can be provided to the traffic
flows. As network technologies evolve including deployments of IPv6,
SRv6, Segment Routing over MPLS dataplane, the programmability
provided by IPv6 and Segment Routing can be augmented by conveying
application related information into the network satifying the fine-
granularity requirements.

This document analyzes the existing problems caused by lack of

service awareness, and outlines various use cases that could benefit
from an Application-aware Networking (APN) framework.

"Bootstrapped TLS Authentication", Owen Friel, Dan Harkins, 2022-05-26,

<draft-friel-tls-eap-dpp-05.txt>

This document defines a TLS extension that enables a server to prove

to a client that it has knowledge of the public key of a key pair
where the client has knowledge of the private key of the key pair.
Unlike standard TLS key exchanges, the public key is never exchanged
in TLS protocol messages. Proof of knowledge of the public key is
used by the client to bootstrap trust in the server. The use case
outlined in this document is to establish trust in an EAP server.

"A User-Focused Internet Threat Model", Dominique Lazanski, 2022-07-03,

<draft-lazanski-users-threat-model-t-05.txt>

RFC 3552 introduces a threat model that does not include endpoint
security. Yet increasingly protocol development is making assumptions
about endpoint security capabilities which have not been defined. RFC
3552 is 17 years old and threat landscape has changed. Security issues
and cyber attacks have increased and there are more devices, users, and
applications on the endpoint than ever. This draft proposes a new
approach to the Internet threat model which will include endpoint
security, focus on users and provide an update to the threat model in
RFC 3552. It brings together Security Considerations for Protocol
Designers draft-lazanski-protocol-sec-design-model-t-05 which is a
comprehensive document that lists threats, attack vectors, examples and
considerations for designing protocols, as well as draft-taddei-smart-
cless-introduction-03 which lays out security concerns, capabilities
and limitations for endpoints in general and draft-mcfadden-smart-
endpoint-taxonomy-for-cless-02 which outlines a clear taxonomy for
endpoint security and identifies changes in technology, economic and
protocol development that has impacted and changed endpoint security.
Taken together these drafts reflect a comprehensive and clear set of
security threats and design considerations for the Internet.

"No Further Fast Reroute", Kireeti Kompella, Wen Lin, 2022-07-08,

<draft-kompella-mpls-nffrr-03.txt>

There are several cases where, once Fast Reroute has taken place (for
MPLS protection), a second fast reroute is undesirable, even
detrimental. This memo gives several examples of this, and proposes
a mechanism to prevent further fast reroutes.

"BGP for Network High Availability", Huaimo Chen, Yanhe Fan, Aijun Wang,
Lei Liu, Xufeng Liu, 2022-03-20, <draft-chen-idr-ctr-availability-04.txt>

This document describes protocol extensions to BGP for improving the

reliability or availability of a network controlled by a controller
 cluster.

"PCE for Network High Availability", Huaimo Chen, Aijun Wang, Lei Liu,
Xufeng Liu, 2022-03-20, <draft-chen-pce-ctr-availability-04.txt>

This document describes extensions to Path Computation Element (PCE)

communication Protocol (PCEP) for improving the reliability or
availability of a network controlled by a controller cluster.

"IGP for Network High Availability", Huaimo Chen, Mehmet Toy, Aijun Wang,
Lei Liu, Xufeng Liu, 2022-03-20, <draft-chen-lsr-ctr-availability-04.txt>

This document describes protocol extensions to OSPF and IS-IS for

improving the reliability or availability of a network controlled by
a controller cluster.

"An Architecture for Network Function Interconnect", Colin Bookham, Andrew

Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene, 2022-07-06,
<draft-bookham-rtgwg-nfix-arch-05.txt>

The emergence of technologies such as 5G, the Internet of Things

(IoT), and Industry 4.0, coupled with the move towards network
function virtualization, means that the service requirements demanded
from networks are changing. This document describes an architecture
for a Network Function Interconnect (NFIX) that allows for
interworking of physical and virtual network functions in a unified
and scalable manner across wide-area network and data center domains
while maintaining the ability to deliver against SLAs.

"Redundancy Policy for Redundancy Protection", Fan Yang, Xuesong Geng,

Tianran Zhou, Gyan Mishra, 2022-07-24,
<draft-geng-spring-redundancy-policy-04.txt>

This document introduces a variant of SR Policy called Redundancy

Policy, in order to instruct the replication of service packets and
assign more than one redundancy forwarding paths used for redundancy
protection.

"Distributed SFC control operation", Carlos Bernardos, Alain Mourad,

2022-03-21, <draft-bernardos-sfc-distributed-control-operation-04.txt>

Service function chaining (SFC) allows the instantiation of an

ordered set of service functions and subsequent "steering" of traffic
through them. In order to set up and maintain SFC instances, a
control plane is required, which typically is centralized. In
certain environments, such as fog computing ones, such centralized
control might not be feasible, calling for distributed SFC control
solutions. This document describes a general framework for
distributed SFC operation.

"NSH extensions for local distributed SFC control", Carlos Bernardos, Alain
Mourad, 2022-03-21, <draft-bernardos-sfc-nsh-distributed-control-04.txt>

Service function chaining (SFC) allows the instantiation of an

ordered set of service functions and subsequent "steering" of traffic
through them. In order to set up and maintain SFC instances, a
control plane is required, which typically is centralized. In
certain environments, such as fog computing ones, such centralized
control might not be feasible, calling for distributed SFC control
 solutions. This document specifies several NSH extensions to provide
in-band SFC control signaling.

"SFC function mobility with Mobile IPv6", Carlos Bernardos, Alain Mourad,
2022-03-21, <draft-bernardos-dmm-sfc-mobility-04.txt>

Service function chaining (SFC) allows the instantiation of an

ordered set of service functions and subsequent "steering" of traffic
through them. In order to set up and maintain SFC instances, a
control plane is required, which typically is centralized. In
certain environments, such as fog computing ones, such centralized
control might not be feasible, calling for distributed SFC control
solutions. This document specifies Mobile IPv6 extensions to enable
function migration in SFC.

"Using Flex-Algo for Segment Routing (SR) based Virtual Transport Network
(VTN)", Yongqing Zhu, Jie Dong, Zhibo Hu, 2022-07-11,
<draft-zhu-lsr-isis-sr-vtn-flexalgo-05.txt>

Enhanced VPN (VPN+) aims to provide enhanced VPN service to support

some application's needs of enhanced isolation and stringent
performance requirements. VPN+ requires integration between the
overlay VPN connectivity and the characteristics provided by the
underlay network. A Virtual Transport Network (VTN) is a virtual
underlay network which has a customized network topology and a set of
network resources allocated from the physical network. A VTN could
be used as the underlay for one or a group of VPN+ services.

The topological constraints of a VTN can be defined using Flex-Algo,

a mechanism to provide distributed constraint-path computation. In
some network scenarios, each VTN can be associated with a unique
Flex-Algo, and the set of network resources allocated to a VTN can be
instantiated as layer-2 sub-interfaces or member links of the layer-3
interfaces. This document describes the mechanisms to build the
Segment Routing (SR) based VTNs using SR Flex-Algo and IGP L2 bundles
with minor extensions. This document updates RFC 8668 by defining a
new flag in the Parent L3 Neighbor Descriptor in the L2 Bundle Member
Attributes TLV.

"Security Considerations for Protocol Designers", Dominique Lazanski,

2022-07-03, <draft-lazanski-protocol-sec-design-model-t-05.txt>

This document is a non-exhaustive set of considerations for protocol

designers and implementers with regards to attack defence. This
document follows on from the way forward outlined in draft-lazanski-
users-threat-model-t-04. These considerations both supplement and
support the work on threat models. They can be used as an aid to
analyse protocol design choice and in turn to help combat threats
and defend users of these protocols and systems against malicious
attacks.

First, we list well-known classes of attacks that pose threats, with

relevant case studies and descriptions. Next, we give a list of
defence measures against these attacks to be considered when
designing and deploying protocols. Naturally, deployments of
protocols vary greatly between use cases; therefore, some attacks
and defensive measures outlined may require more consideration than
others, dependent on use case.
 This RFC can be used by protocol designers to write the Security
Considerations section in an RFC. The impact on attack defence of a
protocol should be considered in multiple use cases across the
multiple layers of the internet. Defence against malicious attacks
can be improved and it can be weakened by design features of
protocols. Designers should acknowledge the role of protocols in
attack prevention, detection and mitigation; this document aims to
be a useful guide in doing so.

"Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic",

Zongpeng Du, Peng Liu, 2022-07-07,
<draft-du-detnet-layer3-low-latency-05.txt>

It is complex to support deterministic forwarding in a large scale

network because there is too much dynamic traffic in the network and
the data model becomes hard to predict after traffic aggregation on
the intermediate nodes. This document introduces the problem of
micro-bursts in the layer3 network, and analyses the method to
decrease the micro-bursts in layer3 network for low-latency traffic.

"Forwarding Layer Problem Statement", Stewart Bryant, Uma Chunduri,

Toerless Eckert, Alexander Clemm, 2022-08-05,
<draft-bryant-arch-fwd-layer-ps-05.txt>

This document considers the problems that need to addressed in IP in

order to address the use cases and new network services described in
draft-bryant-arch-fwd-layer-uc-00.

"MoWIE for Network Aware Applications", Yuhang Jia, Yunfei Zhang, Richard
Yang, Gang Li, Yixue Lei, Yunbo Han, Sabine Randriamasy, 2022-07-11,
<draft-huang-alto-mowie-for-network-aware-app-04.txt>

With the quick deployment of 5G networks in the world, cloud-based

interactive applications (services) such as cloud gaming have gained
substantial attention and are regarded as potential killer
applications. To ensure users' quality of experience (QoE), a cloud
interactive service may require not only high bandwidth (e.g., high-
resolution media transmission) but also low delay (e.g., low latency
and low lagging). However, the bandwidth and delay experienced by a
mobile and wireless user can be dynamic, as a function of many
factors, and unhandled changes can substantially compromise the
user's QoE. In this document, we investigate network-aware
applications (NAA), which realize cloud based interactive services
with improved QoE, by efficient utilization of a solution named
Mobile and Wireless Information Exposure (MoWIE). In particular,
this document demonstrates, through realistic evaluations, that
mobile network information such as MCS (Modulation and Coding Scheme)
can effectively expose the dynamicity of the underlying network and
can be made available to applications through MoWIE; using such
information, the applications can then adapt key control knobs such
as media codec scheme, encapsulation, and application layer
processing to minimize QoE deduction. Based on the evaluations, we
discuss how the MoWIE features can define extensions of the ALTO
protocol, to expose more lower-layer and finer grain network
dynamics.

"Connection-oriented Path in SRv6 Network", Zongpeng Du, Peng Liu,

2022-07-05, <draft-du-spring-connection-oriented-srv6-02.txt>
 This document proposes a method to support connection-oriented path
in the SRv6 network. Two related SRv6 Functions need to be supported
on each node along the connection-oriented path.

"SPAKE2+, an Augmented PAKE", Tim Taubert, Christopher Wood, 2022-05-05,

<draft-bar-cfrg-spake2plus-08.txt>

This document describes SPAKE2+, a Password Authenticated Key

Exchange (PAKE) protocol run between two parties for deriving a
strong shared key with no risk of disclosing the password. SPAKE2+
is an augmented PAKE protocol, as only one party has knowledge of the
password. This method is simple to implement, compatible with any
prime order group and is computationally efficient.

This document was produced outside of the IETF and IRTF, and
represents the opinions of the authors. Publication of this document
as an RFC in the Independent Submissions Stream does not imply
endorsement of SPAKE2+ by the IETF or IRTF.

"Proxy Operations for CoAP Group Communication", Marco Tiloca, Esko Dijk,
2022-03-07, <draft-tiloca-core-groupcomm-proxy-06.txt>

This document specifies the operations performed by a proxy, when

using the Constrained Application Protocol (CoAP) in group
communication scenarios. Such a proxy processes a single request
sent by a client over unicast, and distributes the request over IP
multicast to a group of servers. Then, the proxy collects the
individual responses from those servers and relays those responses
back to the client, in a way that allows the client to distinguish
the responses and their origin servers through embedded addressing
information. This document updates RFC7252 with respect to caching
of response messages at proxies.

"BGP Well Known Large Community", Jakob Heitz, Kotikalapudi Sriram, Brian
Dickson, John Heasley, 2022-03-07, <draft-heitz-idr-wklc-04.txt>

A range of BGP Autonomous System Numbers is reserved to create a set

of BGP Well Known Large Communities.

"Abstract", Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li, 2022-06-17,
<draft-wu-identifier-data-escrow-interface-05.txt>

This document describes the Data Escrow report requirement and

technical details of the interfaces provides by the Top-level Node
(TLN) to its contracted parties. Second-level Node (SLN) MUST
periodically send data escrow report to Top-level Node (TLN) and
Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN
and SLN after processing the report.

"Crowd Sourced Remote ID", Robert Moskowitz, Stuart Card, Adam

Wiethuechter, Shuai Zhao, Henk Birkholz, 2022-05-10,
<draft-moskowitz-drip-crowd-sourced-rid-08.txt>

This document describes using the ASTM Broadcast Remote ID (B-RID)

specification in a "crowd sourced" smart phone environment to provide
much of the ASTM and FAA envisioned Network Remote ID (Net-RID)
functionality. This crowd sourced B-RID (CS-RID) data will use
multilateration to add a level of reliability in the location data on
the Unmanned Aircraft (UA). The crowd sourced environment will also
 provide a monitoring coverage map to authorized observers.

"UAS Operator Privacy for RemoteID Messages", Robert Moskowitz, Stuart

Card, Adam Wiethuechter, 2022-04-08,
<draft-moskowitz-drip-operator-privacy-10.txt>

This document describes a method of providing privacy for UAS

Operator/Pilot information specified in the ASTM UAS Remote ID and
Tracking messages. This is achieved by encrypting, in place, those
fields containing Operator sensitive data using a hybrid ECIES.

"Reflexive Forwarding for CCNx and NDN Protocols", David Oran, Dirk
Kutscher, 2022-06-06, <draft-oran-icnrg-reflexive-forwarding-03.txt>

Current Information-Centric Networking protocols such as CCNx and NDN

have a wide range of useful applications in content retrieval and
other scenarios that depend only on a robust two-way exchange in the
form of a request and response (represented by an _Interest-Data
exchange_ in the case of the two protocols noted above). A number of
important applications however, require placing large amounts of data
in the Interest message, and/or more than one two-way handshake.
While these can be accomplished using independent Interest-Data
exchanges by reversing the roles of consumer and producer, such
approaches can be both clumsy for applications and problematic from a
state management, congestion control, or security standpoint. This
specification proposes a _Reflexive Forwarding_ extension to the CCNx
and NDN protocol architectures that eliminates the problems inherent
in using independent Interest-Data exchanges for such applications.
It updates RFC8569 and RFC8609.

"Secure UAS Network RID and C2 Transport", Robert Moskowitz, Stuart Card,
Adam Wiethuechter, Andrei Gurtov, 2022-07-23,
<draft-moskowitz-drip-secure-nrid-c2-11.txt>

This document defines a transport mechanism for Unmanned Aircraft

System (UAS) Network Remote ID (Net-RID). The Broadcast Remote ID
(B-RID) messages can be sent directly over UDP or via a more
functional protocol using CoAP/CBOR for the Net-RID messaging. This
is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure
messaging Command-and-Control (C2) for is also described.

"QUIC Version Aliasing", Martin Duke, 2022-04-28,

<draft-duke-quic-version-aliasing-08.txt>

The QUIC transport protocol preserves its future extensibility partly

by specifying its version number. There will be a relatively small
number of published version numbers for the foreseeable future. This
document provides a method for clients and servers to negotiate the
use of other version numbers in subsequent connections and encrypts
Initial Packets using secret keys instead of standard ones. If a
sizeable subset of QUIC connections use this mechanism, this should
prevent middlebox ossification around the current set of published
version numbers and the contents of QUIC Initial packets, as well as
improving the protocol's privacy properties.

"LTP Fragmentation", Fred Templin, 2022-07-25,

<draft-templin-dtn-ltpfrag-09.txt>

The Licklider Transmission Protocol (LTP) provides a reliable

 datagram convergence layer for the Delay/Disruption Tolerant
Networking (DTN) Bundle Protocol. In common practice, LTP is often
configured over UDP/IP sockets and inherits its maximum segment size
from the maximum-sized UDP/IP datagram, however when this size
exceeds the maximum IP packet size for the path a service known as IP
fragmentation must be employed. This document discusses LTP
interactions with IP fragmentation and mitigations for managing the
amount of IP fragmentation employed.

"Optimizing ACK mechanism for QUIC", Tong Li, Kai Zheng, Rahul Jadhav, Jiao
Kang, 2022-05-12, <draft-li-quic-optimizing-ack-in-wlan-04.txt>

The dependence on frequent acknowledgments (ACKs) is an artifact of

current transport protocol designs rather than a fundamental
requirement. This document analyzes the problems caused by
contentions and collisions on wireless medium between data packets
and ACKs in WLAN and it proposes an ACK mechanism that minimizes the
intensity of ACK Frame in QUIC, improving the performance of
transport layer connection.

"Use Identity as Raw Public Key in EAP-TLS", chenmeiling, Li Su, Haiguang

Wang, 2022-07-08, <draft-chen-emu-eap-tls-ibs-04.txt>

This document specifies the use of identity as a raw public key in

EAP-TLS, EAP-TLS for TLS1.2 is defined in RFC 5216 and EAP-TLS for
TLS1.3 is defined in the draft draft-ietf-emu-eap-tls13 and draft-
ietf-tls-dtls13. The procedures of EAP-TIBS will consistent with
EAP-TLS's interactive process, Identity-based signature will be
extended to support EAP-TLS's signature algorithms.

"Notable CBOR Tags", Carsten Bormann, 2022-07-11,

<draft-bormann-cbor-notable-tags-07.txt>

The Concise Binary Object Representation (CBOR, RFC 8949) is a data

format whose design goals include the possibility of extremely small
code size, fairly small message size, and extensibility without the
need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags.

RFC 8949's original edition, RFC 7049, defined a basic set of tags as
well as a registry that can be used to contribute additional tag
definitions [IANA.cbor-tags]. Since RFC 7049 was published, some 80
tag definitions have been added to that registry.

The present document provides a roadmap to a large subset of these

tag definitions. Where applicable, it points to a IETF standards or
standard development document that specifies the tag. Where no such
document exists, the intention is to collect specification
information from the sources of the registrations. After some more
development, the present document is intended to be useful as a
reference document for the IANA registrations of the CBOR tags the
definitions of which have been collected.

"Generalized SRv6 Network Programming for SRv6 Compression", Weiqiang

Cheng, Zhenbin Li, Cheng Li, Francois Clad, Aihua Liu, Chongfeng Xie,
Yisong Liu, Shay Zadok, 2022-04-24,
<draft-cl-spring-generalized-srv6-for-cmpr-05.txt>

This document proposes Generalized Segment Routing over IPv6 (G-SRv6)

 Networking Programming for SRv6 compression.

G-SRv6 can reduce the overhead of SRv6 by encoding the Generalized

SIDs(G-SID) in SID list, and it also supports to program SRv6 SIDs
and G-SIDs in a single SRH to support incremental deployment and
smooth upgrade.

G-SRv6 is fully compatible with SRv6 with no modification of SRH, no

new address consumption, no new route creation, and even no
modification of control plane.

G-SRv6 for Compression is designed based on the Compressed SRv6

Segment List Encoding in SRH
[I-D.filsfilscheng-spring-srv6-srh-compression] framework.

"A Simple LISP NAT-Traversal Implementation", Dino Farinacci, 2022-05-01,

<draft-farinacci-lisp-simple-nat-04.txt>

This informational draft documents the lispers.net LISP NAT-Traversal

implementation.

"Defined Resource Operator (drop) The 'drop' URI Scheme", Tim McSweeney,
2022-08-15, <draft-mcsweeney-drop-scheme-05.txt>

This document describes the 'drop' Uniform Resource

Identifier (URI) scheme.

"The GNU Name System", Martin Schanzenbach, Christian Grothoff, Bernd Fix,
2022-08-07, <draft-schanzen-gns-21.txt>

This document contains the GNU Name System (GNS) technical

specification. GNS is a decentralized and censorship-resistant
domain name resolution protocol that provides a privacy-enhancing
alternative to the Domain Name System (DNS) protocols.

This document defines the normative wire format of resource records,

resolution processes, cryptographic routines and security
considerations for use by implementers.

This specification was developed outside the IETF and does not have
IETF consensus. It is published here to inform readers about the
function of GNS, guide future GNS implementations, and ensure
interoperability among implementations including with the pre-
existing GNUnet implementation.

"Advertising SID Algorithm Information in BGP", Liu Yao, Shaofu Peng,

2022-06-05, <draft-peng-idr-segment-routing-te-policy-attr-03.txt>

This document proposes extensions of BGP and defines some new Segment
Types with algorithm information to meet more requirements when
delivering SR Policy via BGP.

"Identity Module for TLS Version 1.3", Pascal Urien, 2022-07-29,

<draft-urien-tls-im-07.txt>

TLS 1.3 will be deployed in the Internet of Things ecosystem. In

many IoT frameworks, TLS or DTLS protocols, based on pre-shared key
(PSK), are used for device authentication. So PSK tamper resistance,
is a critical market request, in order to prevent hijacking issues.
 If DH exchange is used with certificate bound to DH ephemeral public
key, there is also a benefit to protect its signature procedure. The
TLS identity module (im) MAY be based on secure element; it realizes
some HKDF operations bound to PSK, and cryptographic signature if
certificates are used. Secure Element form factor could be
standalone chip, or embedded in SoC like eSIM.

"Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt

Larson, Paul Hoffman, 2022-05-19, <draft-klh-dnsop-rfc8109bis-04.txt>

This document describes the queries that a DNS resolver should emit
to initialize its cache. The result is that the resolver gets both a
current NS Resource Record Set (RRset) for the root zone and the
necessary address information for reaching the root servers.

This document, when published, obsoletes RFC 8109.

"Multipath TCP Extension for Robust Session Establishment", Markus Amend,

Jiao Kang, 2022-03-07, <draft-amend-tcpm-mptcp-robe-02.txt>

Multipath TCP extends the plain, single-path limited, TCP towards the
capability of multipath transmission. This greatly improves the
reliability and performance of TCP communication. For backwards
compatibility reasons the Multipath TCP was designed to setup
successfully an initial path first, after which subsequent paths can
be added for multipath transmission. For that reason the Multipath
TCP has the same limitations as the plain TCP during connection
setup, in case the selected path is not functional.

This document proposes a set of implementations and possible

combinations thereof, that provide a more Robust Establishment (RobE)
of MPTCP sessions. It includes RobE_TIMER, RobE_SIM, RobE_eSIM and
RobE_IPS.

RobE_TIMER is designed to stay close to MPTCP in that standard

functionality is used wherever possible. Resiliency against network
outages is achieved by modifying the SYN retransmission timer: If one
path is defective, another path is used.

RobE_SIM and RobE_eSIM provides the ability to simultaneously use

multiple paths for connection setup. They ensure connectivity if at
least one functional path out of a bunch of paths is given and offers
beside that the opportunity to significantly improve loading times of
Internet services.

RobE_IPS provides a heuristic to select properly an initial path for

connection establishment with a remote host based on empirical data
derived from previous connection information.

In practice, these independent solutions can be complementary used.

This document also presents the design and protocol procedure for
those combinations in addition to the respective stand-alone
solutions.

"Distributed Ledger Time-Stamp", Emanuele Cisbani, Daniele Ribaudo,

Giuseppe Damiano, 2022-05-27, <draft-intesigroup-dlts-04.txt>

This document defines a standard to extend Time Stamp Tokens with

Time Attestations recorded on Distributed Ledgers.
 The aim is to provide long-term validity to Time Stamp Tokens,
backward compatible with currently available software.

"Self-configuring Stub Networks: Problem Statement", Ted Lemon, 2022-04-25,

<draft-lemon-stub-networks-ps-02.txt>

IETF currently provides protocols for automatically connecting single

hosts to existing network infrastructure. This document describes a
related problem: the problem of connecting a stub network (a
collection of hosts behind a router) automatically to existing
network infrastructure in the same manner.

"Stateless SRv6 Point-to-Multipoint Path", Huaimo Chen, Mike McBride, Yanhe

Fan, Zhenbin Li, Xuesong Geng, Mehmet Toy, Gyan Mishra, Aijun Wang, Lei
Liu, Xufeng Liu, 2022-04-30, <draft-chen-pim-srv6-p2mp-path-06.txt>

This document describes a solution for a SRv6 Point-to-Multipoint

(P2MP) Path/Tree to deliver the traffic from the ingress of the path
to the multiple egresses/leaves of the path in a SR domain. There is
no state stored in the core of the network for a SR P2MP path like a
SR Point-to-Point (P2P) path in this solution.

"MPLS-based Service Function Path(SFP) Consistency Verification", Liu Yao,

Greg Mirsky, 2022-06-11, <draft-lm-mpls-sfc-path-verification-03.txt>

This document describes extensions to MPLS LSP ping mechanisms to

support verification between the control/management plane and the
data plane state for SR-MPLS service programming and MPLS-based NSH
SFC.

This document defines the signaling of the Generic Associated Channel

(G-ACh) over a Service Function Path (SFP) with an MPLS forwarding
plane using the basic unit defined in RFC 8595. The document updates
RFC 8595 in respect to SFF's handling TTL expiration. The document
also describes the processing of the G-ACh by the elements of the
SFP.

"Principles for the Involvement of Intermediaries in Internet Protocols",

Martin Thomson, 2022-03-07, <draft-thomson-tmi-03.txt>

This document proposes a set of principles for designing protocols

with rules for intermediaries. The goal of these principles is to
limit the ways in which intermediaries can produce undesirable
effects and to protect the useful functions that intermediaries
legitimately provide.

"Seamless SR Problem Statement", Shraddha Hegde, Chris Bowers, Xiaohu Xu,

Arkadiy Gulko, Alex Bogdanov, Jim Uttaro, Luay Jalil, Mazen Khaddam, Andrew
Alston, Luis Contreras, 2022-07-08,
<draft-hegde-spring-mpls-seamless-sr-07.txt>

This draft documents a set of use cases and requirements for end-to-
end intent-based paths spanning multi-domain packet networks. The
document explicitly focuses on use cases that require high scale and
availability, which will likely benefit from distributed solutions.
It is intended that the requirements in this document serve as a
basis for future IETF work to develop distributed solutions for
inter-domain intent-based transport paths.
"TCP ACK Rate Request Option", Carles Gomez, Jon Crowcroft, 2022-07-09,
<draft-gomez-tcpm-ack-rate-request-05.txt>

TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism

that allows reducing protocol overhead in many scenarios. However,
Delayed ACKs may also contribute to suboptimal performance. When a
relatively large congestion window (cwnd) can be used, less frequent
ACKs may be desirable. On the other hand, in relatively small cwnd
scenarios, eliciting an immediate ACK may avoid unnecessary delays
that may be incurred by the Delayed ACKs mechanism. This document
specifies the TCP ACK Rate Request (TARR) option. This option allows
a sender to request the ACK rate to be used by a receiver, and it
also allows to request immediate ACKs from a receiver.

"Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM)
Data", Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos
Pignataro, 2022-07-25, <draft-xzlnp-bier-ioam-04.txt>

In-situ Operations, Administration, and Maintenance (IOAM) records

operational and telemetry information in the packet while the packet
traverses a path in the network. Bit Index Explicit Replication
(BIER) is an architecture that provides optimal multicast forwarding
through a "multicast domain", without requiring intermediate routers
to maintain any per-flow state or to engage in an explicit tree-
building protocol. The BIER header contains a bit-string in which
each bit represents exactly one egress router to forward the packet
to. This document outlines the requirements to carry IOAM data in
BIER header and specifies how IOAM data fields are encapsulated in
BIER header.

"Traffic Steering using BGP Flowspec with SRv6 Policy", Jiang Wenying,
Yisong Liu, Shuanglong Chen, Shunwan Zhuang, 2022-03-23,
<draft-jiang-idr-ts-flowspec-srv6-policy-07.txt>

BGP Flow Specification (FlowSpec) [RFC8955] [RFC8956] has been

proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to
mitigate (distributed) denial-of-service attacks, and to provide
traffic filtering in the context of a BGP/MPLS VPN service.
Recently, traffic steering applications in the context of SRv6 using
FlowSpec aslo attract attention. This document introduces the usage
of BGP FlowSpec to steer packets into an SRv6 Policy.

"Accurate Data Scheduling by Server in MPTCP", Jiao Kang, liangqiandeng,

Shangling Deng, 2022-06-16,
<draft-kang-tcpm-accurate-data-scheduling-by-server-03.txt>

This document defines a new mechanism that enables MPTCP server to

send requests to MPTCP client for data scheduling between specified
subflows during a MPTCP session.

"Signal Degrade Indication in Segment Routing over MPLS Network", Liuyan

Han, Fan Yang, Junfeng Zhao, 2022-07-07, <draft-han-mpls-sdi-sr-03.txt>

This document describes a typical use case of MPLS-TP, where signal

degrade defect needs to be correctly detected and transmitted via OAM
messages within network. When MPLS-TP evolves to Segment Routing
MPLS, transit node has no knowledge of labels to be encapsulated in
MPLS label stack. Transit node cannot spread OAM messages with
 signal degrade defect indication. Thus, a solution is proposed in
this draft.

"Forwarding Layer Use Cases", Stewart Bryant, Uma Chunduri, Toerless

Eckert, Alexander Clemm, 2022-08-06, <draft-bryant-arch-fwd-layer-uc-04.txt>

This document considers the new and emerging use cases for IP. These
use cases are difficult to address with IP in its current format and
demonstrate the need to evolve the protocol.

"A YANG Data Model for MPLS-TE Topology", Italo Busi, Aihua Guo, Xufeng
Liu, Tarek Saad, Rakesh Gandhi, 2022-04-28,
<draft-busizheng-teas-yang-te-mpls-topology-03.txt>

This document describes a YANG data model for Multi-Protocol Label

Switching (MPLS) with Traffic Engineering (MPLS-TE) networks.

"YANG Data Model for MPLS LSP Ping", Nagendra Nainar, Carlos Pignataro,
Madhan Sankaranarayanan, Guangying Zheng, 2022-07-30,
<draft-nainar-mpls-lsp-ping-yang-03.txt>

This document describes the YANG data model for Multi-Protocol Label
Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined
in RFC 7950 and conforms to the Network Management Datastore
Architecture (NMDA) as described in RFC 8342.

"Cacheable OSCORE", Christian Amsuess, Marco Tiloca, 2022-07-11,

<draft-amsuess-core-cachable-oscore-05.txt>

Group communication with the Constrained Application Protocol (CoAP)

can be secured end-to-end using Group Object Security for Constrained
RESTful Environments (Group OSCORE), also across untrusted
intermediary proxies. However, this sidesteps the proxies' abilities
to cache responses from the origin server(s). This specification
restores cacheability of protected responses at proxies, by
introducing consensus requests which any client in a group can send
to one server or multiple servers in the same group.

"AS Hijack Detection and Mitigation", Kotikalapudi Sriram, Doug Montgomery,

2022-07-10, <draft-sriram-sidrops-as-hijack-detection-04.txt>

This document proposes a method for detection and mitigation of AS

hijacking. In this mechanism, an AS operator registers a new object
in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is
digitally signed using the AS holder's certificate. By registering a
REAP object, the AS operator is declaring that they have Route Origin
Authorization (ROA) coverage for all prefixes originated by their AS.
A receiving AS will mark a route as Invalid if the prefix is not
covered by any Validated ROA Payload (VRP) and the route origin AS
has signed a REAP. Here Invalid means that the route is determined
to be an AS hijack.

"Autonomic Control Plane design for Layer-Two Switched Networks", Michael

Richardson, Wei Pan, 2022-07-11,
<draft-richardson-anima-l2-friendly-acp-03.txt>

This document proposes a design for an L2 aware Autonomic Control

Plane that can be deployed easily to layer-two (Ethernet) switched
technologies that are common on Campus/Enterprise network
 architectures.

This document leverages the hop-by-hop announcement used in LLDP, but

runs bulk data over normal IPv6 Link-Local unicast ethernet frames.

"IP Flow Information Export (IPFIX) Information Elements Extension for

Forwarding Exceptions", Venkata Munukutla, Shivam Vaid, Aditya Mahale,
Devang Patel, 2022-08-09, <draft-mvmd-opsawg-ipfix-fwd-exceptions-05.txt>

This draft proposes new Forwarding exceptions related

Information Elements (IEs) and Templates for the IP Flow Information
Export (IPFIX) protocol. These new Information Elements and
Exception Template can be used to export information about any
forwarding errors in a network. This essential information is
adequate to correlate packet drops to any control plane entity and
map it to an impacted service. Once exceptions are correlated to a
particular entity, an action can be assigned to mitigate such
problems essentially enabling self-driving networks.

"SVG Tiny Portable/Secure", Alex Brotman, J. Adams, 2022-04-10,

<draft-svg-tiny-ps-abrotman-03.txt>

This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A

Scalable Vector Graphics (SVG) profile to be used with documents that
are intended for use with more secure requirements, and in some
cases, in conjunction with a limited rendering engine.

"Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman

over COSE (EDHOC)", Eduardo Sanchez, Dan Garcia-Carrillo, Rafael
Marin-Lopez, Goeran Selander, John Mattsson, 2022-07-11,
<draft-ingles-eap-edhoc-02.txt>

The Extensible Authentication Protocol (EAP), defined in RFC 3748,

provides a standard mechanism for support of multiple authentication
methods. This document specifies the use of EAP-EDHOC with Ephemeral
Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight
authenticated Diffie-Hellman key exchange with ephemeral keys, using
COSE (RFC 8152) to provide security services efficiently encoded in
CBOR (RFC 8949). This document also provides guidance on
authentication and authorization for EAP-EDHOC.

"Fault Management Mechanism in MPTCP Session", Jiao Kang, liangqiandeng,

Shangling Deng, 2022-06-16,
<draft-kang-tcpm-fault-management-in-mptcp-session-01.txt>

This document presents a mechanism for fault management during a

MPTCP session. It is used to convey subflow failure information from
client to server by other subflow running normally. It includes: 1)
a new Fault Announce Option for describing subflow failure, 2)
implementation and interoperability of this option during a MPTCP
session when one subflow suffers a failure. In fact, the server is
able to determine network problems accurately based on these fault
information reported from multiple clients for their connections.

"A Taxonomy of operational security considerations for manufacturer

installed keys and Trust Anchors", Michael Richardson, 2022-08-16,
<draft-richardson-t2trg-idevid-considerations-07.txt>

This document provides a taxonomy of methods used by manufacturers of

 silicon and devices to secure private keys and public trust anchors.
This deals with two related activities: how trust anchors and private
keys are installed into devices during manufacturing, and how the
related manufacturer held private keys are secured against
disclosure.

This document does not evaluate the different mechanisms, but rather
just serves to name them in a consistent manner in order to aid in
communication.

RFCEDITOR: please remove this paragraph. This work is occurring in

https://github.com/mcr/idevid-security-considerations

"Usage scenarios of Application-aware Networking (APN) for SD-WAN", Feng

Yang, Weiqiang Cheng, Shuping Peng, Zhenbin Li, 2022-07-06,
<draft-yang-apn-sd-wan-usecase-05.txt>

This document describes the usage of Application-aware Networking

(APN) in SD-WAN scenarios. In these scenarios, APN is able to
identify a application group, steer its traffic flows along explicit
path across the network, and provide SLA guaranteed network services
such as low latency and high reliability.

"Secure Element for TLS Version 1.3", Pascal Urien, 2022-03-27,

<draft-urien-tls-se-04.txt>

This draft presents ISO7816 interface for TLS1.3 stack running in

secure element. It presents supported cipher suites and key exchange
modes, and describes embedded software architecture. TLS 1.3 is the
de facto security stack for emerging Internet of Things (IoT)
devices. Some of them are constraint nodes, with limited computing
resources. Furthermore cheap System on Chip (SoC) components usually
provide tamper resistant features, so private or pre shared keys are
exposed to hacking. According to the technology state of art, some
ISO7816 secure elements are able to process TLS 1.3, but with a
limited set of cipher suites. There are two benefits for TLS-SE;
first fully tamper resistant processing of TLS protocol, which
increases the security level insurance; second embedded software
component ready for use, which relieves the software of the burden
of cryptographic libraries and associated attacks. TLS-SE devices
may also embed standalone applications, which are accessed via
internet node, using a routing procedure based on SNI extension.

"PCEP Procedures and Protocol Extensions for Using PCE as a Central

Controller (PCECC) of BIER", Ran Chen, BenChong Xu, Huaimo Chen, Aijun
Wang, 2022-03-07, <draft-chen-pce-pcep-extension-pce-controller-bier-03.txt>

This draft specify a new mechanism where PCE allocates the BIER
information centrally and uses PCEP to distribute them to all nodes,
then PCC generate a "Bit Index Forwarding Table"(BIFT).

"PCEP Procedures and Protocol Extensions for Using PCE as a Central

Controller (PCECC) of BIER-TE", Ran Chen, BenChong Xu, Huaimo Chen, Aijun
Wang, 2022-03-07, <draft-chen-pce-controller-bier-te-03.txt>

This draft specify extensions to PCEP protocol when a PCE-based

controller is responsible for allocates the BIER-TE information(BIER
subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc),
then PCC generate a "Bit Index Forwarding Table"(BIFT).
"Federated TLS Authentication", Jakob Schlyter, Stefan Halen, 2022-07-24,
<draft-halen-fed-tls-auth-04.txt>

This document describes how to establish a secure end-to-end channel

between two parties within a federation, where both client and server
are mutually authenticated. The trust relationship is based upon a
trust anchor held and published by the federation. A federation is a
trusted third party that inter-connect different trust domains with a
common set of policies and standards.

"MSYNC", Sophie Bale, Remy Brebion, Guillaume Bichot, 2022-07-29,

<draft-bichot-msync-05.txt>

This document describes the Multicast Synchronization (MSYNC)

Protocol that aims at transferring video media objects over IP
multicast operating preferably RTP. Although generic, MSYNC has been
primarily designed for transporting HTTP adaptive streaming (HAS)
objects including manifest/playlists and media segments (e.g. MP4,
CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH
between a multicast server and a multicast gateway.

"BGP Extensions of SR Policy for Segment List Identification and

Protection", Liu Yao, Shaofu Peng, 2022-06-09,
<draft-lp-idr-sr-path-protection-03.txt>

This document proposes extensions of BGP to provide identification

and protection information of segment lists within a candidate path
when delivering SR policy. And it also extends BGP-LS to provide
some extra information of the segment list in the advertisement.

"QUIC-Aware Proxying Using HTTP", Tommy Pauly, David Schinazi, 2022-09-02,

<draft-pauly-masque-quic-proxy-04.txt>

This document defines an extension to UDP Proxying over HTTP that

adds specific optimizations for proxied QUIC connections. This
extension allows a proxy to reuse UDP 4-tuples for multiple
connections. It also defines a mode of proxying in which QUIC short
header packets can be forwarded using an HTTP/3 proxy rather than
being re-encapsulated and re-encrypted.

"Binary Application Record Encoding (BARE)", Drew DeVault, 2022-05-11,

<draft-devault-bare-07.txt>

The Binary Application Record Encoding (BARE) is a data format used

to represent application records for storage or transmission between
programs. BARE messages are concise and have a well-defined schema,
and implementations may be simple and broadly compatible. A schema
language is also provided to express message schemas out-of-band.

Comments

Comments are solicited and should be addressed to the mailing list at

~sircmpwn/public-inbox@lists.sr.ht and/or the author(s).

"Short Hierarchical IP Addresses for Edge Networks", Haoyu Song,

2022-04-11, <draft-song-ship-edge-03.txt>

To mitigate the IPv6 header overhead and improve the scalability and
 performance in edge networks, this draft proposes to use short
hierarchical IP addresses excluding the network prefix within edge
networks. An edge network can be further organized into a
hierarchical architecture containing one or more levels of networks.
While each end node only needs to keep a short address suffix as its
identifier, the border routers for each hierarchical level are
responsible for address augmenting and pruning when a packet leaves
or enter a lower level network. Specifically, the top-level border
routers of an edge network convert the internal IP header to and from
the standard IPv6 header. This draft presents an incrementally
deployable scheme allowing packet header to be effectively compressed
in edge networks without affecting the network interoperability.
Simplifying both network data plane and control plane, the SHIP
architecture is suitable for any types of edge networks, especially
when low latency, high performance, and high bandwidth efficiency are
required.

"Signature Validation Token", Stefan Santesson, Russ Housley, 2022-05-16,

<draft-santesson-svt-08.txt>

Electronic signatures have a limited lifespan with respect to the

time period that they can be validated and determined to be
authentic. The Signature Validation Token (SVT) defined in this
specification provides evidence that asserts the validity of an
electronic signature. The SVT is provided by a trusted authority,
which asserts that a particular signature was successfully validated
according to defined procedures at a certain time. Any future
validation of that electronic signature can be satisfied by
validating the SVT without any need to also validate the original
electronic signature or the associated digital certificates. SVT
supports electronic signatures in CMS, XML, PDF and JSON documents.

"IPv6 Solution for 5G Edge Computing Sticky Service", Linda Dunbar, John
Kaippallimalil, 2022-03-07,
<draft-dunbar-6man-5g-edge-compute-sticky-service-06.txt>

This draft describes the IPv6-based solutions that can stick an

application flow originated from a mobile device to the same
ANYCAST server location when the mobile device moves from one
5G cell site to another.

"Revised Cookie Processing in the IKEv2 Protocol", Valery Smyslov,

2022-04-18, <draft-smyslov-ipsecme-ikev2-cookie-revised-03.txt>

This document defines a revised processing of cookies in the Internet

Key Exchange protocol Version 2 (IKEv2). It is intended to solve a
problem in IKEv2 when due to packets loss and reordering peers may
erroneously fail to authenticate each other when cookies are used in
the initial IKEv2 exchange.

"An MPLS SR OAM option reducing the number of end-to-end path validations",
Ruediger Geib, 2022-04-26, <draft-geib-spring-oam-opt-03.txt>

MPLS traceroute implementations validate dataplane connectivity and

isolate faults by sending messages along every end-to-end Label
Switched Path (LSP) combination between a source and a destination
node. This requires a growing number of path validations in networks
with a high number of equal cost paths between origin and
destination. Segment Routing (SR) introduces MPLS topology awareness
 combined with Source Routing. By this combination, SR can be used to
implement an MPLS traceroute option lowering the total number of LSP
validations as compared to commodity MPLS traceroute.

"Bidirectional Forwarding Detection (BFD) on Multi-chassis Link Aggregation

Group (MC-LAG) Interfaces", Greg Mirsky, Jeff Tantsura, Gyan Mishra,
2022-03-30, <draft-mtm-rtgwg-bfd-mc-lag-04.txt>

This document describes the use of Bidirectional Forwarding Detection

for Multi-chassis Link Aggregation Group to provide faster than Link
Aggregation Control Protocol convergence. This specification
enhances RFC 7130 "Bidirectional Forwarding Detection (BFD) on Link
Aggregation Group (LAG) Interfaces".

"Blockchain Gateways: Use-Cases", Aetienne Sardon, Thomas Hardjono, Mike

McBride, 2022-04-20, <draft-sardon-blockchain-gateways-usecases-03.txt>

In the past five years there has been a growing interest in using
blockchains and DLT systems as a means to create a new mechanism to
issue, distribute and manage virtual assets. However, as DLT systems
consisting of peer-to-peer (P2P) network of nodes increase in number,
there is an increasing need to interconnect these networks to permit
virtual assets to flow into and out of them. This document captures
a number of use-cases driving the need for interoperability between
DLT systems.

"SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)", Gyan

Mishra, Alexandre Petrescu, Naveen Kottapalli, Dusan Mudric, Dmytro Shytyi,
2022-04-30, <draft-mishra-6man-variable-slaac-06.txt>

This draft proposes the use of arbitrary length prefixes in PIO for
SLAAC. A prefix of length 63 in PIO, for example, would be permitted
to form an address whose interface identifier length is 65, which
allows several benefits. A prefix of length 65 would be allowed too,
but it SHOULD NOT be used on a large scale, like at a large ISP; this
is to avoid a race to the bottom.

The implementation uses a parameter in the Host; this option is off

by default. In that case, the Host respects the 64bit boundary.
When the parameter is set to on the Host accepts prefixes of lengths
different than 64 and forms 128bit addresses.

In the past, various IPv6 addressing models have been proposed based
on a subnet hierarchy embedding a 64-bit prefix. The last remnant of
IPv6 classful addressing is a inflexible interface identifier
boundary at /64. This document proposes flexibility to the fixed
position of that boundary for interface addressing.

"SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A

Problem Statement", Gyan Mishra, Alexandre Petrescu, Naveen Kottapalli,
Dusan Mudric, Dmytro Shytyi, 2022-04-30,
<draft-mishra-v6ops-variable-slaac-problem-stmt-04.txt>

In the past, various IPv6 addressing models have been proposed based
on a subnet hierarchy embedding a 64-bit prefix. The last remnant of
IPv6 classful addressing is a inflexible interface identifier
boundary at /64. This document details the 64-bit boundary problem
statement.
"Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment
Identifiers (SIDs) with MPLS Data Planes", Xiao Min, Shaofu Peng, Liyan
Gong, 2022-06-21, <draft-xp-mpls-spring-lsp-ping-path-sid-04.txt>

Path Segment is a type of SR segment, which is used to identify an SR

path. This document provides Target Forwarding Equivalence Class
(FEC) stack TLV definitions for Path Segment Identifiers.

"Beyond 64KB Limit of IKEv2 Payloads", C. Tjhai, Tobias Heider, Valery

Smyslov, 2022-07-28, <draft-tjhai-ikev2-beyond-64k-limit-03.txt>

The maximum Internet Key Exchange Version 2 (IKEv2) payload size is

limited to 64KB. This makes IKEv2 not usable for conservative post-
quantum cryptosystem whose public-key is larger than 64KB. This
document discusses the considerations and defines a mechanism to
exchange large post-quantum public keys and signatures in IKEv2.

"Extension of Transport Aware Mobility in Data Network", Kausik Majumdar,

Uma Chunduri, Linda Dunbar, 2022-04-14,
<draft-mcd-rtgwg-extension-tn-aware-mobility-04.txt>

The existing Transport Network Aware Mobility for 5G [TN-AWARE-

MOBILITY] draft specifies a framework for mapping the 5G mobile
systems Slice and Service Types (SSTs) to corresponding underlying
network paths in IP and Layer 2 Transport networks.The focus of that
work is limited to the mobility domain and transport network
characteristics till the UPF and doesn't go beyond the UPF to the
Data Network.

To maintain E2E transport network characteristics the framework

needs to be extended beyond UPF. This document describes a framework
for extending the mobility aware transport network characteristics
from the UPF through the Data Network.

"Separation of Data Path and Data Flow Sublayers in the Transport Layer",
Hirochika Asai, 2022-07-06, <draft-asai-tsvwg-transport-review-03.txt>

This document reviews the architectural design of the transport

layer. In particular, this document proposes to separate the
transport layer into two sublayers; the data path and the data flow
layers. The data path layer provides functionality on the data path,
such as connection handling, path quality and trajectory monitoring,
waypoint management, and congestion control for the data path
resource management. The data flow layer provides additional
functionality upon the data path layer, such as flow control for the
receive buffer management, retransmission for reliable data delivery,
and transport layer security. The data path layer multiplexes
multiple data flow layer protocols and provides data path information
to the data flow layer to control data transmissions, such as
prioritization and inverse multiplexing for multipath protocols.

"Network measurement intent - one of IBN use cases", Danyang Chen, Hongwei
Yang, Kehan Yao, Giuseppe Fioccola, Qin WU, 2022-07-07,
<draft-yang-nmrg-network-measurement-intent-05.txt>

As an important technical means to detect network state, network

measurement has attracted more and more attention in the development
of network. However, the current network measurement technology has
the problem that the measurement method and the measurement purpose
 cannot match well. To solve this problem, this memo introduces
network measurement intent, presents a process of scheduling the
network resource and measurement task to meet the user or network
operator's needs. And it can be seen as a specific use case of
intent based network.

"DC aware TE topology model", Young Lee, Xufeng Liu, Luis Contreras,
2022-07-11, <draft-llc-teas-dc-aware-topo-model-02.txt>

This document proposes the extension of the TE topology model for

including information related to data center resource capabilities.

"IETF Network Slice Controller and its associated data models", Luis
Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody,
Sergio Belotti, 2022-07-11,
<draft-contreras-teas-slice-controller-models-03.txt>

This document describes the major functional components of an IETF

Network Slice Controller (NSC) as well as references the data models
required for supporting the requests of IETF network slices and their
realization.

"Privacy Pass: Centralization Problem Statement", Mark McFadden,

2022-03-07, <draft-mcfadden-pp-centralization-problem-03.txt>

This document discusses the problems associated with strict upper

bounds on the number of Privacy Pass servers in the proposed Privacy
Pass ecosystem. It documents a proposed problem statement.

"Protocol and Engineering Effects of Consolidation", Dominique Lazanski,

Mark McFadden, 2022-07-24, <draft-lazanski-consolidation-04.txt>

This document contributes to the continuing discussion on Internet

consolidation. Over the last several years there have been many types
of discussions around consolidation at a technical level, an economic
or market level and also at an engineering level. This] document aims
to discuss recent areas of Internet consolidation and provide some
suggestions for advancing the discussion.

"BIER Fast ReRoute", Huaimo Chen, Mike McBride, Steffen Lindner, Michael
Menth, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu,
2022-04-03, <draft-chen-bier-frr-05.txt>

BIER is a scalable multicast overlay [RFC8279] that utilizes a

routing underlay, e.g., IP, to build up its Bit Index Forwarding
Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-
FRR). It protects BIER traffic after detecting the failure of a link
or node in the core of a BIER domain until affected BIFT entries are
recomputed after reconvergence of the routing underlay. BIER-FRR is
applied locally at the point of local repair (PLR) and does not
introduce any per-flow state. The document specifies nomenclature
for BIER-FRR and gives examples for its integration in BIER
forwarding. Furthermore, it presents operation modes for BIER-FRR.
Link and node protection may be chosen as protection level.
Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based
BIER-FRR are defined and compared.

"Security Management Automation of Cloud-Based Security Services in I2NSF

Framework", Jaehoon Jeong, Patrick Lingga, J., PARK, Diego Lopez, Susan
Hares, 2022-07-25, <draft-jeong-i2nsf-security-management-automation-04.txt>

This document describes Security Management Automation (SMA) of

cloud-based security services in the framework of Interface to
Network Security Functions (I2NSF). The security management
automation in this document deals with closed-loop security control,
security policy translation, and security audit. To support these
three features in SMA, this document specifies an augmented
architecture of the I2NSF framework with new system components and
new interfaces.

"Transaction ID Mechanism for NETCONF", Jan Lindblad, 2022-06-08,

<draft-lindblad-netconf-transaction-id-02.txt>

NETCONF clients and servers often need to have a synchronized view of

the server's configuration data stores. The volume of configuration
data in a server may be very large, while data store changes
typically are small when observed at typical client resynchronization
intervals.

Rereading the entire data store and analyzing the response for
changes is an inefficient mechanism for synchronization. This
document specifies an extension to NETCONF that allows clients and
servers to keep synchronized with a much smaller data exchange and
without any need for servers to store information about the clients.

"Mailing List Manager (MLM) Transformations", Alessandro Vesely,

2022-08-18, <draft-vesely-dmarc-mlm-transform-06.txt>

The widespread adoption of Domain-based Message Authentication,

Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to
rewrite the From: header field as a workaround.

This document proposes two methods to restore the original From:

value of transformed messages, to be effected by the receiving
Message Delivery Agent (rMDA). One method requires receivers to
identify a set of trusted MLM operators who set the Author: header
field. The other method tries to revert MLM transformations in order
to verify DomainKeys Identified Mail (DKIM) signatures that were
applied by the author domain at submission time.

"JWS Clear Text JSON Signature Option (JWS/CT)", Bret Jordan, Samuel
Erdtman, Anders Rundgren, 2022-06-21, <draft-jordan-jws-ct-08.txt>

This document describes a method for extending the scope of the JSON
Web Signature (JWS) specification, called JWS/CT (JWS "Clear Text").
By combining the detached mode of JWS with the JSON Canonicalization
Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON
format after being signed. In addition to supporting a consistent
data format, this arrangement also simplifies documentation,
debugging, and logging. The ability to embed signed JSON objects in
other JSON objects, makes the use of counter-signatures
straightforward.

This informational specification has been produced outside the IETF,

is not an IETF standard, and does not have IETF consensus. The
intended audiences of this document are JSON tool vendors as well as
designers of JSON-based cryptographic solutions.
"Network Time Protocol Version 5", Miroslav Lichvar, 2022-08-25,
<draft-mlichvar-ntp-ntpv5-05.txt>

This document describes the version 5 of the Network Time Protocol

(NTP).

"IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White,

Shraddha Hegde, Tony Przygienda, 2022-07-11,
<draft-white-lsr-distoptflood-03.txt>

In dense topologies (such as data center fabrics based on the Clos

and butterfly topologies, though not limited to these), IGP flooding
mechanisms designed for sparse topologies can "overflood," or carry
too many copies of topology and reachability information to fabric
devices. This results in slower convergence times and higher
resource utilization. The modifications to the flooding mechanism in
the Intermediate System to Intermediate System (IS-IS) link state
protocol described in this document reduce resource utilization
significantly, while increasing convergence performance in dense
topologies.

Note that a Clos fabric is used as the primary example of a dense

flooding topology throughout this document. However, the flooding
optimizations described in this document apply to any topology.

"Trusted Resolution System and Protocol Extension", Yuying Chen, Jiahui

Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2022-05-09,
<draft-chen-trusted-resolution-03.txt>

The Handle System [1][2]is a name service system for handle

resolution and management over the public Internet. Handle System
protocol [3] is designed to be transmitted as a byte stream via a TCP
connection. This document describes a Trusted Resolution System and
the protocol extension based on Handle System protocol. Trusted
resolution aims to achieve credibility verification through data
signing. The Trusted Resolution System determines whether to perform
trusted resolution and verification on the response according to the
trusted flag requested by the client.

"Use of the SM2 and SM3 Algorithms in Handle System", Yuying Chen, Jiahui
Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie, 2022-05-09,
<draft-chen-sm2-sm3-algorithms-03.txt>

The Handle System is a global name service that allows secured handle
resolution and administration over the public Internet according to
[1][5][3]. Handle System protocol [3] is designed to be transmitted
as a byte stream via a TCP connection. In this document, SM2 and SM3
algorithms [4][5]are introduced into the handle system to enhance the
security and compactivity. Trusted resolution and message credential
are extended to support SM2 and SM3 algorithms.

"In-band Edge-to-Edge Round Trip Time Measurement", Haoyu Song, Linda

Dunbar, 2022-05-31, <draft-song-ippm-inband-e2e-rtt-measurement-03.txt>

This draft describes a lightweight in-band edge-to-edge flow-based

network round trip time measurement architecture and proposes the
implementation over IOAM E2E option. By augmenting the IOAM E2E
option header, the process can be fully done in data plane without
needing to involve the control plane to maintain any states.
"SRH TLV Processing Programming", Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin
Li, 2022-08-07, <draft-li-spring-srh-tlv-processing-programming-03.txt>

This document proposes a mechanism to program the processing rules of

Segment Routig Header (SRH) optional TLVs explicitly on the ingress
node. In this mechanism, there is no need to configure local
configuration at the node to support SRH TLV processing. A network
operator can program to process specific TLVs on specific segment
endpoint nodes for specific packets on the ingress node, which is
more efficient for SRH TLV processing.

"JSON Schema: A Media Type for Describing JSON Documents", Austin Wright,
Henry Andrews, Ben Hutton, Greg Dennis, 2022-06-10,
<draft-bhutton-json-schema-01.txt>

JSON Schema defines the media type "application/schema+json", a JSON-

based format for describing the structure of JSON data. JSON Schema
asserts what a JSON document must look like, ways to extract
information from it, and how to interact with it. The "application/
schema-instance+json" media type provides additional feature-rich
integration with "application/schema+json" beyond what can be offered
for "application/json" documents.

"JSON Schema Validation: A Vocabulary for Structural Validation of JSON",

Austin Wright, Henry Andrews, Ben Hutton, 2022-06-10,
<draft-bhutton-json-schema-validation-01.txt>

JSON Schema (application/schema+json) has several purposes, one of

which is JSON instance validation. This document specifies a
vocabulary for JSON Schema to describe the meaning of JSON documents,
provide hints for user interfaces working with JSON data, and to make
assertions about what a valid document must look like.

"IPv6 Addressing Considerations", Fernando Gont, Guillermo Gont,

2022-06-01, <draft-gont-v6ops-ipv6-addressing-considerations-02.txt>

IPv6 addresses can differ in a number of properties, such as scope,

stability, and intended usage type. This document analyzes the
impact of these properties on aspects such as security, privacy,
interoperability, and network operations, with the goal of providing
guidance about IPv6 address usage. Additionally, it identifies
challenges and gaps that currently prevent systems and applications
from leveraging the increased flexibility and availability of IPv6
addresses.

"An ECN Extension to CONNECT-UDP", David Schinazi, 2022-03-28,

<draft-schinazi-masque-connect-udp-ecn-02.txt>

CONNECT-UDP allows proxying UDP packets over HTTP. This document

describes an extension to CONNECT-UDP that allows conveying ECN
information on proxied UDP packets.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/DavidSchinazi/draft-connect-udp-ecn.
"http2 window size setting", chenmeiling, Li Su, 2022-07-08,
<draft-chen-httpbis-window-size-03.txt>

This document proposed the minimum value setting mechanism for

HTTP2.0 Window and Window_update, and a Window_update frame sending
mechanism, used to solve the gap caused by the inconsistency of the
minimum value, f the use case when window_size_increment in the
window update frame less than 128 bytes and the increased window size
also less than 128 bytes, then network connection will come to an
error.

"APN Scope and Gap Analysis", Shuping Peng, Zhenbin Li, Gyan Mishra,
2022-03-06, <draft-peng-apn-scope-gap-analysis-04.txt>

The APN work in IETF is focused on developing a framework and set of

mechanisms to derive, convey and use an attribute allowing the
implementation of fine-grain user group-level and application group-
level requirements in the network layer. APN aims to apply various
policies in different nodes along a network path onto a traffic flow
altogether, for example, at the headend to steer into corresponding
path, at the midpoint to collect corresponding performance
measurement data, and at the service function to execute particular
policies. Currently there is still no way to efficiently realize
this composite network service provisioning along the path. This
document further clarifies the scope of the APN work and describes
the solution gap analysis.

"SRv6 In-situ Active Measurement with IOAM", Haoyu Song, Gyan Mishra, Tian
Pan, 2022-03-04, <draft-song-spring-siam-03.txt>

This draft describes an active measurement method for SRv6 which can
support hop-by-hop and end-to-end measurement on any SRv6 path using
existing protocols such as IOAM. A packet containing an SRH uses a
flag bit to indicate the packet is an active probing packet. The
measurement information, such as the IOAM header and data, is
encapsulated in UDP payload, indicated by a dedicated port number.
The probing packet originates from a segment source node, traverses
an arbitrary segment path, and terminates at a segment endpoint node,
as configured by the segment list in SRH. Each segment node on the
path, when detecting the flag, shall parse the UDP header and the
payload. In the case of IOAM, the node shall process the IOAM option
conforming to the standard procedures defined in the IOAM documents.
The method is compatible with some other SRv6 active measurement
proposals and support multiple applications.

"Using Entropy Label for Network Slice Identification in MPLS networks.",

Bruno Decraene, Clarence Filsfils, Wim Henderickx, Tarek Saad, Vishnu
Beeram, Luay Jalil, 2022-06-14,
<draft-decraene-mpls-slid-encoded-entropy-label-id-04.txt>

This document updates [RFC6790] to extend the use of the TTL field of
the Entropy Label in order to provide a flexible set of flags called
the Entropy Label Control field.

This document also defines a solution to encode a slice identifier in

MPLS in order to distinguish packets that belong to different slices,
to allow enforcing per network slice policies (.e.g, Qos).
 The slice identification is independent of the topology. It allows
for QoS/DiffServ policy on a per slice basis in addition to the per
packet QoS/DiffServ policy provided by the MPLS Traffic Class field.

In order to minimize the size of the MPLS stack and to ease

incremental deployment the slice identifier is encoded as part of the
Entropy Label.

"Photonic firewall oriented routing and spectrum allocation strategy in

optical networks", Li Xin, Lu Zhang, Ying Tang, Zicheng Shi, Shanguo Huang,
2022-07-05, <draft-li-rtgwg-photonic-firewall-rsa-03.txt>

The photonic firewall oriented routing and spectrum allocation

strategy in elastic optical networks is proposed. For the security
detecting requirement, each light-path should pass through at least a
photonic firewall. To reduce the blocking rate and improve the
spectrum efficiency, the whole network is divided into several parts
according to the locations of all deployed photonic firewalls. A
photonic firewall is responsible for the security detecting for each
part. This strategy has a low complexity and is suitable for large-
scale optical networks.

"Network File System (NFS) Version 4 Minor Version 1 Protocol", David

Noveck, 2022-06-15, <draft-dnoveck-nfsv4-rfc5661bis-04.txt>

This document describes the Network File System (NFS) version 4 minor
version 1, including features retained from the base protocol (NFS
version 4 minor version 0, which is specified in RFC 7530) and
protocol extensions made subsequently. The later minor version has
no dependencies on NFS version 4 minor version 0, and was, until
recently, documented as a completely separate protocol.

This document will give rise to a suite of documents which

collectively obsolete RFC 8881. In addition to many corrections and
clarifications, it will rely on NFSv4-wide documents to substantially
revise the treatment of protocol extension, internationalization, and
security, superseding the descriptions of those aspects of the
protocol appearing in RFCs 5661 and 8881.

"Profiles for Traffic Engineering (TE) Topology Data Model and

Applicability to non-TE Use Cases", Italo Busi, Xufeng Liu, Igor Bryskin,
Tarek Saad, Oscar de Dios, 2022-08-09,
<draft-busi-teas-te-topology-profiles-04.txt>

This document describes how profiles of the Traffic Engineering (TE)

Topology Model, defined in RFC8795, can be used to address
applications beyond "Traffic Engineering".

"DLT Gateway Crash Recovery Mechanism", Rafael Belchior, Miguel Correia,

Andre Augusto, Thomas Hardjono, 2022-05-20,
<draft-belchior-gateway-recovery-04.txt>

This memo describes the crash recovery mechanism for the Open Digital
Asset Protocol (ODAP), called ODAP-2PC. The goal is to assure
gateways running ODAP to be able to recover from crashes, and thus
preserve the consistency of an asset across ledgers (i.e., double
spend does not occur). This draft includes the description of the
messaging and logging flow necessary for the correct functioning of
ODAP-2PC.
"Generic Delivery Functions", Zhaohui Zhang, Ron Bonica, Kireeti Kompella,
Greg Mirsky, 2022-07-11,
<draft-zzhang-intarea-generic-delivery-functions-03.txt>

Some functionalities (e.g., fragmentation/reassembly and

Encapsulating Security Payload) provided by IPv6 can be viewed as
delivery functions independent of IPv6 or even IP entirely. This
document proposes to provide those functionalities at different
layers (e.g., MPLS, BIER or even Ethernet) independent of IP.

"Segment Routing Header encapsulation for Alternate Marking Method",

Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, 2022-08-05,
<draft-fz-spring-srv6-alt-mark-03.txt>

This document describes how the Alternate Marking Method can be used
as the passive performance measurement tool in an SRv6 network. It
defines how Alternate Marking data fields are transported as part of
the Segment Routing with IPv6 data plane (SRv6) header.

"Segment Routing for Unaffiliated BFD Echo Function", Mach Chen, Cheng Li,
Jiang Wenying, Yisong Liu, Xinjun Chen, 2022-03-21,
<draft-chen-spring-sr-policy-for-ubfd-04.txt>

This document describes how to leverage Segment Routing (SR) to

ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the
remote system before being looped back to the local system. This
enables that U-BFD works not only for one hop scenario but for
multiple hops scenario as well.

In addition, this document also defines a way to explicitly specify

the loop back path of the U-BFD Echo packets. This is useful in the
case where the forward and reverse path of the Echo packets are
required to follow the same path.

"DLEP Radio Band Extension", Henning Rogge, 2022-03-07,

<draft-rogge-manet-dlep-radio-band-03.txt>

This document defines an extension to the Dynamic Link Exchange

Protocol (DLEP) to provide the frequency bands used by the radio.

"Dynamic-Anycast (Dyncast) Problem Statement and Use Cases", Peng Liu,

Philip Eardley, Dirk Trossen, Mohamed Boucadair, Luis Contreras, Cheng Li,
Yizhou Li, 2022-07-08, <draft-liu-dyncast-ps-usecases-04.txt>

Many service providers have been exploring distributed computing

techniques to achieve better service response time and optimized
energy consumption. Such techniques rely upon the distribution of
computing services and capabilities over many locations in the
network, such as its edge, the metro region, virtualized central
office, and other locations. In such a distributed computing
environment, providing services by utilizing computing resources
hosted in various computing facilities (e.g., edges) is being
considered, e.g., for computationally intensive and delay sensitive
services. Ideally, services should be computationally balanced using
service-specific metrics instead of simply dispatching the service
requests in a static way or optimizing solely connectivity metrics.
For example, systematically directing end user-originated service
requests to the geographically closest edge or some small computing
 units may lead to an unbalanced usage of computing resources, which
may then degrade both the user experience and the overall service
performance. We have named this kind of network with dynamic sharing
of edge compute resources "Computing-Aware Networking" (CAN).

This document provides the problem statement and the typical

scenarios of CAN, which is to provide the service equivalency by
steering traffic dynamically to the appropriate service instance
based on the basic edge computing deployment.

"DLEP Radio Channel Utilization Extension", Henning Rogge, 2022-03-07,

<draft-rogge-manet-dlep-channel-utilization-02.txt>

This document defines an extension to the Dynamic Link Exchange

Protocol (DLEP) to provide the utilization of a radio channel.

"BGP Extensions of SR Policy for Composite Candidate Path", Hao Li,

Mengxiao Chen, Changwang Lin, Jiang Wenying, Weiqiang Cheng, 2022-08-30,
<draft-li-idr-sr-policy-composite-path-03.txt>

Segment Routing is a source routing paradigm that explicitly

indicates the forwarding path for packets at the ingress node. An SR
Policy is associated with one or more candidate paths. A candidate
path is either dynamic, explicit or composite. This document defines
extensions to BGP to distribute SR policies carrying composite
candidate path information. So that composite candidate paths can be
installed when the SR policy is applied.

"Signaling Composite Candidate Path of SR Policy using BGP-LS", Hao Li,

Mengxiao Chen, Changwang Lin, Jiang Wenying, Weiqiang Cheng, 2022-08-30,
<draft-li-idr-bgpls-sr-policy-composite-path-03.txt>

Segment Routing is a source routing paradigm that explicitly

indicates the forwarding path for packets at the ingress node. An SR
Policy is associated with one or more candidate paths, and each
candidate path is either dynamic, explicit or composite. This
document specifies the extensions to BGP Link State (BGP-LS) to carry
composite candidate path information in the advertisement of an SR
policy.

"PCEP Extensions for sid verification for SR-MPLS", Ran Chen, Samuel Sidor,
Chun Zhu, Alexej Tokar, Mike Koldychev, 2022-07-27,
<draft-chen-pce-sr-mpls-sid-verification-05.txt>

This document defines a new flag for indicating the headend is

explicitly requested to verify SID(s) by the PCE.

"BGP Color-Aware Routing Problem Statement", Dhananjaya Rao, Swadesh

Agrawal, Clarence Filsfils, Bruno Decraene, Dirk Steinberg, Luay Jalil, Jim
Guichard, Ketan Talaulikar, Keyur Patel, Wim Henderickx, 2022-05-26,
<draft-dskc-bess-bgp-car-problem-statement-05.txt>

This document explores the scope, use-cases and requirements for a

BGP based routing solution to establish end-to-end intent-aware paths
across a multi-domain service provider network environment.

"A YANG Model for MPLS MSD", Yingzhen Qu, Acee Lindem, Stephane Litkowski,
Jeff Tantsura, 2022-07-27, <draft-qu-mpls-mpls-msd-yang-05.txt>
 This document defines a YANG data module augmenting the IETF MPLS
YANG model to provide support for MPLS Maximum SID Depths (MSDs) as
defined in RFC 8476 and RFC 8491.

"Subtype Capability Exchange During MPTCP Handshake", Jiao Kang,

liangqiandeng, Shangling Deng, 2022-06-16,
<draft-kang-tcpm-subtype-capability-exchange-01.txt>

Multipath TCP provides the ability to simultaneously use multiple

paths between peers. MPTCP protocol defines seven subtypes in MPTCP
v0 [RFC6824] and ten subtypes in MPTCP v1 [RFC8684] to differentiate
message types and implement some additional functions during a
session.

This draft proposes an enhancement to support Subtype Capability

Exchange during MPTCP connection establishment in order to improve
elastic scalability of MPTCP protocol. It includes: 1) requirements
for which this kind of capability exchange during handshake is
important for a MPTCP session; 2) a typical flow for Subtype
Capability Exchange between peers; 3) a feasible solution on protocol
design is suggested.

"One-way/Two-way Active Measurement Protocol Extensions for Performance

Measurement on LAG", Zhenqiang Li, Tianran Zhou, Guo Jun, Greg Mirsky,
Rakesh Gandhi, 2022-08-28, <draft-li-ippm-otwamp-on-lag-04.txt>

This document defines extensions to One-way Active Measurement

Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to
implement performance measurement on every member link of a Link
Aggregation Group (LAG). Knowing the measured metrics of each member
link of a LAG enables operators to enforce the performance based
traffic steering policy across the member links.

"Challenges for the Internet Routing Systems Introduced by Semantic

Routing", Daniel King, Adrian Farrel, Christian Jacquenet, 2022-04-25,
<draft-king-irtf-challenges-in-routing-08.txt>

Historically, the meaning of an IP address has been to identify an

interface on a network device. Routing protocols were developed
based on the assumption that a destination address had this semantic.

Over time, routing decisions have been enhanced to determine paths on

which packets could be forwarded according to additional information
carried principally within the packet headers, and dependent on
policy coded in, configured at, or signaled to the routers.

Many proposals have been made to add semantics to IP packets by

placing additional information into existing fields, by adding
semantics to IP addresses, or by adding fields to the packets. The
intent is always to facilitate routing decisions based on these
additional semantics in order to provide differentiated paths to
enable forwarding of different packet flows on paths that may be
distinct from those derived by shortest path first or path vector
routing. We call this approach "Semantic Routing".

This document describes the challenges to the existing routing system

that are introduced by Semantic Routing. It then summarizes the
opportunities for research into new or modified routing and
forwarding approaches that make use of additional semantics.
 This document is presented as a study to support further research
into clarifying and understanding the issues. It does not pass
comment on the advisability or practicality of any of the proposals
and does not define any technical solutions.

"Simple Two-Way Direct Loss Measurement Procedure", Rakesh Gandhi, Clarence

Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Stefano Salsano, 2022-08-08,
<draft-gandhi-ippm-simple-direct-loss-03.txt>

This document defines Simple Two-Way Direct Loss Measurement (DLM)

procedure that can be used for Alternate-Marking Method for detecting
accurate data packet loss in a network. Specifically, DLM probe
packets are defined for both unauthenticated and authenticated modes
and they are efficient for hardware-based implementation.

"Dynamic-Anycast Architecture", Yizhou Li, Luigi Iannone, Dirk Trossen,

Peng Liu, Cheng Li, 2022-07-10, <draft-li-dyncast-architecture-04.txt>

This document describes a proposal for an architecture for the

Dynamic-Anycast (Dyncast). It includes an architecture overview,
main components that shall exist, and the workflow. An example of
workflow is provided, focusing on the load-balance multi-edge based
service use-case, where load is distributed in terms of both
computing and networking resources through the dynamic anycast
architecture.

"An Offset Extension Frame For HTTP/3 Data", Sam Hurst, 2022-07-04,
<draft-hurst-quic-http-data-offset-frame-02.txt>

This document specifies an optional extension frame type for HTTP/3

that extends the functionality of the DATA frame type to include an
offset for the HTTP message payload. This is useful in situations
where the HTTP/3 exchange is taking place over an unreliable
transport mechanism.

"Simple Two-Way Active Measurement Protocol Extensions for Performance

Measurement on LAG", Zhenqiang Li, Tianran Zhou, Guo Jun, Greg Mirsky,
Rakesh Gandhi, 2022-08-28, <draft-li-ippm-stamp-on-lag-03.txt>

This document extends Simple Two-Way Active Measurement Protocol

(STAMP) to implement performance measurement on every member link of
a Link Aggregation Group (LAG). Knowing the measured metrics of each
member link of a LAG enables operators to enforce a performance based
traffic steering policy across the member links.

"PCE for BIER-TE Path", Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra,
Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-04-18,
<draft-chen-pce-bier-te-path-03.txt>

This document describes extensions to Path Computation Element (PCE)

communication Protocol (PCEP) for supporting Bit Index Explicit
Replication (BIER) Traffic Engineering (TE) paths.

"BIER-TE Fast ReRoute", Huaimo Chen, Mike McBride, Yisong Liu, Aijun Wang,
Gyan Mishra, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-08-15,
<draft-chen-bier-te-frr-03.txt>

This document describes a mechanism for fast re-route (FRR)

 protection against the failure of a transit node or link on an
explicit point to multipoint (P2MP) multicast path/tree in a "Bit
Index Explicit Replication" (BIER) Traffic Engineering (TE) domain.
It does not have any per-path state in the core. For a multicast
packet to traverse a transit node along an explicit P2MP path, when
the node fails, its upstream hop node as a PLR reroutes the packet
around the failed node along the P2MP path once it detects the
failure.

"BIER-TE Egress Protection", Huaimo Chen, Mike McBride, Aijun Wang, Gyan
Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu, 2022-08-15,
<draft-chen-bier-te-egress-protect-03.txt>

This document describes a mechanism for fast protection against the

failure of an egress node of an explicit point to multipoint (P2MP)
multicast path/tree in a "Bit Index Explicit Replication" (BIER)
Traffic Engineering (TE) domain. It does not have any per-flow state
in the core of the domain. For a multicast packet to the egress
node, when the egress node fails, its upstream hop as a PLR sends the
packet to the egress' backup node once the PLR detects the failure.

"Terminal-based joint selection and configuration of MEC host and RAW

network", Carlos Bernardos, Alain Mourad, 2022-03-21,
<draft-bernardos-raw-joint-selection-raw-mec-02.txt>

There are several scenarios involving multi-hop heterogeneous

wireless networks requiring reliable and available features combined
with multi-access edge computing, such as Industry 4.0. This
document discusses mechanisms to allow a terminal influencing the
selection of a MEC host for instantiation of the terminal-targeted
MEC applications and functions, and (re)configuring the RAW network
lying in between the terminal and the selected MEC host. This
document assumes IETF RAW and ETSI MEC integration, fostering
discussion about extensions at both IETF and ETSI MEC to better
support these scenarios.

"Challenging Scenarios and Problems in Internet Addressing", Yihao Jia,

Dirk Trossen, Luigi Iannone, Nirmala Shenoy, Paulo Mendes, Donald Eastlake,
Peng Liu, Dino Farinacci, 2022-03-06,
<draft-jia-intarea-scenarios-problems-addressing-03.txt>

The Internet Protocol (IP) has been the major technological success
in information technology of the last half century. As the Internet
becomes pervasive, IP has been replacing communication technology for
many domain-specific solutions. However, domains with specific
requirements as well as communication behaviors and semantics still
exist and represent what [RFC8799] recognizes as "limited domains".

This document describes well-recognized scenarios that showcase

possibly different addressing requirements, which are challenging to
be accommodated in the IP addressing model. These scenarios
highlight issues related to the Internet addressing model and call
for starting a discussion on a way to re-think/evolve the addressing
model so to better accommodate different domain-specific
requirements.

The issues identified in this document are complemented and deepened

by a detailed gap analysis in a separate companion document
[I-D.jia-intarea-internet-addressing-gap-analysis].
"Carrying Virtual Transport Network Identifier in MPLS Packet", Zhenbin Li,
Jie Dong, 2022-03-07, <draft-li-mpls-enhanced-vpn-vtn-id-02.txt>

A Virtual Transport Network (VTN) is a virtual network which has a

customized network topology and a set of dedicated or shared network
resources allocated from the underlying network infrastructure.
Multiple VTNs can be created by network operator for using as the
underlay for one or a group of VPNs services to provide enhanced VPN
(VPN+) services. In packet forwarding, some fields in the data
packet needs to be used to identify the VTN the packet belongs to, so
that the VTN-specific processing can be executed. In the context of
network slicing, a VTN can be instantiated as a Network Resource
Partition (NRP).

This document proposes a mechanism to carry the VTN-ID in an MPLS

packet to identify the VTN the packet belongs to. The procedure for
processing the VTN ID is also specified.

"Dynamically Recreatable Keys", Juan Garcia-Pardo, Cyrill Kraehenbuehl,

Benjamin Rothenberger, Adrian Perrig, 2022-07-24,
<draft-garciapardo-panrg-drkey-03.txt>

DRKey is a pragmatic Internet-scale key-establishment system that

allows any host to locally obtain a symmetric key to enable a remote
service to perform source-address authentication, and enables first-
packet authentication. The remote service can itself locally derive
the same key with efficient cryptographic operations.

DRKey was developed with path aware networks in mind, but it is also
applicable to today's Internet. It can be incrementally deployed and
it offers incentives to the parties using it independently of its
dissemination in the network.

"NTS4PTP - Key Management System for the Precision Time Protocol Based on
the Network Time Security Protocol", Martin Langer, Rainer Bermbach,
2022-08-22, <draft-langer-ntp-nts-for-ptp-04.txt>

This document defines a key management service for automatic key

management for the integrated security mechanism (prong A) of IEEE
Std 1588[TM]-2019 (PTPv2.1) described there in Annex P. It
implements a key management for the immediate security processing
approach and offers a security solution for all relevant PTP modes.
The key management service for PTP is based on and extends the NTS
Key Establishment protocol defined in IETF RFC 8915 for securing NTP,
but works completely independent from NTP.

"Extended Communities Derived from Route Targets", Zhaohui Zhang, Jeffrey

Haas, Keyur Patel, 2022-03-04,
<draft-zzhang-idr-rt-derived-community-02.txt>

This document specifies a way to derive an Extended Community from a

Route Target and describes some example use cases.

"Multi-purpose Special Purpose Label for Forwarding Actions", Kireeti

Kompella, Vishnu Beeram, Tarek Saad, Israel Meilik, 2022-07-10,
<draft-kompella-mpls-mspl4fa-03.txt>

The MPLS architecture introduced Special Purpose Labels (SPLs) to

 indicate special forwarding actions and offered a few simple
examples, such as Router Alert. In the two decades since the
original architecture was crafted, the range, complexity and sheer
number of such actions has grown; in addition, there now is need for
"associated data" for some of the forwarding actions. Likewise, the
capabilities and scale of forwarding engines has also improved vastly
over the same time period. There is a pressing need to match the
needs with the capabilities to deliver the next generation of MPLS
architecture.

In this memo, we propose an alternate mechanism whereby a single SPL

can encode multiple forwarding actions and carry data (if any)
associated with the actions, some in the label stack and some after
the label stack. This proposal also solves the problem of scarcity
of base SPLs.

As proof of its utility and flexibility, this approach can

immediately address several use cases:

* to carry an Entropy Label for better load balancing;

* to carry a Flow-Aggregate Selector for IETF network slicing;

* to signal that further fast reroute may have harmful consequences;

* to indicate that there is relevant data after the label stack;

* among others.

"Instantiation of IETF Network Slices in Service Providers Networks",

Samier Barguil, Luis Contreras, Victor Lopez, Reza Rokui, Oscar de Dios,
2022-07-11, <draft-barguil-teas-network-slices-instantation-04.txt>

Network Slicing (NS) is an integral part of Service Provider

networks. The IETF has produced several YANG data models to support
the Software-Defined Networking and network slice architecture and
YANG-based service models for network slice (NS) instantiation.

This document describes the relationship between IETF Network Slice

models for requesting the IETF Network Slices and (e.g., Layer-3
Service Model, Layer-2 Service Model) and Network Models (e.g.,
Layer-3 Network Model, Layer-2 Network Model) used during their
realizations. In addition, this document describes the communication
between the IETF Network Slice Controller and the network controllers
for the realization of IETF network slices.

The IETF Network Slice YANG model provides the customer-oriented view
of the network slice. Thus, once the IETF Network Slice controller
(NSC) receives a request, it needs to map it to accomplish the
specific parameters expected by the network controllers. The network
models are analyzed to satisfy the IETF Network Slice requirements,
and the gaps in existing models are reported.

The document also provides operational and security considerations

when deploying network slices in Service Provider networks.

"Connecting Stub Networks to Existing Infrastructure", Ted Lemon,

2022-04-25, <draft-lemon-stub-networks-03.txt>
 This document describes a set of practices for connecting stub
networks to adjacent infrastructure networks, as well as to larger
network fabrics. This is applicable in cases such as constrained
(Internet of Things) networks where there is a need to provide
functional parity of service discovery and reachability between
devices on the stub network and devices on an adjacent infrastructure
link (for example, a home network).

The stub networks use case is intended to fully address the need to
attach a single network link to an infrastructure network, where the
attached link provides no through routing and in cases where
integration to the infrastructure routing fabric (if any) is not
available.

"Key Consistency and Discovery", Alex Davidson, Matthew Finkel, Martin

Thomson, Christopher Wood, 2022-08-17, <draft-wood-key-consistency-03.txt>

This document describes the key consistency and correctness

requirements of protocols such as Privacy Pass, Oblivious DoH, and
Oblivious HTTP for user privacy. It discusses several mechanisms and
proposals for enabling user privacy in varying threat models. In
concludes with discussion of open problems in this area.

"Definition of End-to-end Encryption", Mallory Knodel, Fred Baker, Olaf

Kolkman, Sofia Celi, Gurshabad Grover, 2022-07-26,
<draft-knodel-e2ee-definition-05.txt>

End-to-end encryption is an application of cryptography in

communication systems between endpoints. End-to-end encrypted
systems are unique in providing features of confidentiality,
integrity and authenticity for users. Improvements to end-to-end
encryption strive to maximise the system's security while balancing
usability and availability. Users of end-to-end encrypted
communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper.

"The Time Zone Information Format (TZif)", Arthur Olson, Paul Eggert,
Kenneth Murchison, 2022-06-13, <draft-murchison-rfc8536bis-05.txt>

This document specifies the Time Zone Information Format (TZif) for
representing and exchanging time zone information, independent of any
particular service or protocol. Two media types for this format are
also defined.

This document replaces and obsoletes RFC 8536.

"Prague Congestion Control", Koen De Schepper, Olivier Tilmans, Bob

Briscoe, 2022-07-11, <draft-briscoe-iccrg-prague-congestion-control-01.txt>

This specification defines the Prague congestion control scheme,

which is derived from DCTCP and adapted for Internet traffic by
implementing the Prague L4S requirements. Over paths with L4S
support at the bottleneck, it adapts the DCTCP mechanisms to achieve
consistently low latency and full throughput. It is defined
independently of any particular transport protocol or operating
system, but notes are added that highlight issues specific to certain
transports and OSs. It is mainly based on the current default
options of the reference Linux implementation of TCP Prague, but it
includes experience from other implementations where available. It
 separately describes non-default and optional parts, as well as
future plans.

The implementation does not satisfy all the Prague requirements (yet)
and the IETF might decide that certain requirements need to be
relaxed as an outcome of the process of trying to satisfy them all.
In two cases, research code is replaced by placeholders until full
evaluation is complete.

"DLEP Radio Quality Extension", Henning Rogge, 2022-03-07,

<draft-rogge-manet-dlep-radio-quality-02.txt>

This document defines an extension to the Dynamic Link Exchange

Protocol (DLEP) to provide the quality of incoming radio signals.

"A SIP Response Code (497) for Call Transfer Failure", Shrawan Khatri,
Vikram Singh, Marcelo Pazos, Cherng-Shung Hsu, 2022-07-25,
<draft-khatri-sipcore-call-transfer-fail-response-03.txt>

This document defines the 497 (Call Transfer Failure) SIP

response code, allowing Call Pull and Call Push parties to
indicate that the operation was rejected. Optional warning codes
are defined to carry granular information. SIP entities may use
this information to adjust how subsequent calls can be handled
intelligently.

"Security Technical Specification for Smart Devices of IoT", Bin Wang, Xing
Wang, Li Wan, Wenyuan Xu, Chonghua Wang, 2022-03-20,
<draft-wang-iot-devices-security-02.txt>

With the development of IoT, security of smart devices becomes an

important issues for us to discuss. This draft proposes a security
framework and detailed requirements in terms of hardware, system,
data, network, and management to ensure the security of IoT smart
devices. Specifically, hardware security includes the security of
hardware interfaces and components. System security includes
firmware security, security audit, etc. Data security includes data
verification and sensitive data protection. Network security
includes stream protection and session security, etc.

"Technical Requirements for Secure Access and Management of IoT Smart

Terminals", Bin Wang, Song Liu, Li Wan, Jun Li, Xing Wang, 2022-03-20,
<draft-wang-secure-access-of-iot-terminals-03.txt>

It is difficult to supervise the great deal of Internet of Things

(IoT) smart terminals which are widely distributed. Furthermore, a
large number of smart terminals (such as IP cameras, access control
terminals, traffic cameras, etc.) running on the network have high
security risks in access control. This draft introduces the
technical requirements for access management and control of IoT smart
terminals, which is used to solve the problem of personate and
illegal connection in the access process, and enables users to
strengthen the control of devices and discover devices that is
offline in time, so as to ensure the safety and stability of smart
terminals in the access process.

"Structured Flow Label", Clarence Filsfils, Ahmed Abdelsalam, Shay Zadok,

Xiaohu Xu, Weiqiang Cheng, Dan Voyer, Pablo Camarillo, 2022-03-07,
<draft-filsfils-6man-structured-flow-label-02.txt>
 This document defines the IPv6 Structured Flow Label. The seamless
nature of the change to [RFC6437] is demonstrated. Benefits of the
solution are explained. Use-cases are illustrated.

"LISP Transport for Policy Distribution", Michael Kowal, Marc

Portoles-Comeras, Amit Jain, Dino Farinacci, 2022-03-20,
<draft-kowal-lisp-policy-distribution-02.txt>

This document describes the use of the Locator/ID Separation Protocol

(LISP) to encode and transport data models for the configuration of
LISP ITRs.

"Open Service Access Protocol for IoT Smart Devices", Bin Wang, Shaopeng
Zhou, Chao Li, Chunming Wu, Zizhao Wang, 2022-03-20,
<draft-wang-open-service-access-protocol-02.txt>

With the development of IoT(Internet of Things) technology,

everything is interconnected. Mass IoT data, devices, businesses,
and services adopt different data descriptions and service access
methods, resulting in fragmentation issues, such as data
heterogeneous, device heterogeneous, and application heterogeneous,
which hinders the development of the industry. In order to solve the
problem, this draft proposes the requirements for IoT smart devices
to transmit and control, as well as transmission and protocol
interfaces. It is for the program design, system testing and
acceptance, and related research. Structured, unified, and
standardized open service interconnection model reduces business
replication cost and removes service barriers to push industrial
development.

"Fetch and Validation of Verified Mark Certificates", Wei Chuang, Marc

Bradshaw, Thede Loder, Alex Brotman, 2022-04-10,
<draft-fetch-validation-vmc-wchuang-02.txt>

A description of how entities wishing to validate a Verified Mark

Certificate (VMC) should retrieve and validate these documents.
This document is a companion to BIMI core specification, which should
be consulted alongside this document.

"BIMI Reporting", J. Adams, Alex Brotman, 2022-04-10,

<draft-adams-bimi-reporting-02.txt>

To support the utility of Brand Indicators for Message Identification

(BIMI), domains publishing BIMI records may find it useful to know
when their logos are failing to be displayed as expected. When an
entity, for example a mailbox operator, determines whether or not to
display the logo identified in the BIMI record, they may encounter
errors trying to retrieve the image file. Similarly, the associated
evidence document used to validate the logo may fail evaluation. In
other cases, the evaluator may decide that despite everything
validating, they may rely on local policies that determine validated
logos should still not be displayed. This specification defines how
BIMI evaluators should report their evaluation outcome back to the
publisher within the context of existing Domain-based Message
Authentication, Reporting, and Conformance (DMARC) reports.

"Automatic Extended Route Optimization (AERO)", Fred Templin, 2022-08-07,

<draft-templin-6man-aero-61.txt>
 This document specifies an Automatic Extended Route Optimization
(AERO) service for IP internetworking over Overlay Multilink Network
(OMNI) interfaces. AERO/OMNI use an IPv6 unique-local address format
for IPv6 Neighbor Discovery (IPv6 ND) messaging over the OMNI virtual
link. Router discovery and neighbor coordination are employed for
network admission and to manage the OMNI link forwarding and routing
systems. Secure multilink operation, mobility management, multicast,
traffic path selection and route optimization are naturally supported
through dynamic neighbor cache updates. AERO is a widely-applicable
mobile internetworking service especially well-suited to aviation,
intelligent transportation systems, mobile end user devices and many
other applications.

"Transmission of IP Packets over Overlay Multilink Network (OMNI)

Interfaces", Fred Templin, 2022-08-07, <draft-templin-6man-omni-71.txt>

Mobile nodes (e.g., aircraft of various configurations, terrestrial

vehicles, seagoing vessels, space systems, enterprise wireless
devices, pedestrians with cell phones, etc.) communicate with
networked correspondents over multiple access network data links and
configure mobile routers to connect end user networks. A multilink
virtual interface specification is presented that enables mobile
nodes to coordinate with a network-based mobility service and/or with
other mobile node peers. The virtual interface provides an
adaptation layer service that also applies for more static
deployments such as enterprise and home networks. This document
specifies the transmission of IP packets over Overlay Multilink
Network (OMNI) Interfaces.

"Deprecating infrastructure "int" domains", Kim Davies, Amanda Baber,

2022-01-05, <draft-davies-int-historic-03.txt>

The document marks as historic any "int" domain names that were
designated for infrastructure purposes, and identifies them for
removal from the "int" top-level domain. Any implementation that
involves these domains should be considered deprecated. This
document also marks RFC 1528 and RFC 1706 as historic, and updates
RFC 1591 by removing the documented use of "int" for international
databases.

"Common Format and MIME Type for Comma-Separated Values (CSV) Files", Yakov
Shafranovich, 2022-03-19, <draft-shafranovich-rfc4180-bis-02.txt>

This RFC documents the common format used for Comma-Separated Values
(CSV) files and updates the associated MIME type "text/csv".

"DNS Resolver Information", Tirumaleswar Reddy.K, Mohamed Boucadair,

2022-08-31, <draft-reddy-add-resolver-info-06.txt>

This document specifies a method for DNS resolvers to publish

information about themselves. DNS clients can use the resolver
information to identify the capabilities of DNS resolvers.

"A Primer on the Development of MPLS", Stewart Bryant, 2022-05-09,

<draft-bryant-mpls-dev-primer-02.txt>

There has been significant recent interest in developing MPLS to

address new needs. This memo collects together various documents
 that together describe the key aspects of the MPLS architecture
together with the development proposals that the author is aware of.

The purpose of this document is to bring everyone up to speed on the

rational for the existing design and to alert them to the new
proposals.

"LAG indication", Bruno Decraene, Shraddha Hegde, Joel Halpern, 2022-08-01,

<draft-decraene-lsr-lag-indication-03.txt>

This document defines a new link flag to advertise that a layer-three

link is composed of multiple layer-two sub-links, such as when this
link is a Link Aggregation Group (LAG). This allows a large single
flow (an elephant flow) to be aware that the link capacity will be
lower than expected as this single flow is not load-balanced across
the multiple layer-two sub-links. A path computation logic may use
that information to route that elephant flow along a different path.

"Token Cell Routing Data Plane Concepts", Stewart Bryant, Alexander Clemm,
2022-05-09, <draft-bcx-rtgwg-tcr-02.txt>

Token Cell Routing is a powerful yet hardware friendly method of

constructing data plane packets to meet the needs of new
applications. It is based on the use of token cells (special kinds
of lightly structured tokens) to provide pointers to procedures pre-
positioned in the forwarding layer together with the parameters
needed to provide the required processing context. A packet can be
composed from multiple token cells as needed to result in new new
network processing and forwarding semantics.

"ND Prefix Robustness Improvements", Eduard, Paolo Volpato, Loba Olopade,

2022-09-01, <draft-vv-6man-nd-prefix-robustness-03.txt>

IPv6 prefixes could become invalid abruptly as a result of outages,

network administrator actions, or particular product shortcomings.

That could lead to connectivity problems for the hosts attached to

the subtended network.

This document has two targets: on one hand, to analyze the cases
that may lead to network prefix invalidity; on the other to develop
a root cause analysis for those cases and propose a solution.

This may bring to extensions of the protocols used to convey prefix

information and other options.

This document updates RFC 4861 and RFC 4862.

"Framework for End-to-End IETF Network Slicing", Zhenbin Li, Jie Dong, Ran
Pang, Yongqing Zhu, 2022-03-07,
<draft-li-teas-e2e-ietf-network-slicing-02.txt>

Network slicing can be used to meet the connectivity and performance

requirement of different services or customers in a shared network.
An IETF network slice may be used for 5G or other network scenarios.
In the context of 5G, the 5G end-to-end network slices consist of
three major types of network technology domains: Radio Access Network
(RAN), Transport Network (TN) and Core Network (CN). The transport
network slice can be realized as IETF network slices. In the
 transport network, the IETF network slice may span multiple network
administrative domains.

In order to facilitate the mapping between network slices in

different network technology domains and administrative domains, it
is beneficial to carry the identifiers related to the 5G end-to-end
network slice, the multi-domain IETF network slice together with the
intra-domain network slice related identifier in the data packet.

This document describes the framework of end-to-end IETF network

slicing, and introduces the identifiers related to 5G end-to-end
network slice and the multi-domain IETF network slice. These
identifiers can be carried in the data packet. The roles of the
different identifiers in packet forwarding is also described. The
network slice identifiers may be instantiated with different data
planes.

"Data Transmission Security of Identity Resolution in Industrial Internet",

Bin Wang, Kezhang Lin, Chonghua Wang, Xing Wang, 2022-04-14,
<draft-wang-data-transmission-security-irii-02.txt>

This draft provides an overview of the security of data transmission

in the identity resolution system for the Industrial Internet.
Identity resolution systems play a vital role in the Industrial
Internet by providing secure sharing and intelligent association of
heterogeneous information among different organizations. This draft
focuses on the security services that identity resolution systems
should provide for resolution data transmission.

"Deterministic Networking (DetNet): Packet Ordering Function", Balazs

Varga, Janos Farkas, Stephan Kehrer, Tobias Heer, 2022-04-25,
<draft-varga-detnet-pof-03.txt>

Replication and Elimination functions of DetNet [RFC8655] may result

in out-of-order packets, which may not be acceptable for some time-
sensitive applications. The Packet Ordering Function (POF) algorithm
described herein enables to restore the correct packet order when
replication and elimination functions are used in DetNet networks.

"Border Gateway Protocol 4 (BGP-4) Send Hold Timer", Job Snijders, Ben
Cartwright-Cox, 2022-08-19, <draft-spaghetti-idr-bgp-sendholdtimer-08.txt>

This document defines the SendHoldTimer session attribute for the

Border Gateway Protocol (BGP) Finite State Machine (FSM).
Implementation of a SendHoldTimer should help overcome situations
where BGP sessions are not terminated after it has become detectable
for the local system that the remote system is not processing BGP
messages. For robustness, this document specifies that the local
system should close BGP connections and not solely rely on the remote
system for session closure when BGP timers have expired. This
document updates RFC4271.

"Retrieving information about Object Identifiers using a text-based

protocol", Daniel Marschall, 2022-07-24, <draft-viathinksoft-oidip-04.txt>

This document defines a method for retrieving information about

Object Identifiers (OIDs) and their associated Registration
Authorities (RAs) through a text-based protocol, in a way that is
both human-readable and machine-readable. Besides a text output
 format, OID-IP also supports sending information in JSON and XML.

"Segment Routing for End-to-End IETF Network Slicing", Zhenbin Li, Jie
Dong, Ran Pang, Yongqing Zhu, 2022-07-10,
<draft-li-spring-sr-e2e-ietf-network-slicing-04.txt>

IETF network slice can be used to meet the connectivity and

performance requirement of different services or customers in a
shared network. An IETF network slice can be realized by mapping a
set of connectivity constructs to a network resource partition (NRP).
In some network scenarios, an end-to-end IETF network slice may span
multiple network domains. Within each domain, traffic of the end-to-
end network slice service is mapped to a local domain NRP.

When segment routing (SR) is used to provide multi-domain IETF

network slices, information of the local domain NRP can be specified
using special SR binding segments which is called NRP binding
segments (NRP BSID). Then a multi-domain IETF network slice can be
specified using a list of NRP BSIDs in the packet, each of which is
used by the corresponding domain edge nodes to steer the traffic of
end-to-end IETF network slice into the specific local domain NRP.

This document describes the functionality of NRP binding segment and

its instantiation in SR-MPLS and SRv6 data plane.

"Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou,
Lifen Zhou, 2022-06-18, <draft-dai-netconf-quic-netconf-over-quic-02.txt>

The Network Configuration Protocol (NETCONF) provides mechanisms to

install, manipulate, and delete the configuration of network devices.
At present, almost all implementations of NETCONF are based on TCP
based protocol. QUIC, a new UDP-based, secure and multiplexed transport
protocol, can facilitate to improve the transportation performance,
information security and resource utility when being used as an
infrastructure layer of NETCONF. This document describes how to use the
QUIC protocol as the transport protocol of NETCONF(It is so called
NETCONFoQUIC).

"Generating Password-based Keys Using the GOST Algorithms", Karelina

Ekaterina, 2022-07-25, <draft-pkcs5-gost-07.txt>

This document specifies how to use the Password-Based Cryptography

Specification version 2.1 (PKCS #5) defined in RFC8018 to generate a
symmetric key from a password in conjunction with the Russian
national standard GOST algorithms.

PKCS #5 applies a pseudorandom function (a cryptographic hash,

cipher, or HMAC) to the input password along with a salt value and
repeats the process many times to produce a derived key.

This specification is developed outside the IETF and is published to

facilitate interoperable implementations that wish to support the
GOST algorithms. This document does not imply IETF endorsement of
the cryptographic algorithms used in this document.

"Protected QUIC Initial Packets", Martin Duke, David Schinazi, 2022-04-27,

<draft-duke-quic-protected-initial-04.txt>

QUIC encrypts its Initial Packets using keys derived from well-known
 constants, meaning that observers can inspect the contents of these
packets and successfully spoof them. This document proposes a new
version of QUIC that encrypts Initial Packets more securely by
leveraging a Public Key distributed via the Domain Name System (DNS)
or other out-of-band system.

"A Survey of Semantic Internet Routing Techniques", Daniel King, Adrian

Farrel, 2022-05-30, <draft-king-irtf-semantic-routing-survey-04.txt>

The Internet Protocol (IP) has become the global standard in any
computer network, independent of the connectivity to the Internet.
Generally, an IP address is used to identify an interface on a
network device. Routing protocols are also required and developed
based on the assumption that a destination address has this semantic
with routing decisions made on addresses and additional fields in the
packet headers.

Over time, routing decisions were enhanced to route packets according

to additional information carried within the packets and dependent on
policy coded in, configured at, or signaled to the routers. Many
proposals have been made to add semantics to IP addresses. The
intent is usually to facilitate routing decisions based solely on the
address and without finding and processing information carried in
other fields within the packets.

This document is presented as a survey to support the study and

further research into clarifying and understanding the issues. It
does not pass comment on the advisability or practicality of any of
the proposals and does not define any technical solutions

"Internet of Secure Elements", Pascal Urien, 2022-04-03,

<draft-urien-coinrg-iose-05.txt>

This draft defines an infrastructure for secure elements over

internet, and features needed for their secure remote use.
It describes a network architecture based on the TLS 1.3 protocol,
which enables remote calls of cryptographic procedures, identified
by Unified Resource Identifier (URI) such as
schemeS://sen@server.com:443/?query
The Internet of Secure Element (IoSE) is a set of secure elements
providing TLS servers, communication interfaces, and identified by
their name (Secure Element Name, sen).

"Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814

Pseudorandom Port Numbers", Gabor Lencse, Keiichi Shima, 2022-06-30,
<draft-lencse-bmwg-benchmarking-stateful-04.txt>

RFC 2544 has defined a benchmarking methodology for network

interconnect devices. RFC 5180 addressed IPv6 specificities and it
also provided a technology update, but excluded IPv6 transition
technologies. RFC 8219 addressed IPv6 transition technologies,
including stateful NAT64. However, none of them discussed how to
apply RFC 4814 pseudorandom port numbers to any stateful NATxy
(NAT44, NAT64, NAT66) technologies. We discuss why using
pseudorandom port numbers with stateful NATxy gateways is a difficult
problem. We recommend a solution limiting the port number ranges and
using two phases: the preliminary phase and the real test phase. We
show how the classic performance measurement procedures (e.g.
throughput, frame loss rate, latency, etc.) can be carried out. We
 also define new performance metrics and measurement procedures for
maximum connection establishment rate, connection tear down rate and
connection tracking table capacity measurements.

"Use of an MPLS LSE as an Ancillary Data Pointer", Stewart Bryant,

Alexander Clemm, Toerless Eckert, 2022-08-06,
<draft-bryant-mpls-aux-data-pointer-01.txt>

The purpose of this memo is to describe how Label Stack Entries

(LSEs) can be used to point to ancillary or meta-data carried below
the MPLS label stack.

"HESP - High Efficiency Streaming Protocol", Pieter-Jan Speelmans,

2022-05-13, <draft-theo-hesp-02.txt>

This document describes a protocol for delivering multimedia data,

enabling ultra-low latency and fast channel change over HTTP
networks. It specifies the data format of the files and the actions
to be taken by the server (sender) and the clients (receivers) of the
streams. It describes version 1 of this protocol.

"Attestation of File Content using an X.509 Certificate", Chuck Lever,

2022-05-04, <draft-cel-nfsv4-hash-tree-interchange-format-03.txt>

This document describes a compact open format for transporting and

storing an abbreviated form of a cryptographically signed hash tree.
Receivers use this representation to reconstitute the hash tree and
verify the integrity of file content protected by that tree.

An X.509 certificate encapsulates and protects the hash tree metadata

and provides cryptographic provenance. Therefore this document
updates the Internet X.509 certificate profile specified in RFC 5280.

"BGP Flow Specification for DetNet and TSN Flow Mapping", Quan Xiong,
Haisheng Wu, Junfeng Zhao, 2022-03-06,
<draft-xiong-idr-detnet-flow-mapping-02.txt>

This document proposes extensions to BGP Flow Specification for the

flow mapping of Deterministic Networking (DetNet) when interconnected
with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is
used for the filtering of the packets that match the DetNet newtworks
and the mapping between TSN streams and DetNet flows in the control
plane.

"RADIUS Extensions for Encrypted DNS", Mohamed Boucadair, Tirumaleswar

Reddy.K, 2022-06-07, <draft-boucadair-opsawg-add-encrypted-dns-05.txt>

This document specifies new Remote Authentication Dial-In User

Service (RADIUS) attributes that carry an authentication domain name,
a list of IP addresses, and a set of service parameters of encrypted
DNS resolvers.

"Deterministic Networking (DetNet): OAM Functions for The Service

Sub-Layer", Balazs Varga, Janos Farkas, Greg Mirsky, 2022-07-25,
<draft-varga-detnet-service-sub-layer-oam-03.txt>

Operation, Administration, and Maintenance (OAM) tools are essential

for a deterministic network. The DetNet architecture [RFC8655] has
defined two sub-layers: (1) DetNet service sub-layer and (2) DetNet
 forwarding sub-layer. OAM mechanisms exist for the DetNet forwarding
sub-layer. Nonetheless, OAM for the service sub-layer might require
new extensions to the existing OAM protocols. This draft presents an
analysis of OAM procedures for the DetNet service sub-layer
functions.

"Gateway Identification and Discovery", Shiping Chen, Thomas Hardjono, Qin

Wang, 2022-08-15, <draft-chen-dlt-gateway-identification-01.txt>

[SATP] is a secure asset transfer protocol that operates between two

gateways. This memo describes requirements, standards and
architectural options that can be considered to identify, discover
and verify gateways before transferring secure digital assets via
SATP.

"Reinforcement Learning-Based Virtual Network Embedding: Problem

Statement", Ihsan Ullah, Youn-Hee Han, TaeYeon Kim, 2022-04-21,
<draft-ihsan-nmrg-rl-vne-ps-02.txt>

In Network virtualization (NV) technology, Virtual Network Embedding

(VNE) is an algorithm used to map a virtual network to the substrate
network. VNE is the core orientation of NV which has a great impact
on the performance of virtual network and resource utilization of the
substrate network. An efficient embedding algorithm can maximize the
acceptance ratio of virtual networks to increase the revenue for
Internet service provider. Several works have been appeared on the
design of VNE solutions, however, it has becomes a challenging issues
for researchers. To solved the VNE problem, we believe that
reinforcement learning (RL) can play a vital role to make the VNE
algorithm more intelligent and efficient. Moreover, RL has been
merged with deep learning techniques to develop adaptive models with
effective strategies for various complex problems. In RL, agents can
learn desired behaviors (e.g, optimal VNE strategies), and after
learning and completing training, it can embed the virtual network to
the subtract network very quickly and efficiently. RL can reduce the
complexity of the VNE algorithm, however, it is too difficult to
apply RL techniques directly to VNE problems and need more research
study. In this document, we presenting a problem statement to
motivate the researchers toward the VNE problem using deep
reinforcement learning.

"Deterministic Nonce-less Hybrid Public Key Encryption", Dan Harkins,

2022-08-09, <draft-harkins-cfrg-dnhpke-02.txt>

This document describes enhancements to the Hybrid Public Key

Encryption standard published by CFRG. These include use of "compact
representation" of relevant public keys, support for key-wrapping,
and two ways to address the use of HPKE on lossy networks: a
determinstic, nonce-less AEAD scheme, and use of a rolling sequence
number with existing AEAD schemes.

"Sliding Window Selective Linear Code (SLC) Forward Error Correction (FEC)
Scheme for FECFRAME", Ray Wang, Liang Si, Bifeng He, 2022-06-14,
<draft-wang-tsvwg-sw-slc-fec-scheme-03.txt>

RFC8680 describes a framework for using Sliding Window Forward Error

Correction(FEC) codes to protection against packet loss, the
framework significantly improves FEC efficiency and reduces FEC-
related added latency compared to block FEC codes defined in RFC
 6363. RFC8681 further describes two fully specified FEC schemes for
Sliding Window Random Linear Codes(RLC), the schemes rely on an
encoding window that slides over a continuous set of source symbols,
generating new repair symbols whenever needed. This document
describes a fully specified FEC scheme for Sliding Window Selective
Linear Code(SLC) over the Galois Field GF (2^^8) , compared to
RFC8681, this framework use a discrete encoding window which can
protect arbitrary media streams selectively, and has better recovery
performance in scenarios such as layered video coding or mixed
streams for video streaming applications.

"Problem Statement and Use Cases of Trustworthiness-based Routing", Tao

Lin, Hao Li, Xingang Shi, Xia Yin, Wenlong Chen, 2022-06-14,
<draft-lin-opsec-trustroute-problem-statement-02.txt>

Currently, network operators are trying to provide fine-granularity

Service Level Agreement (SLA) guarantee to achieve better Quality of
Experience (QoE) for end users and engage customers, such as ultra-
low latency and high reliability service. However, with increasing
security threats, differentiated QoE services are insufficient, the
demands for more differentiated security service are emerging.

This document explores the requirements for differentiated security

services and identifies the scenarios for network operators. To
provide differentiated security services, possible trustworthiness-
based routing solution is discussed.

"NTP Over PTP", Miroslav Lichvar, 2022-05-30,

<draft-mlichvar-ntp-over-ptp-02.txt>

This document specifies a transport for the Network Time Protocol

(NTP) client-server mode using the Precision Time Protocol (PTP) to
enable hardware timestamping on hardware that can timestamp PTP
messages but not NTP messages.

"SRv6-based BGP Service Capability", Liu Yao, Zheng Zhang, Eduard Metz,
2022-06-14, <draft-lz-bess-srv6-service-capability-03.txt>

This draft describes the problems that may be encountered during the
deployment of SRv6-based BGP services and the possible solutions.

"Multi Distribution master", haisheng yu, Daobiao Gong, Yang Song, Yan Liu,
2022-06-19, <draft-yu-dnsops-disdm-04.txt>

DM (Distribution Master) is used to transfer zone file data between

the registry and the authoritative server. The centralized DM system
has the risk of a single point of failure. The distributed DM
architecture allows nodes to join and exit at any time to solve the
single point of failure problem.

"Complaint Feedback Loop Address Header", Jan-Philipp Benecke, 2022-06-15,

<draft-benecke-cfbl-address-header-07.txt>

This document describes a method that allows an email sender to

specify a complaint feedback loop (FBL) address as an email header.
Also it defines the rules for processing and forwarding such a
complaint. The motivation for this arises out of the absence of a
standardized and automated way to provide mailbox providers with an
address for a complaint feedback loop. Currently, providing and
 maintaining such an address is a manual and time-consuming process
for email senders and providers.

It is unclear, at the time of publication, whether the function

provided by this document has widespread demand, and whether the
mechanism offered will be adopted and found to be useful. Therefore,
this is being published as an Experiment, looking for a constituency
of implementers and deployers, and for feedback on the operational
utility. The document is produced through the Independent RFC stream
and was not subject to the IETF's approval process.

"CDNI Metadata Model Extensions", Glenn Goldstein, Will Power, Guillaume

Bichot, Alfonso Siloniz, 2022-03-07,
<draft-goldstein-cdni-metadata-model-extensions-02.txt>

The Content Delivery Network Interconnection (CDNI) Metadata

interface enables interconnected Content Delivery Networks (CDNs) to
exchange content distribution metadata in order to enable content
acquisition and delivery. To facilitate a wider set of use cases
such as Open Caching, this document describes extensions to the CDNI
Metadata object model and its associated Capabilities model as
documented in "CDNI Metadata" RFC8006 and "CDNI Request Routing:
Footprint and Capabilities Semantics" RFC8008 .

This document is a reflection of the content in the Streaming Video

Alliance specification titled "SVA Configuration Interface: Part 2
Extensions to CDNI Metadata Object Model".

"Problems and Requirements of Satellite Constellation for Internet", Lin

Han, Richard Li, Alvaro Retana, chenmeiling, Li Su, Tianji Jiang, Ning
Wang, 2022-07-06, <draft-lhan-problems-requirements-satellite-net-03.txt>

This document presents the detailed analysis about the problems and
requirements of satellite constellation used for Internet. It starts
from the satellite orbit basics, coverage calculation, then it
estimates the time constraints for the communications between
satellite and ground-station, also between satellites. How to use
satellite constellation for Internet is discussed in detail including
the satellite relay and satellite networking. The problems and
requirements of using traditional network technology for satellite
network integrating with Internet are finally outlined.

"IS-IS and OSPF Extension for Event Notification", Peter Psenak, Les
Ginsberg, Ketan Talaulikar, 2022-03-07,
<draft-ppsenak-lsr-igp-event-notification-01.txt>

Link-state protocols like IS-IS and OSPF have been designed to

distribute state information - state of the local adjacencies, state
of the local prefix reachability, etc. Each state can have
additional attributes associated with it, but all the attributes are
only meaningful while the state exists.

This document extends link-state IGPs to distribute event

notifications. An event notification has a very limited lifetime.
It is rapidly propagated across the network and leaves no state after
its lifetime.

"Applications Multiplexing a QUIC Session", Jiao Kang, liangqiandeng,

Shangling Deng, Peng Liu, 2022-06-16,
<draft-kang-quic-apps-multiplexing-a-session-01.txt>

This document describes the requirements for extensions on QUIC

transport protocol in the use case when multiple application
protocols reuse the same QUIC session for data transmission.

"Supporting leaves without northbound neighbors connecting to a fat-tree

network using RIFT", Zheng Zhang, Yuehua Wei, BenChong Xu, 2022-07-03,
<draft-zwx-rift-leaf-ring-01.txt>

This document discusses the usage and solution for leaf nodes without
northbound neighbors connecting to a fat-tree network by leaf nodes
having direct northbound neighbors in RIFT.

"BGP Dissemination of FlowSpec for Transport Aware Mobility", Linda Dunbar,

Kausik Majumdar, Uma Chunduri, 2022-06-27,
<draft-dmc-idr-flowspec-tn-aware-mobility-02.txt>

This document defines a BGP Flow Specification (flowSpec)

extension to disseminate flows from 5G mobile networks so that
the 5G mobile systems slices and Service Types (SSTs) can be
mapped to optimal underlying network paths in the data network
outside the 5G UPFs, or the N6 interface in 3GPP 5G
Architecture [3GPP TR 23.501].

"Verification of Routes Using Region Authorization", Chen Shen, Tianran

Zhou, Yisong Liu, Wenyan Yu, Haibo Wang, Shunwan Zhuang, Shuanglong Chen,
2022-08-16, <draft-shen-sidrops-region-verification-02.txt>

BGP routing security is becoming a major issue that affects the

normal running of Internet services. Currently, there are many
solutions, including ROA authentication and ASPA authentication, to
prevent route source hijacking, path hijacking, and route leaking.
However, on an actual network, large ISPs with multiple ASes can use
carefully constructed routes to bypass ROA and ASPA authentication to
attack the target network.

This document defines an region-based authentication method for large

ISPs with many ASes to prevent traffic hijacking within ISPs.

"RSVP for TSN Networks", Dirk Trossen, Juergen Schmitt, 2022-07-07,

<draft-trossen-detnet-rsvp-tsn-02.txt>

This document provides a solution for control plane signaling by

virtue of proposing changes to RSVP signaling with deterministic
services at the underlying TSN enabled layer. The solution covers
distributed, centralized, and hybrid signaling scenarios in the TSN
and SDN domain. The proposed changes to RSVP IntServ, called RSVP TSN
in the remainder of this document, provide a better integration with
Layer 2 technologies for resource reservation, for which we outline
example API specifications for the realization of RSVP TSN.

"Generic Metric for the AIGP attribute", Srihari Sangli, Shraddha Hegde,
Reshma Das, Bruno Decraene, 2022-07-11,
<draft-ssangli-idr-bgp-generic-metric-aigp-03.txt>

This document defines extensions to the AIGP attribute to carry

Generic Metric sub-types. This is applicable when multiple domains
exchange BGP routing information. The extension will aid in intent-
 based end-to-end path selection.

"IGMP/MLD Extension for Multicast Source Management", Huanan Li, Aijun

Wang, Stig Venaas, 2022-05-19,
<draft-li-pim-igmp-mld-extension-source-management-03.txt>

This document describes extensions to Internet Group Management

Protocol (IGMP) and Multicast Listener Discover (MLD) protocol for
supporting interaction between multi cast sources and routers,
accomplishing multi cast source management.

"Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil
Cook, Mohamed Boucadair, 2022-06-28,
<draft-wing-dnsop-structured-dns-error-page-04.txt>

DNS filtering is widely deployed for network security, but filtered

DNS responses lack information for the end user to understand the
reason for the filtering. Existing mechanisms to provide detail to
end users cause harm especially if the blocked DNS response is to an
HTTPS website.

This document updates the EXTRA-TEXT field of Extended DNS Error to

provide details on the DNS filtering. This information can be parsed
by the client and displayed, logged, or used for other purposes.

This document updates RFC 8914.

"Transmission of SCHC-compressed packets over IEEE 802.15.4 networks",

Carles Gomez, Ana Minaburo, 2022-07-10, <draft-gomez-6lo-schc-15dot4-03.txt>

A framework called Static Context Header Compression and

fragmentation (SCHC) has been designed with the primary goal of
supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies
[RFC8724]. One of the SCHC components is a header compression
mechanism. If used properly, SCHC header compression allows a
greater compression ratio than that achievable with traditional
6LoWPAN header compression [RFC6282]. For this reason, it may make
sense to use SCHC header compression in some 6LoWPAN environments,
including IEEE 802.15.4 networks. This document specifies how a
SCHC-compressed packet can be carried over IEEE 802.15.4 networks.

"Encoding Network Slice Identification for SRv6", Weiqiang Cheng, Changwang

Lin, Liyan Gong, Shay Zadok, xuewei wang, 2022-07-07,
<draft-cheng-spring-srv6-encoding-network-sliceid-04.txt>

This document describe a method to encode network slicing identifier

within SRv6 domain.

"YANG Data Model for Topology Filter", Vishnu Beeram, Tarek Saad, Rakesh
Gandhi, Xufeng Liu, 2022-03-07,
<draft-bestbar-teas-yang-topology-filter-03.txt>

This document defines a YANG data model for the management of

topology filters/filter-sets on network elements and controllers.

"OSCORE-capable Proxies", Marco Tiloca, Rikard Hoeglund, 2022-07-11,

<draft-tiloca-core-oscore-capable-proxies-03.txt>

Object Security for Constrained RESTful Environments (OSCORE) can be

 used to protect CoAP messages end-to-end between two endpoints at the
application layer, also in the presence of intermediaries such as
proxies. This document defines how to use OSCORE for protecting CoAP
messages also between an origin application endpoint and an
intermediary, or between two intermediaries. Also, it defines how to
secure a CoAP message by applying multiple, nested OSCORE
protections, e.g., both end-to-end between origin application
endpoints, as well as between an application endpoint and an
intermediary or between two intermediaries. Thus, this document
updates RFC 8613. The same approach can be seamlessly used with
Group OSCORE, for protecting CoAP messages when group communication
with intermediaries is used.

"Service Function Chaining (SFC) Parallelism and Diversions", Donald

Eastlake, 2022-05-31, <draft-eastlake-sfc-parallel-03.txt>

Service Function Chaining (SFC) is the processing of packets through

a sequence of Service Functions (SFs) within an SFC domain by the
addition of path information and metadata on entry to that domain,
the use and modification of that path information and metadata to
step the packet through a sequence of SFs, and the removal of that
path information and metadata on exit from that domain. The IETF has
standardized a method for SFC using the Network Service Header
specified in RFC 8300.

There are requirements for SFC to process packets through parallel

sequences of service functions and to easily splice in additional
service functions or splice service functions out of a service chain.
This document provides use cases for these requirements and
extensions to SFC to support them.

"IKEv2 support for per-queue Child SAs", Antony Antony, Tobias Brunner,
Steffen Klassert, Paul Wouters, 2022-08-31,
<draft-pwouters-ipsecme-multi-sa-performance-04.txt>

This document defines three Notify Message Type Payloads for the
Internet Key Exchange Protocol Version 2 (IKEv2) indicating support
for the negotiation of multiple identical Child SAs to optimize
performance.

The CPU_QUEUES notification indicates support for multiple queues or

CPUs. The CPU_QUEUE_INFO notification is used to confirm and
optionally convey information about the specific queue. The
TS_MAX_QUEUE notify conveys that the peer is unwilling to create more
additional Child SAs for this particular Traffic Selector set.

Using multiple identical Child SAs has the benefit that each stream
has its own Sequence Number Counter, ensuring that CPUs don't have to
synchronize their crypto state or disable their packet replay
protection.

"Selectively Applying Host Isolation to Simplify IPv6 First-hop

Deployment", XiPeng Xiao, Eduard, Eduard Metz, Gyan Mishra, 2022-07-01,
<draft-xiao-v6ops-nd-deployment-guidelines-02.txt>

Neighbor Discovery (ND) is the key protocol of IPv6 first-hop. ND

uses multicast extensively and trusts all hosts. In some scenarios
like wireless networks, multicast can be inefficient. In other
scenarios like public access networks, hosts may not be trustable.
 Consequently, ND issues may happen in various scenarios. The issues
and solutions are documented in more than 30 RFCs. It is difficult
to keep track of all these issues and solutions, and how the various
solutions fit together. Therefore, deployment guidelines are needed.

This document firstly summarizes the known ND issues and

optimization solutions into a one-stop reference. Analyzing these
solutions reveals an insight: isolating hosts is effective in
solving ND issues. Four isolation methods are proposed and their
applicability is discussed. Guidelines are then described for
selecting a suitable isolation method based on the deployment
scenario.

"EAP Usability", Alan DeKok, 2022-03-05,

<draft-dekok-emu-eap-usability-01.txt>

This document defines methods which enable simpler deployment of TLS-

based EAP methods. It defines new certificate fields, and uses
existing certificate fields in order describe new methods for
bootstrapping security. The methods defined here change TLS-based
EAP supplicant configuration from a complex and insecure process to
one that is automated, and is essentially trivial. These methods are
still, however, compatible with existing standards and practices.

"RUSH - Reliable (unreliable) streaming protocol", Kirill Pugin, Alan

Frindell, Jordi Cenzano, Jake Weissman, 2022-03-07,
<draft-kpugin-rush-01.txt>

RUSH is an application-level protocol for ingesting live video. This

document describes the protocol and how it maps onto QUIC.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the mailing list (), which
is archived at .

Source for this draft and an issue tracker can be found at

https://github.com/afrind/draft-rush.

"Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS Networks",

Rakesh Gandhi, Patrice Brissette, Eddie Leyton, 2022-07-11,
<draft-gandhi-mpls-stamp-pw-02.txt>

Pseudowires (PWs) are used in MPLS networks for various services

including carrying layer 2 and layer 3 data packets. This document
describes the procedure for encapsulation of the Simple Two-Way
Active Measurement Protocol (STAMP) defined in RFC 8762 and its
optional extensions defined in RFC 8972 for PWs in MPLS networks.
The procedure uses PW Generic Associated Channel (G-ACh) to
encapsulate the STAMP test packets with or without an IP/UDP header.

"Concise Reference Integrity Manifest", Henk Birkholz, Thomas Fossati,

Yogesh Deshpande, Ned Smith, Wei Pan, 2022-07-11,
<draft-birkholz-rats-corim-03.txt>

Remote Attestation Procedures (RATS) enable Relying Parties to assess

the trustworthiness of a remote Attester and therefore to decide
 whether to engage in secure interactions with it. Evidence about
trustworthiness can be rather complex and it is deemed unrealistic
that every Relying Party is capable of the appraisal of Evidence.
Therefore that burden is typically offloaded to a Verifier. In order
to conduct Evidence appraisal, a Verifier requires not only fresh
Evidence from an Attester, but also trusted Endorsements and
Reference Values from Endorsers and Reference Value Providers, such
as manufacturers, distributors, or device owners. This document
specifies Concise Reference Integrity Manifests (CoRIM) that
represent Endorsements and Reference Values in CBOR format.
Composite devices or systems are represented by a collection of
Concise Module Identifiers (CoMID) and Concise Software Identifiers
(CoSWID) bundled in a CoRIM document.

"Security and Privacy Considerations for Multicast Transports", Kyle Rose,

Jake Holland, 2022-07-11, <draft-krose-multicast-security-03.txt>

Interdomain multicast has unique potential to solve delivery

scalability for popular content, but it carries a set of security and
privacy issues that differ from those in unicast delivery. This
document analyzes the security threats unique to multicast-based
delivery for Internet and Web traffic under the Internet and Web
threat models.

"Composite Public and Private Keys For Use In Internet PKI", Mike
Ounsworth, Massimiliano Pala, Jan Klaussner, 2022-06-08,
<draft-ounsworth-pq-composite-keys-02.txt>

The migration to post-quantum cryptography is unique in the history

of modern digital cryptography in that neither the old outgoing nor
the new incoming algorithms are fully trusted to protect data for the
required data lifetimes. The outgoing algorithms, such as RSA and
elliptic curve, may fall to quantum cryptalanysis, while the incoming
post-quantum algorithms face uncertainty about both the underlying
mathematics as well as hardware and software implementations that
have not had sufficient maturing time to rule out classical
cryptanalytic attacks and implementation bugs.

Cautious implementors may wish to layer cryptographic algorithms such

that an attacker would need to break all of them in order to
compromise the data being protected. For digital signatures, this is
referred to as "dual", and for encryption key establishment this as
reffered to as "hybrid". This document, and its companions, defines
a specific instantiation of the dual and hybrid paradigm called
"composite" where multiple cryptographic algorithms are combined to
form a single key, signature, or key encapsulation mechanism (KEM)
such that they can be treated as a single atomic object at the
protocol level.

EDNOTE: the terms "dual" and "hybrid" are currently in flux. We

anticipate an Informational draft to normalize terminology, and will
update this draft accordingly.

This document defines the structures CompositePublicKey and

CompositePrivateKey, which are sequences of the respective structure
for each component algorithm. The generic composite variant is
defined which allows arbitrary combinations of key types to be placed
in the CompositePublicKey and CompositePrivateKey structures without
needing the combination to be pre-registered or pre-agreed. The
 explicit variant is also defined which allows for a set of algorithm
identifier OIDs to be registered together as an explicit composite
algorithm and assigned an OID.

This document is intended to be coupled with corresponding documents

that define the structure and semantics of composite signatures and
encryption, such as [draft-ounsworth-pq-composite-sigs-05] and draft-
ounsworth-pq-composite-kem (yet to be published).

"Interconnecting Limited Domains Based on Declared Communication

Requirements", Carsten Bormann, 2022-07-11,
<draft-bormann-t2trg-interconnect-declared-02.txt>

"Limited Domains" are parts of an internet that may have notable

differences or are just convenient to separate from the general
Internet and can be delimited from that and from other Limited
Domains by a defined boundary (the "border").

This memo focuses on the case where the nodes inside the Limited
Domain want to interact with nodes on (or reachable via) the general
Internet, but need some assistance at the border that is cognizant
about the specific properties of the nodes in the Limited Domain.

Self-Descriptions can provide the information needed for this

assistance.

"Autoconfiguration of infrastructure services in ACP networks via DNS-SD

over GRASP", Toerless Eckert, Mohamed Boucadair, Christian Jacquenet,
Michael Behringer, 2022-03-04,
<draft-eckert-anima-services-dns-autoconfig-01.txt>

This document defines standards that enable autoconfiguration of

fundamental centralized or decentralized network infrastructure
services on ACP network nodes via GRASP. These are primarily the
services required for initial bootstrapping of a network but will
persist through the lifecycles of the network. These services
include secure remote access to zero-touch bootstrapped ANI devices
via SSH/Netconf with Radius/Diameter authentication and authorization
and provides lifecycle autoconfiguration for other crucial services
such as syslog, NTP (clock synchronization) and DNS for operational
purposes.

"A summary of security-enabling technologies for IoT devices", Brendan

Moran, 2022-07-11, <draft-moran-iot-nets-01.txt>

The IETF has developed security technologies that help to secure the
Internet of Things even over constrained networks and when targetting
constrained nodes. These technologies can be used independenly or
can be composed into larger systems to mitigate a variety of threats.
This documents illustrates an overview over these technologies and
highlights their relationships. Ultimately, a threat model is
presented as a basis to derive requirements that interconnect
existing and emerging solution technologies.

"HTTP Datagrams, UDP Proxying, and Extensible Prioritization", Lucas

Pardue, 2022-07-25, <draft-pardue-masque-dgram-priority-02.txt>

Application protocols using the QUIC transport protocol rely on

streams, and optionally the unreliable datagram extension, to carry
 application data. Streams and datagrams can be multiplexed in single
connections but QUIC does not define an interoperable prioritization
scheme or signaling mechanism. The HTTP Extensible Prioritization
scheme describes an application-level scheme for the prioritization
of streams in HTTP/2 and HTTP/3. This document defines how
Extensible Priorities can be augmented to apply to the multiplexing
of HTTP datagram flows with other flows or streams.

"Transient Hiding of Hop-by-Hop Options", Donald Eastlake, 2022-07-08,

<draft-eastlake-6man-hide-options-03.txt>

There are increasing requests for a variety IPv6 hop-by-hop options

but such IPv6 options are poorly handled, particularly by high-speed
routers in the core Internet where packets having options are
commonly discarded. This document proposes a simple method of
transiently hiding such options for part of a packet's path to
protect the packet from discard.

"KEM-based Authentication for TLS 1.3", Sofia Celi, Peter Schwabe, Douglas
Stebila, Nick Sullivan, Thom Wiggers, 2022-03-07,
<draft-celi-wiggers-tls-authkem-01.txt>

This document gives a construction for a Key Encapsulation Mechanism

(KEM)-based authentication mechanism in TLS 1.3. This proposal
authenticates peers via a key exchange protocol, using their long-
term (KEM) public keys.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the mailing list (), which
is archived at .

Source for this draft and an issue tracker can be found at

https://github.com/claucece/draft-celi-wiggers-tls-authkem.

"MPLS Data Plane Encapsulation for In-situ OAM Data", Rakesh Gandhi, Zafar
Ali, Frank Brockners, Bin Wen, Bruno Decraene, Voitek Kozak, 2022-07-06,
<draft-gandhi-mpls-ioam-05.txt>

In-situ Operations, Administration, and Maintenance (IOAM) is used

for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
This document defines how IOAM data fields are transported with MPLS
data plane encapsulation using MPLS Network Action (MNA) with new
Generic Associated Channel (G-ACh) and updates the RFC 5586.

"Automatic Replication of DNS-SD Service Registration Protocol Zones", Ted

Lemon, Abtin Keshavarzian, Jonathan Hui, 2022-07-11,
<draft-lemon-srp-replication-02.txt>

This document describes a protocol that can be used for ad-hoc

replication of a DNS zone by multiple servers where a single primary
DNS authoritative server is not available and the use of stable
storage is not desirable.

"YANG Data Model for Bidirectional Forwarding Detection (BFD) Hardware

Offloaded Session", VELUCHAMY Rajaguru, 2022-08-23,
<draft-rvelucha-bfd-offload-yang-03.txt>

This document defines a extension YANG data model that can be used to
manage Hardware Offloaded Bidirectional Forwarding Detection (BFD).

This document specially talks about BFD sessions that are offloaded
to hardware.

The YANG modules in this document conform to the Network Management

Datastore Architecture (NMDA).

"Advertisement of Stub Link Attributes", Aijun Wang, Zhibo Hu, Acee Lindem,
Gyan Mishra, Jinsong Sun, 2022-05-16,
<draft-wang-lsr-stub-link-attributes-04.txt>

This document describes the mechanism that can be used to advertise

the stub link attributes within the ISIS or OSPF domain.

"MTU propagation over EVPN Overlays", DIKSHIT Saumya, Vinayak Joshi, A

Nayak, 2022-08-04,
<draft-saum-nvo3-mtu-propagation-over-evpn-overlays-02.txt>

Path MTU Discovery between end-host-devices/Virtual-Machines/servers/

workloads connected over an EVPN-Overlay Network in
Datacenter/Campus/enterprise deployment, is a problem, yet to be
resolved in the standards forums. It needs a converged solution to
ensure optimal usage of network and computational resources of the
networking elements, including underlay routers/switches,
constituting the overlay network. This documents takes leads from
the guidelines presented in [RFC4459].

The overlay connectivity can pan across various sites (geographically

seperated or collocated) for realizing a Datacenter Interconnect or
intersite VPNs between campus sites (buildings, branch offices etc).

This literature intends to solve problem of icmp error propagation

from an underlay routing/switching device to an end-host (hooked to
EVPN overlay), thus facilitating "accurate MTU" learnings.

This document also leverages the icmp multipart message extension,

mentioned in [RFC4884] to carry the original packet in the icmp PDU.

"Mathematical Mesh 3.0 Part VI: Reliable User Datagram", Phillip

Hallam-Baker, 2022-04-20, <draft-hallambaker-mesh-rud-01.txt>

A presentation layer suitable for use in conjunction with HTTP and

UDP transports is described.

https://mailarchive.ietf.org/arch/browse/mathmesh/
(http://whatever)Discussion of this draft should take place on the
MathMesh mailing list (mathmesh@ietf.org), which is archived at .

"Knowledge Transmission Using Distributed Denial-of-Service Open Threat

Signaling (DOTS) Data Channel", Kun Li, Hua-chun Zhou, Zhe Tu, Feiyang Liu,
Weilin Wang, 2022-08-26, <draft-li-dots-knowledge-trans-03.txt>

DOTS Knowledge Trans August 2022

 The document specifies new DOTS data channel configuration parameters
that customize the DDoS knowledge transmission configuration between
distributed knowledge bases. These options enable assist the
distributed knowledge base to share attack knowledge in different
fields and actively adapt to dynamically changing DDoS attacks.

"LISP Support for Dynamic Anycast Routing", Sun Kj, Younghan Kim,
2022-04-28, <draft-kjsun-lisp-dyncast-02.txt>

Dynamic Anycast (Dyncast) is a new routing approach to support

equivalent services running in distributed geolocations and connect
to them by considering both network-related metric and service-
related metric. In LISP, it is possible to support anycast EIDs and/
or anycast RLOCs without any modification, so it is suitable for
providing dyncast routing. In this document, it describes the LISP-
based dyncast architecture and related standard works to meet dyncast
requirements.

"DNS over CoAP (DoC)", Martine Lenders, Christian Amsuess, Cenk Gundogan,
Thomas Schmidt, Matthias Waehlisch, 2022-07-11,
<draft-lenders-dns-over-coap-04.txt>

This document defines a protocol for sending DNS messages over the
Constrained Application Protocol (CoAP). These CoAP messages are
protected by DTLS-Secured CoAP (CoAPS) or Object Security for
Constrained RESTful Environments (OSCORE) to provide encrypted DNS
message exchange for constrained devices in the Internet of Things
(IoT).

"The Application Specific Link Attribute (ASLA) Any Application Bit",

Shraddha Hegde, Ron Bonica, Chris Bowers, Robert Raszuk, Zhenbin Li, Dan
Voyer, 2022-07-11, <draft-hegde-lsr-asla-any-app-02.txt>

RFC 8919 and RFC 8920 define Application Specific Link Attributes
(ASLA). Each ASLA includes an Application Identifier Bit Mask. The
Application Identifier Bit Mask includes a Standard Application Bit
Mask (SABM) and a User Defined Application Bit Mask (UDABM). The
SABM and UDABM determine which applications can use the ASLA as an
input.

This document introduces a new bit to the Standard Application

Identifier Bit Mask. This bit is called the Any Application Bit
(i.e., the A-bit). If the A-bit is set, the link attribute can be
used by any application. This includes currently defined
applications as well as applications to be defined in the future.

"Defreezing Optimization post EVPN Mac Dampening", DIKSHIT Saumya, Vinayak

Joshi, Swathi Shankar, 2022-08-04,
<draft-saum-bess-dampening-backoff-05.txt>

MAC move handling in EVPN deployments is discussed in detail in

[RFC7432]. There are few optimizations which can be done in existing
way of handling the mac duplication. This document describes few of
the potential techniques to do so. This document is of informational
type based on comments in the ietf meeting.

"Data Model for Lifecycle Management and Operations", Marisol Palmero,

Frank Brockners, Sudhendu Kumar, Shwetha Bhandari, Camilo Cardona, Diego
Lopez, 2022-07-11, <draft-palmero-opsawg-dmlmo-05.txt>
 This document motivates and specifies a data model for lifecycle
management and operations. It describes the motivation and
requirements to collect asset-centric metrics including but not
limited to asset adoption and usability, licensing, supported
features and capabilities, enabled features and capabilities, etc.;
with the primary objective to measure and improve the overall user
experience along the lifecycle journey, from technical requirements
and technology selection through advocacy and renewal, including the
end of life of an asset.

"Enhanced Performance Measurement Using Simple TWAMP in Segment Routing

Networks", Rakesh Gandhi, Clarence Filsfils, Navin Vaghamshi, Moses
Nagarajah, Richard Foote, Mach Chen, Amit Dhamija, 2022-08-12,
<draft-gandhi-spring-enhanced-srpm-02.txt>

Segment Routing (SR) leverages the source routing paradigm. SR is

applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) data planes. This document defines procedure for Enhanced
Performance Measurement of end-to-end SR paths including SR Policies
for both SR-MPLS and SRv6 data planes using Simple Two-Way Active
Measurement Protocol (STAMP) defined in RFC 8762. The procedure
allows to improve the scale for number of sessions and failure
detection interval.

"I2NSF Application Interface YANG Data Model", Patrick Lingga, Jaehoon

Jeong, Yunchul Choi, 2022-04-28,
<draft-lingga-i2nsf-application-interface-dm-03.txt>

This document describes an information model and a YANG data model

for the Application Interface between an Interface to Network
Security Functions (I2NSF) Analyzer and a Security Controller in an
I2NSF system in a Network Functions Virtualization (NFV) environment.
The YANG data model described in this document is based on the I2NSF
NSF-Facing Interface and the I2NSF Monitoring Interface for enabling
feedback delivery based on the information received from a Network
Security Function (NSF).

"Stream Control Transmission Protocol (SCTP) Network Address Translation

Support", Claudio Porfiri, 2022-04-29,
<draft-porfiri-tsvwg-sctp-natsupp-03.txt>

The Stream Control Transmission Protocol (SCTP) provides a reliable

communications channel between two end-hosts in many ways similar to
the Transmission Control Protocol (TCP). With the widespread
deployment of Network Address Translators (NAT), specialized code has
been added to NAT functions for TCP that allows multiple hosts to
reside behind a NAT function and yet share a single IPv4 address,
even when two hosts (behind a NAT function) choose the same port
numbers for their connection. This additional code is sometimes
classified as Network Address and Port Translation (NAPT).

This document describes the protocol extensions needed for the SCTP
endpoints and the mechanisms for NAT functions necessary to provide
similar features of NAPT in the single point and multipoint traversal
scenario.

"hashlookup format", Alexandre Dulaunoy, Jean-Louis Huynen, 2022-06-23,

<draft-dulaunoy-hashlookup-format-03.txt>
 This document describes the hashlookup output format used to express
meta information of hash values seen in databases of known files.
The output description includes a common semantic. The hashlookup
format is used by public and private digital forensics investigations
services.

"All PEs as DF", DIKSHIT Saumya, Vinayak Joshi, 2022-08-04,

<draft-saumvinayak-bess-all-df-bum-04.txt>

The Designated forwarder concept is leveraged to prevent looping of

BUM traffic into tenant network sourced across NVO fabric for
multihoming deployments. [RFC7432] defines a preliminary approach to
select the DF for an ES,VLAN or ES,Vlan Group, panning across
multiple NVE's. [RFC8584] makes the election logic more robust and
fine grained by inculcating fair election of DF handling most of the
prevalent use-cases. This document presents a deployment problem and
a corresponding solution which cannot be easily resolve by rules
mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall
deployment on disparate overlay sites connected over WAN. The
requirement is to allow reachability, ONLY, to the local firewall,
unless there is an outage. In case of outage the reachability can be
extended to remote site's firewall over WAN.

"Deterministic Networking (DetNet) Data Plane - MPLS TC Tagging for Cyclic

Queuing and Forwarding (MPLS-TC TCQF)", Toerless Eckert, Stewart Bryant,
Andrew Malis, 2022-07-11, <draft-eckert-detnet-mpls-tc-tcqf-03.txt>

This memo defines the use of the MPLS TC field of MPLS Label Stack
Entries (LSE) to support cycle tagging of packets for Multiple Buffer
Cyclic Queuing and Forwarding (TCQF). TCQF is a mechanism to support
bounded latency forwarding in DetNet network.

Target benefits of TCQF include low end-to-end jitter, ease of high-

speed hardware implementation, optional ability to support large
number of flow in large networks via DiffServ style aggregation by
applying TCQF to the DetNet aggregate instead of each DetNet flow
individually, and support of wide-area DetNet networks with arbitrary
link latencies and latency variations.

"Reputation Verified Selection of Upstream Encrypted Resolvers", Benjamin

Schwartz, Chris Box, 2022-07-08, <draft-schwartz-add-ddr-forwarders-02.txt>

This draft describes an extension to the Discovery of Designated

Resolvers (DDR) standard, enabling use of encrypted DNS in the
presence of legacy DNS forwarders.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the mailing list

(add@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/add/.

Source for this draft and an issue tracker can be found at

https://github.com/bemasc/ddr-forwarders.

"HTTP Datagram PING and TIMESTAMP", Benjamin Schwartz, 2022-05-26,

<draft-schwartz-masque-h3-datagram-ping-02.txt>

This draft defines new mechanisms for measuring the functionality and
performance of an HTTP Datagram path. These mechanisms can be used
with CONNECT-UDP, CONNECT-IP, or any other instantiation of the
Capsule Protocol.

"Extending ICMP for IP-related Information Validation", Liu Yao,

2022-06-06, <draft-liu-6man-icmp-verification-01.txt>

This document introduces the mechanism to verify the data plane

against the control plane in IPv6/SRv6 networks by extending ICMP
messages.

"Secure Vector Routing (SVR)", Abilash Menon, Patrick MeLampy, Michael Baj,
Patrick Timmons, Hadriel Kaplan, 2022-03-29, <draft-menon-svr-01.txt>

This document describes Secure Vector Routing (SVR). SVR is an

overlay inter-networking protocol that operates at the session layer.
SVR provides end-to-end communication of network requirements not
possible or practical using network header layers. SVR uses
application layer cookies that eliminate the need to create and
maintain non-overlapping address spaces necessary to manage network
routing requirements. SVR is an overlay networking protocol that
works through middleboxes and address translators including those
existing between private networks, the IPv4 public internet, and the
IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases
and improve security at the networking routing plane. SVR eliminates
the need for encapsulation and decapsulation often used to create
non-overlapping address spaces.

"Additional block types for PCAP Next Generation (pcapng) Capture File
Format", Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy
Harris, Eelco Chaudron, Michael Richardson, 2022-07-29,
<draft-richardson-opsawg-pcapng-extras-01.txt>

This document contains a number of extensions to the PCAPng file

format which are outside of the IETF networking mandate.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the OPSAWG Working Group

mailing list (opsawg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/opsawg/.

Source for this draft and an issue tracker can be found at

https://github.com/pcapng/pcapng.

"Procedures for Standards Track Documents to Refer Normatively to Documents

at a Lower Level", Murray Kucherawy, 2021-10-17,
<draft-kucherawy-bcp97bis-01.txt>

IETF procedures generally require that a standards track RFC may not
have a normative reference to another standards track document at a
lower maturity level or to a non standards track specification (other
than specifications from other standards bodies). For example, a
standards track document may not have a normative reference to an
 informational RFC. Exceptions to this rule are sometimes needed as
the IETF uses informational RFCs to describe non-IETF standards or
IETF-specific modes of use of such standards. This document defines
the procedure used in these circumstances.

This document merges and updates, and thus obsoletes, RFC 3967, RFC
4897, and RFC 8067.

"TURN Cluster: Scale out TURN cluster by routable transaction id", William
Zeng, 2022-05-09, <draft-zeng-turn-cluster-03.txt>

The TURN protocol is designed to solve the connectivity problem of

Peer-to-Peer Communication when NAT devices exist, by allowing each
peer to establish a data channel on TURN servers. Since there are
some specific requirements in the use of TURN, such as RTP/RTCP
connection pairs must be sent to the same TURN server, it is not easy
to scale a single TURN server into a TURN cluster. In addition, a
TURN service cluster also needs to consider how to achieve good load
balancing and how to protect internal information security. Based on
these demands, this specification provides several standard means to
implement a functional and secure TURN cluster, and this
specification also provides an overview and rationale of the cluster
architecture.

"YANG model for Data Export over IP Flow Information Export (IPFIX)
Protocol", Anand Arokiaraj, Marta Seda, 2022-08-29,
<draft-arokiarajseda-ipfix-data-export-yang-model-02.txt>

This document defines a YANG model for data export via the IP Flow
Information Export (IPFIX) protocol. The YANG model in this document
conforms to the Network Management Datastore Architecture (NMDA)
defined in RFC 8342.

"Brand Indicators for Message Identification (BIMI)", Seth Blank, Peter

Goldstein, Thede Loder, Terry Zink, Marc Bradshaw, Alex Brotman,
2022-04-10, <draft-brand-indicators-for-message-identification-01.txt>

Brand Indicators for Message Identification (BIMI) permits Domain

Owners to coordinate with Mail User Agents (MUAs) to display brand-
specific Indicators next to properly authenticated messages. There
are two aspects of BIMI coordination: a scalable mechanism for Domain
Owners to publish their desired Indicators, and a mechanism for Mail
Transfer Agents (MTAs) to verify the authenticity of the Indicator.
This document specifies how Domain Owners communicate their desired
Indicators through the BIMI Assertion Record in DNS and how that
record is to be interpreted by MTAs and MUAs. MUAs and mail-
receiving organizations are free to define their own policies for
making use of BIMI data and for Indicator display as they see fit.

"RADIUS attributes for Randomized and Changing MAC addresses", Jerome

Henry, Nancy Cam-Winget, 2022-04-11,
<draft-henry-radext-stable-mac-identifier-01.txt>

This document describes the means by which a Stable MAC address

identifier can be signaled to a Authentication Authorization and
Accounting (AAA) server.

"Self-Addressing IDentifier (SAID)", Samuel Smith, 2022-05-31,

<draft-ssmith-said-02.txt>
 A SAID (Self-Addressing IDentifier) is a special type of content-
addressable identifier based on encoded cryptographic digest that is
self-referential. The SAID derivation protocol defined herein
enables verification that a given SAID is uniquely cryptographically
bound to a serialization that includes the SAID as a field in that
serialization. Embedding a SAID as a field in the associated
serialization indicates a preferred content-addressable identifier
for that serialization that facilitates greater interoperability,
reduced ambiguity, and enhanced security when reasoning about the
serialization. Moreover, given sufficient cryptographic strength, a
cryptographic commitment such as a signature, digest, or another
SAID, to a given SAID is essentially equivalent to a commitment to
its associated serialization. Any change to the serialization
invalidates its SAID thereby ensuring secure immutability evident
reasoning with SAIDs about serializations or equivalently their
SAIDs. Thus SAIDs better facilitate immutably referenced data
serializations for applications such as Verifiable Credentials or
Ricardian Contracts.

SAIDs are encoded with CESR (Composable Event Streaming

Representation) [CESR] which includes a pre-pended derivation code
that encodes the cryptographic suite or algorithm used to generate
the digest. A CESR primitive's primary expression (alone or in
combination ) is textual using Base64 URL-safe characters. CESR
primitives may be round-tripped (alone or in combination) to a
compact binary representation without loss. The CESR derivation code
enables cryptographic digest algorithm agility in systems that use
SAIDs as content addresses. Each serialization may use a different
cryptographic digest algorithm as indicated by its derivation code.
This provides interoperable future proofing. CESR was developed for
the [KERI] protocol.

"Requirements for Large-Scale Deterministic Networks", Peng Liu, Yizhou Li,

Toerless Eckert, Quan Xiong, Jeong-dong Ryoo, zhushiyin, 2022-08-17,
<draft-liu-detnet-large-scale-requirements-03.txt>

Aiming at the large-scale deterministic network, this document

describes the technical and operational requirements when the
different deterministic levels of applications co-exist and are
transported over a wide area. This document also describes the
corresponding Deterministic Networking (DetNet) data plane
enhancement requirements.

"UDP-based Generic Multi-Access (GMA) Control Protocol", Jing Zhu, Menglei

Zhang, 2022-04-11, <draft-zhu-intarea-gma-control-01.txt>

A device can be simultaneously connected to multiple networks,

e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
combine the connectivity over these networks below the transport
layer (L4) to improve quality of experience for applications that
do not have built in multi-path capabilities. This document
presents a new control protocol to manage traffic steering,
splitting, and duplicating across multiple connections. The
solution has been developed by the authors based on their
experiences in multiple standards bodies including the IETF and
3GPP, is not an Internet Standard and does not represent the
consensus opinion of the IETF. This document will enable other
developers to build interoperable implementations in order to
 experiment with the protocol.

"VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4", Wei Wang,
Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong, 2022-04-13,
<draft-wang-idr-vpn-prefix-orf-03.txt>

This draft defines a new Outbound Route Filter (ORF) type, called the
VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable
when the VPN routes from different VRFs are exchanged via one shared
BGP session (e.g., routers in a single-domain connect via Route
Reflector).

"Illustrations for Compressed SRv6 Segment List Encoding in SRH", Francois

Clad, Darren Dukes, 2022-04-19,
<draft-clad-spring-srv6-srh-compression-illus-01.txt>

This document provides illustrations for compressed SRv6 Segment List

Encoding in the Segment Routing Header (SRH).

"Scalability of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse,

2022-06-30, <draft-lencse-v6ops-transition-scalability-03.txt>

Several IPv6 transition technologies have been developed to provide

customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines the scalability of the five most prominent

IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6,
MAP-E, MAP-T) considering two aspects: (1) how their performance
scales up with the number of CPU cores, (2) how their performance
degrades, when the number of concurrent sessions is increased until
hardware limit is reached.

"Performance Analysis of IPv6 Transition Technologies for IPv4aaS", Gabor

Lencse, 2022-05-02, <draft-lencse-v6ops-transition-benchmarking-01.txt>

Several IPv6 transition technologies have been developed to provide

customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines and compares the performance of some free

software implementations of the five most prominent IPv4aaS
technologies (464XLAT [RFC6877], Dual Stack Lite [RFC6333],
Lightweight 4over6 [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599])
and DNS64 [RFC6147].

"Extensions to the Access Control Lists (ACLs) YANG Model", Oscar de Dios,
Samier Barguil, Mohamed Boucadair, 2022-06-29, <draft-dbb-netmod-acl-01.txt>

RFC 8519 defines a YANG data model for Access Control Lists (ACLs).
This document discusses a set of extensions that fix many of the
limitations of the ACL model as initially defined in RFC 8519.
 Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Network Modeling

Working Group mailing list (netmod@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/netmod/.

Source for this draft and an issue tracker can be found at

https://github.com/oscargdd/draft-dbb-netmod-enhanced-acl.

"Native Short Addressing for Low power and Lossy Networks Expansion",
Guangpeng Li, Zhe Lou, Luigi Iannone, Peng Liu, Rong Long, 2022-06-01,
<draft-li-6lo-native-short-address-03.txt>

This document specifies a topological addressing scheme, Native Short

Address (NSA) that enables IP packet transmission over links where
the transmission of a full length address may not be desirable.
Furthermore, packet forwarding is stateless, meaning that no routing
table needs to be built, rather, the forwarding decision is based
solely on the destination address structure. This document focuses
on carrying IP packets across an LLN (Low power and Lossy Network),
in which the topology is static, where nodes' location is fixed, and
the connection between nodes is also rather stable. This
specifications details the NSA architecture, address allocation,
forwarding mechanism, header format design, including length-variable
fields, and IPv6 interconnection support.

"A registry/registrar blockchain architecture for domain name registration

data access protocol", Yu Zeng, Man Zhang, Wei Wang, 2022-06-26,
<draft-zeng-dinrg-blockchain-based-rdap-01.txt>

This document defines a registry/registrar blockchain architecture

for domain name registration data access protocol.

"The Need for New Authentication Methods for Internet of Things", Dirk
Hugo, Behcet Sarikaya, 2022-07-11, <draft-hsothers-iotsens-ps-02.txt>

The document attempts to establish the need for new authentication

methods in the Internet of Things (IoT) as a future networking area
beyond 5G going into 6G for standardization. Several scenarios are
described where the current authentication protocols do not work or
are insufficient. Wireless LAN/6G sensing is established as an
admission method that can be used within the framework of Device
Provisioning Protocol and LED light and others as out-of band channel
based authentication which can be further explored.

"Advertising S-BFD Discriminators in BGP", Haibo Wang, Jie Dong, Greg

Mirsky, Yang Huang, 2022-04-16, <draft-wang-bess-sbfd-discriminator-02.txt>

Seamless Bidirectional Forwarding Detection (S-BFD) is a simplified

BFD mechanism. It eliminates most negotiation aspects and provides
advantages such as fast configuration injection. S-BFD is especially
useful in multi-homing PE scenarios and reduces resource overheads on
the dual-homing PEs. Although S-BFD is simpler than BFD, a large
number of manual configurations are required when there are a large
number of PEs.

This document provides the mechanism of distributing S-BFD

 discriminators with VPN service routes, which simplifies S-BFD
deployment for VPN services.

"Updated Rules for PCEP Object Ordering", Dhruv Dhody, 2022-07-09,

<draft-dhody-pce-pcep-object-order-02.txt>

The Path Computation Element (PCE) Communication Protocol (PCEP)

defines the mechanisms for the communication between a Path
Computation Client (PCC) and a PCE, or among PCEs. Such interactions
include path computation requests and path computation replies
defined in RFC 5440. As per RFC 5440, these message are required to
follow strict object ordering.

This document updates RFC 5440 by relaxing the strict object ordering
requirement in the PCEP messages.

"Use of Streams in BGP over QUIC", Alvaro Retana, Yingzhen Qu, Jeff
Tantsura, 2022-05-11, <draft-retana-idr-bgp-quic-stream-02.txt>

This document specifies the use of QUIC Streams to support multiple

BGP sessions over one connection in order to achieve high resiliency.

"Satellite Semantic Addressing for Satellite Constellation", Lin Han,

Richard Li, Alvaro Retana, chenmeiling, Ning Wang, 2022-09-04,
<draft-lhan-satellite-semantic-addressing-02.txt>

This document presents a semantic addressing method for satellites in

satellite constellation connecting with Internet. The satellite
semantic address can indicate the relative position of satellites in
a constellation. The address can be used with traditional IP address
or MAC address or used independently for IP routing and switching.

"Unicast Use of the Formerly Reserved 240/4", Seth Schoen, John Gilmore,
David Taht, 2022-07-06, <draft-schoen-intarea-unicast-240-03.txt>

This document redesignates 240/4, the region of the IPv4 address

space historically known as "Experimental," "Future Use," or "Class
E" address space, so that this space is no longer reserved. It asks
implementers to make addresses in this range fully usable for unicast
use on the Internet.

"Artificial Intelligence Framework for Network Management", Pedro

Martinez-Julia, Shunsuke Homma, Diego Lopez, 2022-07-06,
<draft-pedro-nmrg-ai-framework-01.txt>

The adoption of artificial intelligence (AI) in network management

(NM) solutions is becoming a reality. It is mainly supported by the
need to resolve complex problems arisen from the acceptance of SDN/
NFV technologies as well as network slicing. Thus, the AINEMA
framework, as discussed in this document, is required to keep focus
and organize the efforts on applying AI to NM. This is enlarged by
the inclusion of external events in NM operations as well as the
consideration of a full intelligence process instead of simple AI-
based guesses. Such process will be highly based in reasoning and
formal and target-based intelligence analysis and decision. This
will allow computer and network system infrastructures to grow in
complexity. The same applies to user demands. The construction and
maintenance of AINEMA requires a comprehensive inclusion of several
mechanisms. For instance, although there has been a lot of effort to
 make Machine Learning (ML) solutions reliable and acceptable, other
mechanisms have been forgotten. It is the particular case of
reasoning, which is the key within AINEMA. It will provide enormous
benefits to NM solutions by, for example, inferring new knowledge and
applying different kind of rules (e.g. logical) to choose from
several actions. While ML solutions work with data, so their only
requirement from the network infrastructure is data retrieval, AINEMA
will work in collaboration to the network it is managing. This makes
the challenges arisen from intelligent reasoning essential for the
evolution of NM. They will be addressed within the context of
AINEMA.

"Innovation in Internet Routing and Addressing", Luigi Iannone, 2022-04-20,

<draft-iannone-routing-and-addressing-manifesto-01.txt>

This document arguments that despite the ongoing research in routing

and addressing and the Internet innovation, researchers and engineers
lack a dedicated forum where they can interact.

"Unicast Use of the Lowest Address in an IPv4 Subnet", Seth Schoen, John
Gilmore, David Taht, Michael Karels, 2022-05-16,
<draft-schoen-intarea-unicast-lowest-address-02.txt>

With ever-increasing pressure to conserve IP address space on the

Internet, it makes sense to consider where relatively minor changes
can be made to fielded practice to improve numbering efficiency. One
such change, proposed by this document, is to increase the number of
unicast addresses in each existing subnet, by redefining the use of
the lowest-numbered (zeroth) host address in each IPv4 subnet as an
ordinary unicast host identifier, instead of as a duplicate segment-
directed broadcast address.

"Secure Credential Transfer", Dmitry Vinokurov, Matt Byington, Matthias

Lerch, Alex Pelletier, Nick Sha, 2022-07-08,
<draft-secure-credential-transfer-04.txt>

This document describes a mechanism to transfer digital credentials

securely between two devices. Secure credentials may represent a
digital key to a hotel room, a digital key to a door lock in a house
or a digital key to a car. Devices that share credentials may belong
to the same or two different platforms (e.g. iOS and Android).
Secure transfer may include one or more write and read operations.
Credential transfer needs to be performed securely due to the
sensitive nature of the information.

"YANG Data Models for requesting Path Computation in Optical Networks",

Italo Busi, Aihua Guo, Sergio Belotti, 2022-03-07,
<draft-gbb-ccamp-optical-path-computation-yang-01.txt>

This document describes YANG data models for Remote Procedure Calls
(RPCs) to request Path Computation in Optical Networks (OTN, WSON and
Flexi-grid).

The YANG data models defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"Constrained Application Protocol (CoAP) Performance Measurement Option",

Giuseppe Fioccola, Tianran Zhou, Mauro Cociglio, Fabio Bulgarella, Massimo
Nilo, 2022-05-25, <draft-fz-core-coap-pm-02.txt>
 This document specifies a method for the Performance Measurement of
the Constrained Application Protocol (CoAP). A new CoAP option is
defined in order to enable network telemetry both end-to-end and on-
path.

"SCIM Roles and Entitlements Extension", Danny Zollner, 2022-07-27,

<draft-zollner-scim-roles-entitlements-extension-02.txt>

The System for Cross-domain Identity Management (SCIM) protocol's

schema RFC RFC7643 (https://datatracker.ietf.org/doc/html/rfc7643)
defines the complex core schema attributes "roles" and
"entitlements". For both of these concepts, frequently only a
predetermined set of values are accepted by a SCIM service provider.
The values that are accepted may vary per customer or tenant based on
customizable configuration in the service provider's application or
based on other criteria such as what services have been purchased.
This document defines an extension to the SCIM 2.0 standard to allow
SCIM service providers to represent available data pertaining to
roles and entitlements so that SCIM clients can consume this
information and provide easier management of role and entitlement
assignments.

"BGP-SPF Flooding Reduction", Huaimo Chen, Gyan Mishra, Aijun Wang, Yisong
Liu, Haibo Wang, Yanhe Fan, 2022-05-15,
<draft-chen-lsvr-flood-reduction-02.txt>

This document describes extensions to Border Gateway Protocol (BGP)

for flooding the link states on a topology that is a subgraph of the
complete topology of a BGP-SPF domain, so that the amount of flooding
traffic in the domain is greatly reduced. This would reduce
convergence time with a more stable and optimized routing
environment.

"Multicast DNS conflict resolution using the Time Since Received (TSR) RR",
Ted Lemon, Liang Qin, 2022-07-11, <draft-tllq-tsr-02.txt>

This document specifies a new conflict resolution mechanism for DNS,

for use in cases where the advertisement is being proxied, rather
than advertised directly, e.g. when using a combined DNS-SD
Advertising Proxy and SRP registrar. A new DNS RR is defined that
communicates the time at which the set of resource records on a
particular DNS owner name was most recently updated.

"BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution

Approaches", Fanghong Duan, Jingrong Xie, 2022-07-11,
<draft-duan-bess-mvpn-ipv6-infras-02.txt>

MVPN deployment faces some problems while used in provider's IPv6

infrastructure networks. This document describes these problems, and
the solutions to solve these problems.

"Multicast VPN Upstream Designated Forwarder Selection", Heng Wang,

Fanghong Duan, 2022-07-09,
<draft-wang-bess-mvpn-upstream-df-selection-01.txt>

This document defines Multicast Virtual Private Network (VPN)

extensions and procedures that allow fast failover for upstream
failures by allowing upstream Provider Edges (PEs) to determine a
 single forwarder for a VPN multicast flow, without the downstream
PEs' duplication prevention. The fast failover is accomplished by
using Virtual Router Redundancy Protocol (VRRP) [RFC5798] or similar
technologies for the upstream PEs to determine a single desinated
fowarder. Also, this document introduces a new BGP Extended
Community called "Upstream Forwarder Selection", carried by BGP VPN
route so that the upstream PEs can inform downstream PEs the election
behavior. The downstream PEs, accordingly, send C-multicast routes
to both the primary and standby upstream PEs and forward the
multicast flow comming from both sides to the CEs.

"Support for Virtual Transport Network (VTN) in the Path Computation

Element Communication Protocol (PCEP)", Jie Dong, Sheng Fang, Liuyan Han,
Minxue Wang, 2022-07-11, <draft-dong-pce-pcep-vtn-01.txt>

With the introduction and evolvement of 5G and other network

scenarios, some existing or new customers may require connectivity
services with advanced characteristics comparing to traditional
Virtual Private Networks (VPNs). Such kind of network service is
called enhanced VPNs (VPN+). The typical application of VPN+ is to
provide network slice services.

A Virtual Transport Network (VTN) is a virtual underlay network which

consists of a set of dedicated or shared network resources allocated
from the physical underlay network, and is associated with a
customized logical network topology. VPN+ services can be delivered
by mapping one or a group of overlay VPNs to the appropriate VTNs as
the virtual underlay. Then traffic flows of the VPN+ service can be
steered onto the TE paths within the VTN.

The Path Computation Element (PCE) provides path computation

functions in support of traffic engineering in Multi-protocol Label
Switching (MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR)
networks.

This document specifies the extensions to PCE communication Protocol

(PCEP) to carry VTN information in the PCEP messages. The extensions
in this document can be used in the basic PCE computation, the
stateful PCE and the PCE-initiated LSP mechanisms to indicate path
computation, path status report and path initialization within a
specific VTN.

"Traffic Mapping YANG model for Traffic Engineering (TE)", Dhruv Dhody,
2022-07-11, <draft-dhody-teas-te-traffic-yang-02.txt>

This document provides a YANG data model to map traffic to Traffic

Engineering (TE) paths. This model providers operator a seamless
control and management of which traffic to send on the underlying TE
resources.

"IETF Network Slice Deployment Status and Considerations", Yusong Ma, Rui
Luo, Alex Chan, Ben Suen, Jie Dong, Yang Liu, Houcine Allahoum, 2022-07-11,
<draft-ma-teas-ietf-network-slice-deployment-01.txt>

Network Slicing is considered as an important approach to provide

different services and customers with the required network
connectivity, network resources and performance characteristics over
a shared network. Operators have started the deployment of network
slices in their networks for different purposes. This document
 introduces several deployment cases of IETF network slices in
operator networks. Some considerations collected from these IETF
network slice deployments are also provided.

"Application-aware Networking (APN) Header", Zhenbin Li, Shuping Peng,

Shuai Zhang, 2022-04-07, <draft-li-apn-header-02.txt>

This document defines the application-aware networking (APN) header

which can be used in a variety of data planes.

"ICMPv6 Echo Request/Reply for Enabled In-situ OAM Capabilities", Xiao Min,
Greg Mirsky, 2022-04-25, <draft-xiao-6man-icmpv6-ioam-conf-state-01.txt>

This document describes the ICMPv6 IOAM Echo functionality, which

uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM
encapsulating node to discover the enabled IOAM capabilities of each
IOAM transit and decapsulating node.

This document updates RFC 4884.

"Application-aware IPv6 Networking (APN6) Encapsulation", Zhenbin Li,

Shuping Peng, Chongfeng Xie, 2022-05-31, <draft-li-apn-ipv6-encap-05.txt>

Application-aware IPv6 Networking (APN6) makes use of IPv6

encapsulation to convey the APN Attribute along with data packets and
make the network aware of data flow requirements at different
granularity levels. The APN attribute can be encapsulated in the APN
header. This document defines the encapsulation of the APN header in
the IPv6 data plane.

"Comparing One-way Delays in Multipath", Jiao Kang, liangqiandeng,

Shangling Deng, Peng Liu, 2022-06-16,
<draft-kang-quic-oneway-delays-in-multipath-01.txt>

This document provides a solution for comparing one-way delays in

multipath quic. In this solution, through message interaction
between data receiver and data sender, the data sender can obtain
delay rankings of multiple specified uniflows, providing reference
for sending data packets.

"Signal Degrade Indication in BFD", Liuyan Han, Minxue Wang, Fan Yang,
2022-07-07, <draft-hwy-bfd-sdi-01.txt>

To satisfy the requirements of signal degrade indication described in

[I-D.yang-mpls-ps-sdi-sr], this document illustrates the extension of
BFD protocol to support signal degrade indication.

"Routing Header Based BIER Information Encapsulation", Wei Wang, Aijun

Wang, Huaimo Chen, Gyan Mishra, Bing Xu, 2022-03-20,
<draft-wang-bier-rh-bier-05.txt>

This draft proposes one new encapsulation schema of Bit Index

Explicit Replication (BIER) information to transfer the multicast
packets within the IPv6 network. By using a new type of IPv6 Routing
Header to forward the packet, the original source address and
destination address of the multicast packet is kept unchanged along
the forwarding path. Such encapsulation schema can make full use of
the existing IPv6 quality assurance solutions to provide high-quality
multicast service.
"Native Minimal Protocols with Flexibility at Edge Networks", Zhe Chen,
Sheng Jiang, 2022-04-14, <draft-jiang-intarea-nmp-edge-01.txt>

This document introduces a flexible native minimal protocol for fast

short packet transmission in edge networks, and can communicate with
IPv6 nodes through gateways.

"A YANG Model for Application-aware Networking (APN)", Shuping Peng,

Zhenbin Li, 2022-04-28, <draft-peng-apn-yang-01.txt>

Application-aware Networking (APN) is a framework, where APN data

packets convey APN attribute (incl. APN ID and/or APN Parameters) to
enable fine grained service provisioning. This document defines a
YANG module for APN.

The YANG modules in this document conform to the Network Management

Datastore Architecture (NMDA).

"Considerations about Hierarchical IETF Network Slices", Jie Dong, Zhenbin

Li, 2022-03-06, <draft-dong-teas-hierarchical-ietf-network-slice-01.txt>

Network slicing is targeted at existing or emerging customers or

services which may request for network connectivity services with a
specific set of Service Level Objectives (SLOs) and Service Level
Expectations (SLEs). In some network scenarios, there can be
requirements for the deployment of hierarchical network slices.The
general framework of IETF network slice supports hierarchical network
slicing, while the technologies for realizing hierarchical IETF
network slice need to be considered.

This document describes the typical scenarios of hierarchical IETF

network slices, and provides the considerations and requirements on
the technologies in different network planes to realize hierarchical
IETF network slices.

"System-defined Configuration", Qiufang Ma, Kent Watsen, Qin WU, Chong

Feng, Jan Lindblad, 2022-08-09, <draft-ma-netmod-with-system-04.txt>

This document updates NMDA to define a read-only conventional

configuration datastore called "system" to hold system-defined
configurations. To avoid clients' explicit copy/paste of referenced
system-defined configuration into the target configuration datastore
(e.g., <running>), a "resolve-system" parameter has been defined to
allow the server acting as a "system client" to copy referenced
system-defined nodes automatically. The solution enables clients
manipulating the target configuration datastore (e.g., <running>) to
overlay and reference nodes defined in <system>, override values of
configurations defined in <system>, and configure descendant nodes of
system-defined nodes.

"RGB (Replication through Global Bitstring) Segment for Multicast Source

Routing over IPv6", Yisong Liu, Jingrong Xie, Xuesong Geng, Mengxiao Chen,
2022-07-10, <draft-lx-msr6-rgb-segment-03.txt>

This document introduces the RGB (Replication through Global

Bitstring) Segment for Multicast Source Routing over IPv6.

"Source Segment for Multicast Source Routing over IPv6", Jingrong Xie,
Xuesong Geng, Yisong Liu, Mengxiao Chen, 2022-07-10,
<draft-xl-msr6-source-segment-02.txt>

This document defines the general concept of source segment which is

used as the IPv6 source address in an IPv6 packet. Source segment
for multicast service is introduced in this document.

"IPv6 Multicast Source Routing Traffic Engineering", Xuesong Geng, Zhenbin

Li, Jingrong Xie, 2022-03-07, <draft-geng-msr6-traffic-engineering-01.txt>

This document defines 2 new types of segment: End.RL and End.RL.X ,

and the corresponding packet processing procedures over the IPv6 data
plane for the MSR6(Multicast Source Routing over IPv6) TE solutions.

"Flow Measurement in IPv6 Network", Haojie Wang, Yisong Liu, Changwang Lin,
Xiao Min, 2022-08-30, <draft-wang-ippm-ipv6-flow-measurement-02.txt>

In-situ Operations, Administration, and Maintenance (OAM) need

carrying the necessary measurement information into a packet while
the packet transverses a path between two points in the network.
This document describes how to deploy in-situ flow performance
measurement based on Alternate-Marking method in IPv6 domain.

"A Data Manifest for Contextualized Telemetry Data", Benoit Claise, Jean
Quilbeuf, Diego Lopez, Ignacio Martinez-Casanueva, Thomas Graf, 2022-07-25,
<draft-claise-opsawg-collected-data-manifest-04.txt>

Most network equipment feature telemetry as a mean to monitoring

their status. Several protocols exist to this end, for example, the
model-driven telemetry governed by YANG models. Some of these
protocols provide the data itself, without any contextual information
about the collection method. This can render the data unusable if
that context is lost, for instance when the data is stored without
the relevant information. This document proposes a data manifest,
composed of two YANG data models, to store that contextual
information along with the collected data, in order to keep the
collected data exploitable in the future.

"Media Over QUIC - Use Cases and Requirements for Media Transport Protocol
Design", James Gruessing, Spencer Dawkins, 2022-07-11,
<draft-gruessing-moq-requirements-02.txt>

This document describes use cases that have been discussed in the
IETF community under the banner of "Media Over QUIC", provides
analysis about those use cases, recommends a subset of use cases that
cover live media ingest, syndication, and streaming for further
exploration, and describes requirements that should guide the design
of protocols to satisfy these use cases.

"Dissemination of BGP Flow Specification Rules for APN", Shuping Peng,

Zhenbin Li, Sheng Fang, Yong Cui, 2022-04-28,
<draft-peng-apn-bgp-flowspec-01.txt>

A BGP Flow Specification is an n-tuple consisting of several matching

criteria that can be applied to IP traffic. Application-aware
Networking (APN) is a framework, where APN data packets convey APN
attribute including APN ID and/or APN Parameters. The dynamic Flow
Spec mechanism for APN is designed for the new applications of
traffic filtering in an APN domain as well as the traffic control and
 actions at the policy enforcement points in this domain. These
applications require coordination among the ASes within a service
provider.

This document specifies a new BGP Flow Spec Component Type in order
to support APN traffic filtering. The match field is the APN ID. It
also specifies traffic filtering actions to enable the creation of
the APN ID in the outer tunnel encapsulation when matched to the
corresponding Flow Spec rules.

"Extension of Link Bandwidth Extended Community", Wenyan Li, Haibo Wang,

Jie Dong, 2022-03-07, <draft-li-idr-link-bandwidth-ext-01.txt>

[I-D.ietf-idr-link-bandwidth] defines a BGP link bandwidth extended

community attribute, which can enable devices to implement unequal-
cost load-balancing. However, the bandwidth value encapsulated by
the extended community attribute is of the floating-point type, which
is inconvenient to use. In this document, a set of new types of link
bandwidth extended community are introduced to facilitate the
configuration and calculation of link bandwidth.

"Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks", Jorge
Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin,
2022-03-07, <draft-sr-bess-evpn-dpath-01.txt>

The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet

Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes.
When used along with EVPN IP Prefix routes or IP-VPN routes, it
identifies the domain(s) through which the routes have passed and
that information can be used by the receiver BGP speakers to detect
routing loops or influence the BGP best path selection. This
document extends the use of D-PATH so that it can also be used along
with other EVPN route types.

"Salted Challenge Response Authentication Mechanism (SCRAM) SASL and

GSS-API Mechanisms", Alexey Melnikov, 2022-07-11,
<draft-melnikov-scram-bis-01.txt>

This document updates requirements on implementations of various

Salted Challenge Response Authentication Mechanism (SCRAM) Simple
Authentication and Security Layer (SASL) mechanisms based on more
modern security practices.

"Problems and Requirements of Addressing in Integrated Space-Terrestrial

Network", Yuanjie Li, Hewu Li, Jiayi Liu, Lixin Liu, Qian Wu, 2022-04-27,
<draft-li-istn-addressing-requirement-01.txt>

This document presents a detailed analysis of the problems and

requirements of network addressing in "Internet in space" for
terrestrial users. It introduces the basics of satellite mega-
constellations, terrestrial terminals/ground stations, and their
inter-networking. Then it explicitly analyzes how space-terrestrial
mobility yeilds challenges for the logical topology, addressing, and
their impact on routing. The requirements of addressing in the
space-terrestrial network are discussed in detail, including
uniqueness, stability, locality, scalability, efficiency and backward
compatibility with terrestrial Internet. The problems and
requirements of network addressing in space-terrestrial networks are
finally outlined.
"Problems and Requirements of Evaluation Methodology for Integrated Space
and Terrestrial Networks", Zeqi Lai, Hewu Li, Yangtao Deng, Qian Wu, Jun
Liu, 2022-04-27, <draft-lai-bmwg-istn-methodology-01.txt>

With the rapid evolution of the aerospace industry, many "NewSpace"

upstarts are actively deploying their mega-constellations in low
earth orbits (LEO) and building integrated space and terrestrial
networks (ISTN), promising to provide pervasive, low-latency, and
high-throughput Internet service globally. Due to the high
manufacturing, launching, and updating cost of LEO mega-
constellations, it is expected that ISTNs can be well designed and
evaluated before the launch of satellites. However, the progress of
designing, assessing, and understanding new network functionalities
and protocols for futuristic ISTNs faces a substantial obstacle: lack
of standardized evaluation methodology with acceptable realism (e.g.
can involve the unique dynamic behaviors of ISTNs), flexibility, and
cost. This memo first reviews the unique characteristics of LEO
mega-constellations. Further, it analyzes the limitation of existing
evaluation and analysis methodologies under ISTN environments.
Finally, it outlines the key requirements of future evaluation
methodology tailored for ISTNs.

"Preferred Path Routing Framework", Stewart Bryant, Uma Chunduri, Alexander

Clemm, 2022-05-09, <draft-chunduri-rtgwg-preferred-path-routing-02.txt>

Capacity demands, Traffic Engineering (TE) and determinism are some

of key requirements for various cellular, edge and industrial
deployments. These deployments span from many underlying data pane
technologies including native IPv4, native IPv6 along with MPLS and
Segment Routing (SR).

This document provides a framework for Preferred Path Routing (PPR).

PPR is a method of providing path based dynamic routing for a number
of packet types including IPv4, IPv6 and MPLS. This seamlessly works
with a controller plane which holds both complete network view of
operator policies, while distributed control plane providing self-
healing benefits in a near-real time fashion.

PPR builds on existing encapsulations at the edge nodes to add path

identity to the packet. This reduces the per packet overhead
required for path steering and therefore has a smaller impact on both
packet MTU, data plane processing and overall goodput for small
payload packets, while extending path steering benefits to any
existing data plane.
A number of extensions that allow expansion of use beyond simple
point-to-point-paths are also described in this memo.

"Problems and Requirements of Source Address Spoofing in Integrated Space

and Terrestrial Networks", Jun Liu, Hewu Li, Tianyu Zhang, Qian Wu,
2022-04-27, <draft-jliu-istn-savi-requirement-01.txt>

This document presents the detailed analysis about the problems and
requirements of dealing with the threat of source address spoofing in
Integrated Space and Terrestrial Networks (ISTN). First,
characteristics of ISTN that cause DDos are identified. Secondly, it
analyzes the major reasons why existing terrestrial source address
validation mechanism does not fit well for ISTN. Then, it outlines
the major requirements for improvement on source address validation
 mechanism for ISTN.

"Path Computation Element Protocol(PCEP) Extension for Color", Balaji

Rajagopalan, Vishnu Beeram, Shaofu Peng, Quan Xiong, Mike Koldychev, Gyan
Mishra, 2022-07-06, <draft-rajagopalan-pce-pcep-color-02.txt>

Color is a 32-bit numerical attribute that is used to associate a

Traffic Engineering (TE) tunnel or policy with an intent or objective
(e.g. low latency). This document specifies an extension to Path
Computation Element Protocol (PCEP) to carry the color attribute.

"Segment Routing IPv6 Mobile User Plane Architecture for Distributed

Mobility Management", Satoru Matsushima, Katsuhiro Horiba, Ashiq Khan, Yuya
Kawakami, Tetsuya Murakami, Keyur Patel, Miya Kohno, Teppei Kamata, Pablo
Camarillo, Dan Voyer, Shay Zadok, Israel Meilik, Ashutosh Agrawal, Kumaresh
Perumal, Jakub Horn, 2022-03-20,
<draft-mhkk-dmm-srv6mup-architecture-03.txt>

This document defines the Segment Routing IPv6 Mobile User Plane
(SRv6 MUP) architecture for Distributed Mobility Management. The
requirements for Distributed Mobility Management described in
[RFC7333] can be satisfied by routing fashion.

Mobile services are deployed over several parts of IP networks. A

Segment Routing over IPv6 (SRv6) network can accommodate all, or part
of those networks thanks to the large address space of IPv6 and the
network programming capability described in [RFC8986].

Segment Routing IPv6 Mobile User Plane Architecture can incorporate

existing session based mobile networks. By leveraging SRv6 network
programmability, mobile user plane can be integrated into the SRv6
data plane. In that routing paradigm, session information between
the entities of the mobile user plane is turned to routing
information.

"EVPN Fast Reroute", Luc Burdet, Patrice Brissette, Takuya Miyasaka, Jorge
Rabadan, 2022-03-07, <draft-burdet-bess-evpn-fast-reroute-02.txt>

This document summarises EVPN convergence mechanisms and specifies

procedures for EVPN networks to achieve sub-second and
scale-independant convergence.

"TCPLS: Modern Transport Services with TCP and TLS", Maxime Piraux,
Florentin Rochet, Olivier Bonaventure, 2022-07-11,
<draft-piraux-tcpls-02.txt>

This document specifies a protocol leveraging TCP and TLS to provide

modern transport services such as multiplexing, connection migration
and multipath in a secure manner.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/mpiraux/draft-piraux-tcpls.

"Considering ALTO as IETF Network Exposure Function", Luis Contreras,

2022-07-11, <draft-contreras-alto-ietf-nef-01.txt>
 This document proposes ALTO as the means for exposure of underlay
network capabilities for multiple overlays on top of the network.

"IPv6 Fragment Retransmission and Path MTU Discovery Soft Errors", Fred
Templin, 2022-03-29, <draft-templin-6man-fragrep-07.txt>

Internet Protocol version 6 (IPv6) provides a fragmentation and

reassembly service for end systems allowing for the transmission of
packets that exceed the path MTU. However, loss of individual
fragments requires retransmission of original packets in their
entirety leading to cascading reassembly failures. This document
specifies an IPv6 fragment retransmission scheme that matches the
loss unit to the retransmission unit. The document further specifies
an update to Path MTU Discovery that distinguishes hard link size
restrictions from reassembly congestion events.

"PIM Light", Hooman Bidgoli, Stig Venaas, Mankamana Mishra, Zhaohui Zhang,
Mike McBride, 2022-08-30, <draft-hb-pim-light-03.txt>

This document specifies a new Protocol Independent Multicast

interface which does not need PIM Hello to accept PIM Join/Prunes or
PIM Asserts.

"IANA Registry for the First Nibble Following a Label Stack", Kireeti
Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson,
2022-07-10, <draft-kbbma-mpls-1stnibble-02.txt>

The goal of this memo is to create a new IANA registry (called the
MPLS First Nibble registry) for the first nibble (4-bit field)
immediately following an MPLS label stack. The memo offers a
rationale for such a registry, describes how the registry should be
managed, and provides some initial entries. Furthermore, this memo
sets out some documentation requirements for registering new values.
Finally, it provides some recommendations that makes processing MPLS
packets easier and more robust.

There is an important caveat on the use of this registry versus the

IP version number registry.

This memo, if published, would update [RFC4928] and [RFC8469].

"The Pseudorandom Extension for cTLS", Benjamin Schwartz, Christopher

Patton, 2022-04-10, <draft-cpbs-pseudorandom-ctls-01.txt>

This draft describes a cTLS extension that allows each party to emit
a purely pseudorandom bitstream.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/bemasc/pseudorandom-ctls.

"Data minimization", Jari Arkko, 2022-07-11,

<draft-arkko-iab-data-minimization-principle-02.txt>

Communications security has been at the center of many security

 improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers.
This document recommends that this is no longer alone sufficient to
cater for the security and privacy issues seen on the Internet today.
For instance, it is often also necessary to protect against endpoints
that are compromised, malicious, or whose interests simply do not
align with the interests of users. While such protection is
difficult, there are some measures that can be taken. It is
important to consider the role of data passed to various parties -
including the primary protocol participants - and balance the
information given to them considering their roles and possible
compromise of the information.

"BGP SR Policy Extensions for template", KaZhang, Zhibo Hu, Jie Dong,
2022-04-27, <draft-zhang-idr-sr-policy-template-01.txt>

Segment Routing(SR) Policies can be advertised using BGP. An SR

Policy may has lots of constraints, and as the application and
features evolve, the SR Policy may need have more and more attribute
constraints. To avoid modifying BGP when constraints are added to an
SR Policy, we can define a template. The identifier and content of
the template are defined by the receiver of the SR Policy. The
advertiser of an SR policy only needs to know the ID of the template.
When advertising SR policy, the advertiser carries the template ID in
the tunnel encapsulation information of the SR policy. After
receiving the SR Policy information, the receiver obtains the
corresponding template and content according to the template ID,
thereby obtaining abundant constraint configuration information.

"PCEP Extension for NRP-ID", Quan Xiong, Shaofu Peng, Vishnu Beeram, Tarek
Saad, 2022-07-06, <draft-xiong-pce-nrp-id-01.txt>

This document proposes a set of extensions for PCEP to support the

identifier of Network Resource Partition (NRP-ID) as the constraint
of network slicing during path computation.

"Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage

Network Using BGP", Changwang Lin, Mengxiao Chen, Hao Li, Ruixue Wang,
Fengwei Qin, Qi Zhang, 2022-05-10, <draft-lin-idr-bgp-nof-nlri-01.txt>

This document proposes a method of distributing device discovery

information in NVMe over RoCEv2 storage network using the BGP
routing protocol. A new BGP Network Layer Reachability Information
(NLRI) encoding format, named NoF NLRI, is defined.

"Unicast Use of the Formerly Reserved 0/8", Seth Schoen, John Gilmore,
David Taht, 2022-07-06, <draft-schoen-intarea-unicast-0-02.txt>

This document redesignates 0/8, the lowest block in the IPv4 address
space, so that this space is no longer reserved. It asks
implementers to make addresses in this range fully usable for unicast
use on the Internet.

"Unicast Use of the Formerly Special-Cased 127/8", Seth Schoen, John

Gilmore, David Taht, 2022-08-29, <draft-schoen-intarea-unicast-127-02.txt>

This document redefines the IPv4 local loopback network as consisting

only of the 65,536 addresses 127.0.0.0 to 127.0.255.255
(127.0.0.0/16). It asks implementers to make addresses in the prior
 loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast
use on the Internet.

"Arm's Platform Security Architecture (PSA) Attestation Verifier

Endorsements", Thomas Fossati, Yogesh Deshpande, Henk Birkholz, 2022-05-11,
<draft-fdb-rats-psa-endorsements-01.txt>

PSA Endorsements include reference values, cryptographic key material

and certification status information that a Verifier needs in order
to appraise attestation Evidence produced by a PSA device. This memo
defines such PSA Endorsements as a profile of the CoRIM data model.

"An Introduction to Semantic Routing", Adrian Farrel, Daniel King,

2022-04-25, <draft-farrel-irtf-introduction-to-semantic-routing-04.txt>

Many proposals have been made to add semantics to IP packets by

placing additional information in existing fields, by adding
semantics to IP addresses themselves, or by adding fields. The
intent is to facilitate enhanced routing/forwarding decisions based
on these additional semantics to provide differentiated forwarding
paths for different packet flows distinct from simple shortest path
first routing. The process is defined as Semantic Routing.

This document provides a brief introduction to Semantic Routing.

"Quantum Safe Cryptography Key Information", Christine van Vredendaal,

Silvio Dragone, Basil Hess, Tamas Visgrady, Michael Osborne, Dieter Bong,
Joppe Bos, 2022-05-12, <draft-uni-qsckeys-01.txt>

This proposal defines key management approaches for Quantum Safe

Cryptographic (QSC) algorithms currently under evaluation in the NIST
Post Quantum Cryptography (PQC) process. This includes key
identification, key serialization, and key compression. The purpose
is to provide guidance such that the adoption of quantum-safe
algorithms is not hampered with the fragmented evolution of necessary
key management standards. Early definition of key material standards
will help expedite the adoption of new quantum safe algorithms at the
same time as improving interoperability between implementations and
minimizing divergence across standards.

"NAT64/DNS64 detection via SRV Records", Martin Hunek, 2022-06-12,

<draft-hunek-v6ops-nat64-srv-03.txt>

This document specifies how to discover the NAT64 pools in use and
DNS servers providing DNS64 service to the local clients. The
discovery made via SRV records allows the assignment of priorities to
the NAT64 pools and DNS64 servers. It also allows clients to have
different DNS providers than NAT64 providers while providing a secure
way via DNSSEC validation of provided SRV records. This way, it
provides DNS64 service regardless of DNS operator and DNS transport
protocol.

"Multi-cluster Edge System Architecture and Network Function Requirements",

Dae Kim, Joo-Sang Youn, 2022-07-25, <draft-dwon-t2trg-multiedge-arch-02.txt>

Artificial intelligence based IoT applications demand more massive

computing resource through networks for the process of AI tasks. To
support these applications, some new technologies based an edge
computing and fog computing are emerging. Especially, the
 computation-intensive and latency-sensitive IoT applications such as
augmented reality, virtual reality and AI based inference application
is deployed with an edge computing and fog computing which are
connected with cloud computing. Recently, cluster-based edge system
is deployed to extend computation capacity of an edge server. The
cluster-based edge system has the advantage that can enhace the
resource scalability and availability in edge computing and fog
computing. In this draft, we present cluster-based edge system
architecture and multi-cluster edge network topology that consists of
multi-cluster edge system and core cloud. Also, we define the
network functions and network node to configurate and operate multi-
cluster edge network collaboratively.

"Control Plane of Inter-Domain Source Address Validation Architecture", Ke

Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2022-05-21,
<draft-xu-savax-control-02.txt>

Because the Internet forwards packets according to the IP destination

address, packet forwarding typically takes place without inspection
of the source address and malicious attacks have been launched using
spoofed source addresses. The inter-domain source address validation
architecture is an effort to enhance the Internet by using state
machine to generate consistent tags. When communicating between two
end hosts at different ADs of IPv6 network, tags will be added to the
packets to identify the authenticity of the IPv6 source address.

This memo focus on the control plane of the SAVA-X mechanism.

"Data Plane of Inter-Domain Source Address Validation Architecture", Ke Xu,

Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2022-05-21,
<draft-xu-savax-data-02.txt>

Because the Internet forwards packets according to the IP destination

address, packet forwarding typically takes place without inspection
of the source address and malicious attacks have been launched using
spoofed source addresses. The inter-domain source address validation
architecture is an effort to enhance the Internet by using state
machine to generate consistent tags. When communicating between two
end hosts at different ADs of IPv6 network, tags will be added to the
packets to identify the authenticity of the IPv6 source address.

This memo focus on the data plane of the SAVA-X mechanism.

"Communication Protocol Between the AD Control Server and the AD Edge

Router of Inter-Domain Source Address Validation Architecture", Ke Xu,
Jianping Wu, Xiaoliang Wang, Yangfei Guo, 2022-05-21,
<draft-xu-savax-protocol-02.txt>

Because the Internet forwards packets according to the IP destination

address, packet forwarding typically takes place without inspection
of the source address and malicious attacks have been launched using
spoofed source addresses. The inter-domain source address validation
architecture is an effort to enhance the Internet by using state
machine to generate consistent tags. When communicating between two
end hosts at different ADs of IPv6 network, tags will be added to the
packets to identify the authenticity of the IPv6 source address.

This memo focus on the packet formats and processing flow of the
SAVA-X mechanism.
"IGMP and MLD Snooping Yang Module Extension for L2VPN", Hongji Zhao,
Xufeng Liu, Yisong Liu, Mahesh Sivakumar, Anish Peter, 2022-05-09,
<draft-zhao-pim-igmp-mld-snooping-yang-l2vpn-ext-01.txt>

Internet Group Management Protocol (IGMP) and Multicast Listener

Discovery (MLD) Snooping could be used in both BRIGDE service and L2VPN
service. The old ietf-igmp-mld-snooping yang module just describes the
BRIGDE service. In this document we extend the existing ietf-igmp-mld-
snooping yang module and make it could be used in L2VPN service.

"IKEv2 Count Based SA Extension", Daniel Migault, Daiying Liu, Congjie

Zhang, 2022-05-13, <draft-liu-ipsecme-ikev2-rekey-redundant-sas-01.txt>

This document describes an IKEv2 extension that enables a more

rational use of count based SA. This includes preventing the
creation of redundant SAs resulting from simultaneous rekeys.

"Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS)",

Ludovic Perret, Julien Prat, Mike Ounsworth, 2022-05-20,
<draft-perret-prat-lamps-cms-pq-kem-01.txt>

This document describes the conventions for using a Key Encapsulation

Mechanism algorithm (KEM) within the Cryptographic Message Syntax
(CMS). The CMS specifies the enveloped-data content type, which
consists of an encrypted content and encrypted content-encryption
keys for one or more recipients. The mechanism proposed here can
rely on either post-quantum KEMs, hybrid KEMs or classical KEMs.

"Intra-Network eXposure analyzer Utility Specification", Savyo Morais,

Claudio de Farias, 2022-05-26, <draft-morais-iotops-inxu-01.txt>

This document proposes the Intra-Network eXposure analyzer Utility

(INXU) as a vulnerability management solution for IoT networks. The
goal of INXU is to take advantage of the functions of the RFC 8520 to
allow a Security Experts Team on protecting multiple heterogeneous
IoT networks, even when there is a few or none private information of
the networks.

INXU identifies and analyzes the capability of an IoT device being

exploited by an well known malicious activity. We also propose the
Malicious Traffic Description (MTD), a data-model to describe traffic
related to malicious activities.

"Open Ethics Transparency Protocol", Nikita Lukianets, 2022-05-22,

<draft-lukianets-open-ethics-transparency-protocol-01.txt>

The Open Ethics Transparency Protocol (OETP) is an application-level

protocol for publishing and accessing ethical Disclosures of IT
Products and their Components. The Protocol is based on HTTP
exchange of information about the ethical "postures", provided in an
open and standardized format. The scope of the Protocol covers
Disclosures for systems such as Software as a Service (SaaS)
Applications, Software Applications, Software Components, Application
Programming Interfaces (API), Automated Decision-Making (ADM)
systems, and systems using Artificial Intelligence (AI). OETP aims
to bring more transparent, predictable, and safe environments for the
end-users. The OETP Disclosure Format is an extensible JSON-based
format.
"Link-Local Next Hop Capability for BGP", Russ White, Jeff Tantsura,
Donatas Abraitis, 2022-05-29, <draft-white-linklocal-capability-01.txt>

BGP, described in [RFC4271], was originally designed to provide

reachability between domains and between the edges of a domain. As
such, BGP assumes the next hop towards any reachable destination may
not reside on the advertising speaker, but rather may either be
through a router connected to the same subnet as the speaker, or
through a router only reachable by traversing multiple hops through
the network. Because of this, BGP does not recognize the use of IPv6
link-local addresses, as described in [RFC4291], as a valid next hop
for forwarding purposes.

However, BGP speakers are now often deployed on point-to-point links

in networks where multihop reachability of any kind is not assumed or
desired (all next hops are assumed to be the speaker reachable
through a directly connected point-to-point link). This is common,
for instance, in data center fabrics. In these situations, a global
IPv6 address is not required for the advertisement of reachability
information; in fact, providing global IPv6 addresses in these kinds
of networks can be detrimental to Zero Touch Provisioning (ZTP).

This draft standardizes the operation of BGP over a point-to-point

link using link-local IPv6 addressing only.

"Centralization, Decentralization, and Internet Standards", Mark

Nottingham, 2022-07-09,
<draft-nottingham-avoiding-internet-centralization-05.txt>

Despite being designed and operated as a decentralized network-of-

networks, the Internet is continuously subjected to forces that
encourage centralization.

This document offers a definition of centralization, explains why it

is undesirable, identifies different types of it, catalogues
limitations of common approaches to decentralization, and explores
what Internet standards efforts can do to address it.

"Using Service Bindings with DANE", Benjamin Schwartz, Robert Evans,

2022-06-22, <draft-rebs-dnsop-svcb-dane-01.txt>

Service Binding records introduce a new form of name indirection in

DNS. This document specifies DNS-Based Authentication of Named
Entities (DANE) interaction with Service Bindings to secure endpoints
including use of ports and transports discovered via Service
Parameters.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/bemasc/svcb-dane.

"IPlir network layer security protocol", Davletshina Alexandra, Urivskiy

Alexey, Rybkin Andrey, Tychina Leonid, Parshin Ilia, 2022-06-16,
<draft-iplir-protocol-01.txt>
 This document specifies the IPlir network layer security protocol.
It describes how to provide a set of security services for traffic
over public and corporate networks using the TCP/IP stack.

"Updated Use of the Expires Message Header Field", Benjamin BILLON, John
Levine, 2022-04-14, <draft-billon-expires-03.txt>

This document allows broader use of the Expires message header field
for SMTP. Senders can then indicate when a message sent becomes
valueless and can safely be deleted, while recipients would use the
information to delete these valueless messages.

"IP Parcels", Fred Templin, 2022-07-29,

<draft-templin-intarea-parcels-14.txt>

IP packets (both IPv4 and IPv6) contain a single unit of upper layer
protocol data which becomes the retransmission unit in case of loss.
Upper layer protocols including the Transmission Control Protocol
(TCP) and transports over the User Datagram Protocol (UDP) prepare
data units known as "segments", with traditional arrangements
including a single segment per IP packet. This document presents a
new construct known as the "IP Parcel" which permits a single packet
to carry multiple upper layer protocol segments, essentially creating
a "packet-of-packets". IP parcels provide an essential building
block for improved performance and efficiency while supporting larger
Maximum Transmission Units (MTUs) in the Internet as discussed in
this document.

"Emergency Registries", Brian Rosen, Brandon Abley, 2022-07-26,

<draft-rosen-ecrit-emergency-registries-01.txt>

Multiple emergency services standards organizations are developing

standards based on IETF emergency call standards and other IETF
protocols. There is a desire among these organizations to use common
registries not tied to a particular country or national Standards
Development Organization (SDO), in the long term pursuit of a single
worldwide standard. This document asks IANA to create a set of
registries and provides processes for expanding the set and
populating them.

"Service Routing in Multi-access Edge Computing", Zongpeng Du, 2022-07-10,

<draft-du-intarea-service-routing-in-mec-01.txt>

This document introduces a service routing mechanism in the scenario

of Multi-access Edge Computing.

"RIFT Auto-Flood Reflection", Jordan Head, Tony Przygienda, Colby Barth,

2022-06-27, <draft-head-rift-auto-fr-01.txt,.pdf>

This document specifies procedures where RIFT can automatically

provision IS-IS Flood Reflection topologies by leveraging its native
no-touch ZTP architecture.

"Deprecation of BGP OPEN Message Error subcodes 8, 9, and 10.", Job

Snijders, 2022-06-30, <draft-spaghetti-idr-deprecate-8-9-10-01.txt>

This document requests IANA to mark BGP OPEN Message Error subcodes
8, 9, and 10 as "deprecated".
"Remote Procedure Call over QUIC Version 1", Benjamin Coddington, Scott
Mayhew, Chuck Lever, 2022-07-05, <draft-cel-nfsv4-rpc-over-quicv1-01.txt>

This document specifies a protocol for conveying Remote Procedure

(RPC) messages on QUIC version 1 connections. It requires no
revision to application RPC protocols or the RPC protocol itself.

"Deadline Based Deterministic Forwarding", Shaofu Peng, Bin Tan, Peng Liu,
2022-07-08, <draft-peng-detnet-deadline-based-forwarding-02.txt>

This document describes a deterministic forwarding mechanism based on

deadline. The mechanism enhances strict priority scheduling
algorithm with dynamically adjusting the priority of the queue
according to its deadline attribute.

"Deadline Option", Shaofu Peng, Bin Tan, Peng Liu, 2022-07-11,

<draft-peng-6man-deadline-option-01.txt>

This document introduces new IPv6 options for Hop-by-Hop Options

header, to carry deadline related information for deterministic
flows.

"IGP Extensions for SR Network Resource Partition SIDs", Tarek Saad, Vishnu
Beeram, Ran Chen, Shaofu Peng, Bin Wen, Daniele Ceccarelli, 2022-07-11,
<draft-bestbar-lsr-spring-nrp-01.txt>

Segment Routing (SR) defines a set of topological "segments" within

an IGP topology to enable steering over a specific SR path. These
segments are advertised by the link-state routing protocols (IS-IS
and OSPF).

This document describes extensions to the IS-IS and OSPF required to

support the signaling of Resource Partition (NRP) segments that
operate over SR-MPLS and SRv6 dataplanes. Multiple SR NRP segments
can be associated with the same topological element to allow offering
of different forwarding treatments (e.g. scheduling and drop policy)
associated with each NRP.

"IGP Flexible Algorithm with Deterministic Routing", Shaofu Peng, Tony Li,
2022-08-24, <draft-peng-lsr-flex-algo-deterministic-routing-03.txt>

IGP Flexible Algorithm proposes a solution that allows IGPs to

compute constraint based paths over the network and specifies a way
of using Segment Routing (SR) Prefix-SIDs, SRv6 locators, or pure IP
prefixes to steer packets along the constraint-based paths. This
document describes how to compute deterministic delay paths within a
Flex-Algorithm topology.

"SMTP Enhanced Status Codes for Potentially Unwanted Mail", Alex Brotman,
2022-04-04, <draft-brotman-srds-02.txt>

We define a method by which an SMTP receiver can immediately notify a

sender that their message is suspected to be unwanted, although it
may still be accepted.

"Export of Segment Routing IPv6 Information in IP Flow Information Export

(IPFIX)", Thomas Graf, Benoit Claise, Pierre Francois, 2022-07-24,
<draft-tgraf-opsawg-ipfix-srv6-srh-05.txt>
 This document introduces new IP Flow Information Export (IPFIX)
information elements to identify the SRv6 Segment Routing Header
dimensions, the SRv6 Control Plane Protocol and the SRv6 Endpoint
Behavior that traffic is being forwarded with.

"Virtualization of PLC in Industrial Networks - Problem Statement", Kiran

Makhijani, Lijun Dong, 2022-03-05, <draft-km-iotops-iiot-frwk-02.txt>

Conventional Programmable Logic Controllers (PLCs) impose several

challenges on factory floors as their numbers and size on the factory
floors/plants continues to grow. Virtualized PLCs can help overcome
many of those concerns. They can improve the automation in Industry
control networks by simplifying communication between higher-level
applications and low-level factory floor machine operations. Virtual
PLCs provide an opportunity to integrate a diverse set of non-
internet protocols supporting Industrial-IoT and IP connections to
improve coordination between applications and field devices. Besides
automation, virtual PLCs also enhance programmability in industry
process control systems by abstracting control functions from I/O
modules. However, to achieve desired outcome and benefits, both
operational and application networks should evolve.

This document introduces virtual PLC concept, describes the details

and benefits of virtualized PLCs, then focuses on the problem
statement and requirements.

"Use Cases of Computing-aware Service Function Chaining (SFC)", Shuai

Zhang, Xia Chen, 2022-07-25,
<draft-zhang-computing-aware-sfc-usecase-01.txt>

Multiple occurrences of the same service function(SF) can exist in

the same administrative domain and each occurrence of SF is called SF
instance. A Service Function Path(SFP) is determined by composing
selected SF instances and overlay links. The SF instances are
selected according to the computing power of SFs in addition to the
network information and this is defined as the computing-aware SFC in
this document.

This document describes the use cases for computing-aware Service

Function Chaining(SFC).

"RTP Payload Format for Visual Volumetric Video-based Coding (V3C)", Lauri
Ilola, Lukasz Kondrad, 2022-06-27, <draft-ilola-avtcore-rtp-v3c-02.txt>

This memo describes an RTP payload format for visual volumetric

video-based coding (V3C) [ISO.IEC.23090-5]. A V3C bitstream is
composed of V3C units that contain V3C video sub-bitstreams, V3C
atlas sub-bitstreams, or a V3C parameter set. The RTP payload format
for V3C video sub-bitstreams is defined by appropriate Internet
Standards for the applicable video codec. The RTP payload format for
V3C atlas sub-bitstreams is described by this memo. The RTP payload
format allows for packetization of one or more V3C Network
Abstraction Layer (NAL) units in a RTP packet payload as well as
fragmentation of a V3C NAL unit into multiple RTP packets. The memo
also describes the mechanisms for grouping RTP streams of V3C
component sub-bitstreams, providing a complete solution for streaming
V3C bitstream.

"Multi-part TLVs in IS-IS", Parag Kaneriya, Tony Li, Tony Przygienda,

Shraddha Hegde, Chris Bowers, Les Ginsberg, 2022-07-04,
<draft-pkaneria-lsr-multi-tlv-01.txt>

New technologies are adding new information into IS-IS while

deployment scales are simultaneously increasing, causing the contents
of many critical TLVs to exceed the currently supported limit of 255
octets. Extensions such as [RFC7356] require significant IS-IS
changes that could help address the problem, but a less drastic
solution would be beneficial. This document codifies the common
mechanism of extending the TLV content space through multiple TLVs.

"Requirements to Multi-domain IPv6-only Network", Chongfeng Xie, Chenhao

Ma, Xing Li, Gyan Mishra, Mohamed Boucadair, 2022-03-06,
<draft-xie-v6ops-reqirements-multi-domain-ipv6only-01.txt>

Dual-stack deployments require both IPv4 and IPv6 transfer

capabilities are deployed in parallel. IPv6-only is considered as
the ultimate stage where only IPv6 transfer capabilities are used
while ensuring global reachability. This document specifies
requirements when deploying IPv6-only in multi-domain networks.

"A YANG Data Model for Network Resource Partition (NRP)", Bo Wu, Dhruv
Dhody, Ying Cheng, 2022-07-11, <draft-wd-teas-nrp-yang-01.txt>

This document defines a YANG data model for managing Network Resource
Partition (NRP) topologies and associated resource allocation. The
model can be used for the realization of IETF network slice services.

"Considerations for the use of SDN in Semantic Routing Networks", Mohamed

Boucadair, Dirk Trossen, Adrian Farrel, 2022-05-31,
<draft-boucadair-irtf-sdn-and-semantic-routing-01.txt>

The forwarding of packets in today's networks has long evolved beyond

ensuring mere reachability of the receiving endpoint. Instead, other
'purposes' of communication, e.g., ensuring quality of service of
delivery, ensuring protection against path failures through utilizing
more than one, and others, are realized by many extensions to the
original reachability purpose of IP routing.

Semantic Routing defines an approach to realizing such extended

purposes beyond reachability by instead making routing and forwarding
decisions based, not only on the destination IP address, but on other
information carried in an IP packet. The intent is to facilitate
enhanced routing decisions based on this information in order to
provide differentiated forwarding paths for specific packet flows.

Software Defined Networking (SDN) places control of network elements

(including all or some of their forwarding decisions) within external
software components called controllers and orchestrators. This
approach differs from conventional approaches that solely rely upon
distributed routing protocols for the delivery of advanced
connectivity services. By doing so, SDN aims to enable network
elements to be simplified while still performing forwarding function.

This document examines the applicability of SDN techniques to

Semantic Routing and provides considerations for the development of
Semantic Routing solutions in the context of SDN.

"Continuing to Evolve Internet Routing Beyond 'Mere' Reachability", Dirk

Trossen, Zhe Lou, Sheng Jiang, 2022-06-30,
<draft-trossen-rtgwg-routing-beyond-reachability-01.txt>

This document discusses the evolution of the Internet routing system

beyond mere reachability. We observe, through examples of past
development, that such evolution has been taking place to improve on
capabilities of the Internet, deal with more complicated network
deployments and cater to changing requirements by end users as well
as novel and emerging applications.

For achieving a routing system that serves more than a singular

reachability purpose, more information is taken into account when
performing the purpose-specific functions. Such extra information
can be obtained by extending current routing protocols to exchange
more information or by carrying that information within packets.

This document is intended to seed discussions of how the observed

evolution of the Internet's routing system can continue, what issues
may occur when simply continuing the current approach for achieving
routing beyond 'mere' reachability and what may be needed to address
those issues. Ultimately, however, this document recognizes the
positive impact that moving beyond reachability has brought to the
Internet and will continue to do so.

"Warp - Segmented Live Media Transport", Luke Curley, 2022-07-09,

<draft-lcurley-warp-01.txt>

This document defines the core behavior for Warp, a segmented live
media transport protocol. Warp maps live media to QUIC streams based
on the underlying media encoding. Media is prioritized to reduce
latency when encountering congestion.

"YANG Extension and Metadata Annotation for Immutable Flag", Qiufang Ma,
Qin WU, Balazs Lengyel, Hongwei Li, 2022-08-11,
<draft-ma-netmod-immutable-flag-03.txt>

This document defines a YANG extension named "immutable" to indicate

that specific "config true" data nodes are not allowed to be
created/deleted/updated. To indicate that specific entries of a
list/leaf-list node or instances inside list entries cannot be
updated/deleted after initialization, a metadata annotation with the
same name is also defined. Any data node or instance marked as
immutable is read-only to the clients of YANG-driven management
protocols, such as NETCONF, RESTCONF and other management operations
(e.g., SNMP and CLI requests).

This document aims to provide more visibility into immutability

characteristic of particular schema or instance nodes by defining a
standard mechanism to allow the server to document the existing
immutable configuration data, while this doesn't mean attaching such
restrictions is encouraged.

"Suppressing CA Certificates in TLS 1.3", Martin Thomson, Panos Kampanakis,

Cameron Bytheway, Bas Westerbaan, 2022-07-08,
<draft-kampanakis-tls-scas-latest-02.txt>

A TLS client or server that has access to the complete set of

published intermediate certificates can inform its peer to avoid
sending certificate authority certificates, thus reducing the size of
 the TLS handshake.

"Impact of DLTs on Provider Networks", Dirk Trossen, David Guzman, Mike

McBride, Xinxin Fan, 2022-08-30, <draft-trossen-rtgwg-impact-of-dlts-02.txt>

This document discusses the impact of distributed ledger technologies

being realized over IP-based provider networks. The focus here lies
on the impact that the DLT communication patterns have on efficiency
of resource usage in the underlying networks. We provide initial
insights into experimental results to quantify this impact in terms
of inefficient and wasted communication, aligned along challenges
that the DLT realization over IP networks faces.

This document intends to outline this impact but also opportunities

for network innovations to improve on the identified impact as well
as the overall service quality. While this document does not promote
specific solutions that capture those opportunities, it invites the
wider community working on DLT and network solutions alike to
contribute to the insights in this document to aid future research
and development into possible solution concepts and technologies.

The findings presented here have first been reported within the
similarly titled whitepaper released by the Industry IoT Consortium
(IIC) [IIC_whitepaper].

"Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth", Xiao
Min, Zheng Zhang, Weiqiang Cheng, 2022-08-15,
<draft-xzc-lsr-mpls-flc-frld-01.txt>

Flow-ID Label (FL) is used for MPLS flow identification and flow-
based performance measurement with alternate marking method. The
ability to process Flow-ID labels is called Flow-ID Label Capability
(FLC), and the capability of reading the maximum label stack depth
and performing FL-based performance measurement is called Flow-ID
Readable Label Depth (FRLD). This document defines a mechanism to
signal the FLC and the FRLD using IGP and BGP-LS.

"L3ND Upper-Layer Protocol Configuration", Randy Bush, Keyur Patel,

2022-04-04, <draft-ymbk-idr-l3nd-ulpc-05.txt>

This document adds PDUs to the Layer-3 Neighbor Discovery protocol to

communicate the parameters needed to exchange inter-device Upper
Layer Protocol Configuration for upper-layer protocols such as the
BGP family.

"Layer-3 Neighbor Discovery", Randy Bush, Russ Housley, Rob Austein, Susan
Hares, Keyur Patel, 2022-04-04, <draft-ymbk-idr-l3nd-04.txt>

Data Centers where the topology is BGP-based need to discover

neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3
Neighbor Discovery protocol identifies BGP neighbor candidates.

"Standard PKC Test Keys", Peter Gutmann, Corey Bonnell, 2022-03-21,

<draft-gutmann-testkeys-01.txt>

This document provides a set of standard PKC test keys that may be
used wherever pre-generated keys and associated operations like
digitial signatures are required. Like the EICAR virus test file,
these widely-known test keys can be detected and recognised by
 applications consuming them as being purely for testing purposes
without assigning any security properties to them.

"Enhanced Port Forwarding functions with CGNAT", Louis Chan, 2022-08-21,

<draft-chan-tsvwg-eipf-cgnat-01.txt>

There is a need for peer-to-peer (P2P) communication under the use

of
CGNAT in service providers. With the combination of home gateway,
this
becomes NAT444.
In RFC5128, methods of using UDP hole punching
solves the problem partially
when EIM (Endpoint-Independent
Mapping) is supported in NAT device in
the path, and there exists
a common rendezvous server.

The success rate of UDP hole punching is high, but not TCP hole punching
in practical world. Also, the P2P solution requires a common
server
in the public internet to exchange the IP and port
information.

In this draft, a method is described to achieve incoming TCP or UDP

session without a common rendezvous server in NAT444 situation.

"Private Line Emulation over Packet Switched Networks", Steven Gringeri,

Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Luca Chiesa,
Nagendra Nainar, Carlos Pignataro, Gerald Smallegange, Chris Brown, Faisal
Dada, 2022-08-19, <draft-schmutzer-pals-ple-01.txt>

This document describes a method for encapsulating high-speed bit-

streams as virtual private wire services (VPWS) over packet switched
networks (PSN) providing complete signal transport transparency.

"IKEv2 IPv4 Downstream Fragmentation Notification Extension", Daiying Liu,

Daniel Migault, Renwang Liu, Congjie Zhang, 2022-05-13,
<draft-liu-ipsecme-ikev2-mtu-dect-02.txt>

This document defines the IKEv2 IPv4 Downstream Fragmentation

Notification Extension which enables a receiving security gateway to
notify the sending receiving gateway that downstream fragmentation is
ongoing. The sending gateway MAY take action to avoid such
fragmentation to occur.

"The 'notes' URI Scheme for viewing HCL Notes/Domino resources", Doug
Conmy, 2022-03-20, <draft-dconmy-notes-uri-scheme-02.txt>

This document describes the 'notes' URI scheme. Specifically, it

lays out the syntactic components and how those components are used
by URI resolution to locate and view or edit a Notes resource,
typically an application and/or document.

"Using CDDL for CSVs", Carsten Bormann, 2022-08-29,

<draft-bormann-cbor-cddl-csv-01.txt>

The Concise Data Definition Language (CDDL), standardized in RFC

8610, is defined to provide data models for data shaped like JSON or
 CBOR.

Another representation format that is quote popular is the CSV

(Comma-Separated Values) file as defined by RFC 4180.

The present document shows a way how to use CDDL to provide a data
model for CSV files.

"tus - Resumable Uploads Protocol", Marius Kleidl, Jiten Mehta, Guoye

Zhang, Lucas Pardue, Stefan Matsson, 2022-07-25,
<draft-tus-httpbis-resumable-uploads-protocol-02.txt>

HTTP clients often encounter interrupted data transfers as a result

of canceled requests or dropped connections. Prior to interruption,
part of a representation may have been exchanged. To complete the
data transfer of the entire representation, it is often desirable to
issue subsequent requests that transfer only the remainder of the
representation. HTTP range requests support this concept of
resumable downloads from server to client. This document describes a
mechanism that supports resumable uploads from client to server using
HTTP.

"One-way Delay Measurement Based on Reference Delay", Hongwei Yang, Kehan

Yao, Jean-Yves Le Boudec, 2022-06-29,
<draft-lyy-detnet-ref-delay-measurement-01.txt>

The end-to-end network one-way delay is an important performance

metric in the 5G network. For realizing the accurate one-way delay
measurement, existing methods requires the end-to-end deployment of
accurate clock synchronization mechanism, such as PTP or GPS, which
results in relatively high deployment cost. Another method can
derive the one-way delay from the round-trip delay. In this case,
since the delay of the downlink and uplink of the 5G network may be
asymmetric, the measurement accuracy is relatively low. Hence, this
document introduces a method to measure the end-to-end network one-
way delay based on a reference delay guaranteed by deterministic
networking without clock synchronization.

"Considerations for Protection of SRv6 Networks", Yisong Liu, Weiqiang

Cheng, Changwang Lin, Xuesong Geng, Liu Yao, 2022-07-06,
<draft-liu-rtgwg-srv6-protection-considerations-02.txt>

This document describes the considerations for protection of SRv6

network.

"Extensible Provisioning Protocol (EPP) Mapping over HTTP", Mario Loffredo,

Lorenzo Trombacchi, Maurizio Martinelli, Jan Romanowski, Marcin Machnio,
2022-06-13, <draft-loffredo-regext-epp-over-http-02.txt>

This document describes how the Extensible Provisioning Protocol

(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.

"S-BFD Path Consistency over SRv6", Changwang Lin, Weiqiang Cheng, Jiang
Wenying, 2022-07-10, <draft-lin-sbfd-path-consistency-over-srv6-02.txt>

Bidirectional Forwarding Detection (BFD) can be used to monitor

 paths between nodes. Seamless BFD (S-BFD) provides a simplified
mechanism which is suitable for monitoring of paths that are setup
dynamically and on a large scale network. In SRv6, when a headend
use S-BFD to monitor the segment list/CPath of SRv6 Policy, the
forward path of control packet is indicated by segment list, the
reverse path of response control packet is via the shortest path
from the reflector back to the initiator (headend) as determined by
routing. The forward path and reverse path of control packet are
likely inconsistent going through different intermediate nodes or
links. This document describes a method to keep the forward path and
reverse path of S-BFD consistent when detecting SRv6 Policy.

"Everything over CoAP", Christian Amsuess, 2022-07-11,

<draft-amsuess-core-coap-kitchensink-02.txt>

The Constrained Application Protocol (CoAP) has become the base of

applications both inside of the constrained devices space it
originally aimed for and outside. This document gives an overview of
applications that are, can, may, and would better not be implemented
on top of CoAP.

"Benchmarking Methodology for MPLS Segment Routing", Giuseppe Fioccola,

Eduard, Paolo Volpato, Luis Contreras, 2022-07-06,
<draft-vfv-bmwg-srmpls-bench-meth-02.txt>

This document defines a methodology for benchmarking Segment Routing

(SR) performance for Segment Routing over MPLS (SR-MPLS). It builds
upon [RFC2544], [RFC5695] and [RFC8402].

"Benchmarking Methodology for IPv6 Segment Routing", Giuseppe Fioccola,

Eduard, Paolo Volpato, Luis Contreras, 2022-07-06,
<draft-vfv-bmwg-srv6-bench-meth-02.txt>

This document defines a methodology for benchmarking Segment Routing

(SR) performance for Segment Routing over IPv6 (SRv6). It builds
upon [RFC2544], [RFC5180], [RFC5695] and [RFC8402].

"SRPM Path Consistency over SRv6", sijun weng, Weiqiang Cheng, Changwang
Lin, Xiao Min, 2022-07-08,
<draft-weng-ippm-srpm-path-consistency-over-srv6-01.txt>

Twamp can be used to measure the performance of end-to-end paths in

networks. Stamp [rfc8762] and twamp light are more lightweight
measurement methods. In the SRv6 network, it is also necessary to
measure the performance of SRv6 policy. This document describes a
method to measure srv6 policy through stamp and twamp light.

"Computing Resource Representation in Computing Aware Networking", Zongpeng

Du, Yuexia Fu, 2022-07-11,
<draft-du-computing-resource-representation-01.txt>

This document introduces the way of encoding service-specific

information and the way of signaling it in the network.

"IETF Network Slice Service Mapping YANG Model", Dhruv Dhody, Bo Wu,
2022-07-11, <draft-dhody-teas-ietf-network-slice-mapping-01.txt>

This document provides a YANG data model to map IETF network slice
service to Traffic Engineering (TE) models (e.g., the Virtual Network
 (VN) model or the TE Tunnel etc). It also supports mapping to the
VPN Network models and Network Resource Partition (NRP) models.
These models are referred to as IETF network slice service mapping
model and are applicable generically for the seamless control and
management of the IETF network slice service with underlying TE/VPN
support.

The models are principally used for monitoring and diagnostics of the
management systems to show how the IETF network slice service
requests are mapped onto underlying network resource and TE/VPN
models.

"Inband Flow Learning Framework", Liuyan Han, Minxue Wang, Fan Yang,
2022-07-11, <draft-hwy-opsawg-ifl-framework-01.txt>

To deploy the inband performance measurement and flow information

telemetry on live traffic, this document proposes a framework of an
inband and flow based flow information learning mechanism called
Inband Flow Learning (IFL). This document also provides different
deployment approaches and considerations in practical network
deployment.

"A Framework for QoS-Enabled Semantic Routing in Industrial Networks",

Paolo Bellavista, Luca Foschini, Lorenzo Patera, Mattia Fogli, Carlo
Giannelli, Cesare Stefanelli, Zhe Lou, 2022-08-31,
<draft-bellavista-semantic-sdn-mom-01.txt>

Industrial networks pose unique challenges in realizing a

communication substrate on the shop floor. Such challenges are due
to strict Quality of Service (QoS) requirements, a wide range of
protocols for data exchange, and highly heterogeneous network
infrastructures. In this regard, this document proposes a framework
for QoS-enabled semantic routing in industrial networks. Such a
framework aims at providing loosely-coupled, asynchronous
communications, fine-grained traffic management (delivery semantics
and flow priorities), and in-network traffic optimization.

"I2NSF Remote Attestation Interface YANG Data Model", Penglin Yang,

chenmeiling, Li Su, Diego Lopez, Jaehoon Jeong, Linda Dunbar, 2022-06-05,
<draft-yang-i2nsf-remote-attestation-interface-dm-01.txt>

This document describes the architecture and corresponding interfaces

of NSF remote attestation in I2NSF framework. Remote attestation of
NSFs could provide integrity assurence of NSFs deployed in remote
environment. The interfaces involved are I2NSF remote attestation
evidence interface, I2NSF remote attestation reference value
interface, and I2NSF remote attestation result interface. This
document complies with I2NSF architecture and Remote Attestation
ProcedureS (RATs) architecture.

"BGP SR Policy Extensions for Network Resource Partition", Jie Dong, Zhibo
Hu, Ran Pang, 2022-07-11, <draft-dong-idr-sr-policy-nrp-01.txt>

Segment Routing (SR) Policy is a set of candidate paths, each

consisting of one or more segment lists and the associated
information. The header of a packet steered in an SR Policy is
augmented with an ordered list of segments associated with that SR
Policy. A Network Resource Partition (NRP) is a collection of
network resources allocated in the network which can be used to
 support one or a group of IETF network slice services.

In networks where there are multiple NRPs, an SR Policy may be

associated with a particular NRP. The association between SR Policy
and NRP needs to be specified, so that for service traffic which is
steered into the SR Policy, the header of the packets can be
augmented with the information associated with the NRP. An SR Policy
candidate path can be distributed using BGP SR Policy. This document
defines the extensions to BGP SR policy to specify the NRP which the
SR Policy candidate path is associated with.

"User Ports for Experiments", Joseph Touch, 2022-08-04,

<draft-touch-tsvwg-usr-exp-01.txt>

This document defines user ports for experiments using transport

protocols. It describes the use of experiment identifiers to enable
shared use of these user ports, as well as updating the use of
system ports for experiments [RFC4727] in the same manner.

"Advertisement of Dedicated Metric for Flexible Algorithm in IGP",

Changwang Lin, Mengxiao Chen, Weiqiang Cheng, Liyan Gong, 2022-08-30,
<draft-lin-lsr-flex-algo-metric-01.txt>

This document proposes a method to advertise dedicated metric for

Flex-Algorithm in IGP.

"Framework For Internet Basic Behavior Metrics", Wei Ding, 2022-03-04,

<draft-ding-ibbm-framework-00.txt>

This document provides a definition of Internet Basic Behavior

Measurement(IBBM) based on the Internet architecture and describes in
detail the specifications to be followed for the metrics and
measurement activities under IBBM, which are given in the form of
elements. The main purpose of this document is to standardize the
accurate meaning and expression of metrics obtained based on Internet
behavioral measurement activities, to improve the worth of the
measurement results.

"BGP SPF for Network Resource Partitions", Jie Dong, Zhenbin Li, Haibo
Wang, 2022-03-04, <draft-dong-lsvr-bgp-spf-nrp-00.txt>

A VTN is a virtual underlay network which has customized network

topology and a set of dedicated or shared network resources. Network
Resource Partition (NRP) refers to a set of network resources that
are available to carry traffic and meet the SLOs and SLEs. Multiple
NRPs can be created in a network to provide different Virtual
Transport Networks (VTN) to meet the requirements of different
services or different service groups.

As the number of NRP increases, there can be scalability concerns

about using Interial Gateway Protocols (IGP) to distribute the NRP
information in the network. In networks where BGP Shortest Path
First (SPF) can used as the underlay routing mechanism to distribute
the link-state information among network nodes, the information of
NRPs needs to be distributed along with the basic network
information. This document specifies the BGP SPF mechanisms with
necessary extensions to distribute the NRP information and perform
NRP-specific path computation.
"dry-run DNSSEC", Yorgos Thessalonikefs, Willem Toorop, Roy Arends,
2022-07-11, <draft-yorgos-dnsop-dry-run-dnssec-01.txt>

This document describes a method called "dry-run DNSSEC" that allows

for testing DNSSEC deployments without affecting the DNS service in
case of DNSSEC errors. It accomplishes that by introducing a new DS
Type Digest Algorithm that signals validating resolvers that dry-run
DNSSEC is used for the zone. DNSSEC errors are then reported with
DNS Error Reporting, but any bogus responses to clients are withheld.
Instead, validating resolvers fallback from dry-run DNSSEC and
provide the response that would have been answered without the
presence of a dry-run DS. A further option is presented for clients
to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC
testing.

"Path Tracing in SRv6 networks", Clarence Filsfils, Ahmed Abdelsalam, Pablo

Camarillo, Mark Yufit, Thomas Graf, Yuanchao Su, Satoru Matsushima, Mike
Valentine, Amit Dhamija, 2022-08-16,
<draft-filsfils-spring-path-tracing-02.txt>

Path Tracing provides a record of the packet path as a sequence of

interface ids. In addition, it provides a record of end-to-end
delay, per-hop delay, and load on each egress interface along the
packet delivery path.

Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop-
by-Hop extension header.

Path Tracing supports fine grained timestamp. It has been designed

for linerate hardware implementation in the base pipeline.

"Just Another Measurement of Extension header Survivability (JAMES)", Eric

Vyncke, Raphael Leas, Justin Iurman, 2022-07-11,
<draft-vyncke-v6ops-james-02.txt>

In 2016, RFC7872 has measured the drop of packets with IPv6 extension
headers. This document presents a slightly different methodology
with more recent results. It is still work in progress.

"Precision Availability Metrics for SLO-Governed End-to-End Services", Greg

Mirsky, Joel Halpern, Xiao Min, Alexander Clemm, John Strassner, Jerome
Francois, 2022-08-25, <draft-mhmcsfh-ippm-pam-02.txt>

This document defines a set of metrics for networking services with

performance requirements expressed as Service Level Objectives (SLO).
These metrics, referred to as Precision Availability Metrics (PAM),
are useful for defining and monitoring of SLOs. Specifically, PAM
can be used by providers and/or users of the Network Slice service to
assess whether the service is provided in compliance with its
specified quality, i.e., in accordance with its defined SLOs.

"Game State over Real Time Protocol", Cullen Jennings, Rich Logan,
2022-03-04, <draft-jennings-dispatch-game-state-over-rtp-00.txt>

This specification defines an Real Time Protocol (RTP) payload to

send game moves and the state of game objects over RTP. This is
useful for games as well collaboration systems that use augment or
virtual reality.
 RTP provide a way to synchronize game state between players with
robust technique for recovery from network packet loss while still
having low latency.

"An Alt-Svc Parameter and SvcParamKey for QUIC Versions", Martin Duke,
Lucas Pardue, 2022-04-27, <draft-duke-httpbis-quic-version-alt-svc-01.txt>

HTTP Alternative Services (Alt-Svc) describes how one origin's

resource can be accessed via a different protocol/host/port
combination. Alternatives are advertised by servers using the Alt-
Svc header field or the ALTSVC frame. This includes a protocol name,
which reuses Application Layer Protocol Negotiation (ALPN)
codepoints. The "h3" codepoint indicates the availability of HTTP/3.
A client that uses such an alternative first makes a QUIC connection.
However, without a priori knowledge of which QUIC version to use,
clients might incur a round-trip latency penalty to complete QUIC
version negotiation, or forfeit desirable properties of a QUIC
version. This document specifies a new Alt-Svc parameter that
specifies alternative supported QUIC versions, which substantially
reduces the chance of this penalty.

Similarly, clients can retrieve additional instructions about access

to services or resources via DNS SVCB and HTTP Resource Records.
This document also defines a new SvcParamKey for these Resource
Records, which specifies the specific QUIC versions in use.

"BIER-TE Encapsulation with Multiple BitStrings", Huaimo Chen, Mike

McBride, Ran Chen, Gyan Mishra, Aijun Wang, Yanhe Fan, Lei Liu, Xufeng Liu,
2022-09-04, <draft-chen-bier-te-enc-01.txt>

This document describes a "Bit Index Explicit Replication Traffic

Engineering" (BIER-TE) header, two levels of Bit Index Forwarding
Tables (BIFTs) and a forwarding procedure for efficiently processing
BIER-TE packets with the header. For a multicast packet with an
explicit point-to-multipoint (P2MP) path, which has multiple
BitStrings, the packet with the header containing the BitStrings is
replicated and forwarded statelessly along the path.

"QuicR - Media Delivery Protocol over QUIC", Cullen Jennings, Suhas

Nandakumar, 2022-07-11, <draft-jennings-moq-quicr-arch-01.txt>

This specification outlines the design for a media delivery protocol

over QUIC. It aims at supporting multiple application classes with
varying latency requirements including ultra low latency applications
such as interactive communication and gaming. It is based on a
publish/subscribe metaphor where entities publish and subscribe to
data that is sent through, and received from, relays in the cloud.
The information subscribed to is named such that this forms an
overlay information centric network. The relays allow for efficient
large scale deployments.

"QuicR - Media Delivery Protocol over QUIC", Cullen Jennings, Suhas

Nandakumar, Christian Huitema, 2022-07-11,
<draft-jennings-moq-quicr-proto-01.txt>

Recently new use cases have emerged requiring higher scalability of

media delivery for interactive realtime applications and much lower
latency for streaming applications and a combination thereof.
 draft-jennings-moq-arch specifies architectural aspects of QuicR, a
media delivery protocol based on publish/subscribe metaphor and Relay
based delivery tree, that enables a wide range of realtime
applications with different resiliency and latency needs.

This specification defines the protocol aspects of the QuicR media

delivery architecture.

"BGP SR Policy Extensions for metric", KaZhang, Jie Dong, 2022-03-05,

<draft-zhang-idr-sr-policy-metric-00.txt>

SR Policy candidate paths can be represented in BGP UPDATE messages.

BGP can then be used to propagate the SR Policy candidate paths to
the headend nodes in the network. After SR Policy is installed on
the ingress node, the packets can be steered into SR Policy through
route selection. Therefore, route selection may be performed on the
ingress node of the SR Policy. If there are multiple routes to the
same destination, the route selection node can select routes based on
the local policy. The local policy may use the IGP metric of the
selected path, which is the IGP Metric of the SR Policy. Thus the
BGP UPDATE message need carry the metric of each segment list of the
SR Policy Candidate Path, which can be used in path selection of
routing.

"Problem Statement and Use Cases of Adaptive Traffic Data Collection",

Xiaoming He, Dongfeng Mao, Qiufang Ma, Tianran Zhou, 2022-03-05,
<draft-he-adaptive-collecting-problem-usecases-00.txt>

IP carrier network needs to provide real-time traffic visibility to

help network operators quickly and accurately locate network
congestion and packet loss, and make timely path adjustment for
deterministic services in order to avoid congestion. It is essential
to explore the adaptive traffic data collection mechanism so as to
capture real-time network state at minimum resource consumption.

This document summarizes the problems currently faced by network

operators when attempting to provide timely traffic data collection
to satisfy the various scenarios that require real-time network state
and traffic visibility, and aggregates the requirements for adaptive
traffic collecting mechanism from a variety of deployment scenarios.

"Discovery of Oblivious Services via Service Binding Records", Tommy Pauly,

Tirumaleswar Reddy.K, 2022-07-27, <draft-pauly-ohai-svcb-config-03.txt>

This document defines a parameter that can be included in SVCB and

HTTPS DNS resource records to denote that a service is accessible
using Oblivious HTTP, by offering an Oblivious Gateway Resource
through which to access the target. This document also defines a
mechanism to learn the key configuration of the discovered Oblivious
Gateway Resource.

"Stateless Traffic Engineering Multicast using MRH", Huaimo Chen, Mike

McBride, Yanhe Fan, Zhenbin Li, Xuesong Geng, Mehmet Toy, Gyan Mishra,
Yisong Liu, Aijun Wang, Lei Liu, Xufeng Liu, 2022-07-11,
<draft-chen-pim-mrh6-03.txt>

This document describes a stateless traffic engineering (TE)

multicast along an explicit P2MP Path/Tree using an IPv6 extension
header called TE multicast routing header (MRH). The MRH with the
 path encoded in link numbers is added into a packet to be multicast
at the ingress. The packet is delivered to the egresses along the
path. There is no state stored in the core of the network.

"Careful resumption of congestion control from retained state with QUIC",

Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom Jones, Christian Huitema,
2022-07-10, <draft-kuhn-quic-careful-resume-02.txt>

This document discusses careful resumption of congestion control

parameters in QUIC with a cautious method that enables faster startup
of new connections.

The method uses a set of computed congestion control parameters that

are based on the previously observed path characteristics, such as
the bottleneck bandwidth, available capacity, or the RTT. These
parameters are stored and can then used to modify the congestion
control behaviour of a subsequent connection. The draft discusses
assumptions around how a server ought to utilise these parameters to
provide opportunities for a new connection to more quickly get up to
speed (i.e. utilise available capacity). It discusses how these
changes impact the capacity at a shared network bottleneck and the
response that is needed after any indication that the new rate is
inappropriate.

"BDP Frame Extension", Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom
Jones, Christian Huitema, 2022-03-06,
<draft-kuhn-quic-bdpframe-extension-00.txt>

This draft describes the BDP Frame extension for QUIC. It enables
the exchange of information related to the path characteristics
between the client and the server during a connection. This
information can later be exploited when a new connection is
established.

"Semantic Address Based Instructive Routing for Satellite Network", Lin

Han, Alvaro Retana, Richard Li, 2022-09-02,
<draft-lhan-satellite-instructive-routing-01.txt>

This document presents a method to do IP routing over satellite

network that consists of LEO (Low Earth Orbit) satellites and ground-
stations. The method uses the source routing mechanism. The whole
routing info is obtained by path calculation. The routing path
information is converted to be a list of instructions and embedded
into user packet's IPv6 extension header. At each hop or each
satellite, the routing process engine will forward the packet based
on the specified instruction for the satellite. Until the packet
reaches the edge of satellite network, or the last satellite, the
packet will be sent to a ground station.

"An IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record",
Donald Eastlake, Haoyu Song, 2022-05-30,
<draft-eastlake-dnsop-rrtype-srv6-01.txt>

A Domain Name System (DNS) Resource Record (RR) Type is specified for
storing IPv6 Segment Routing (SRv6) Information in the DNS.

"5G Distributed UPFs", Zhaohui Zhang, Keyur Patel, Tianji Jiang, Luis
Contreras, 2022-07-11, <draft-zzhang-dmm-5g-distributed-upf-01.txt>
 This document describes evolution of mobile user plane in 5G,
including distributed UPFs and alternative user plane implementations
that some vendors/operators are pushing without changing 3GPP
architecture/signaling. This also sets the stage for discussions in
a companion document about potentially integrating UPF and Acess Node
(AN) in a future generation (xG) of mobile network.

"Mobile User Plane Evolution", Zhaohui Zhang, Keyur Patel, Luis Contreras,
2022-07-11, <draft-zzhang-dmm-mup-evolution-01.txt>

[I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile

user plane in 5G, including distributed UPFs and alternative user
plane implementations that some vendors/operators are pushing without
changing 3GPP architecture/signaling. Building on top of that, this
document further discusses potentially integrating UPF and Acess Node
(AN) in a future generation (xG) of mobile network.

This document is not an attempt to do 3GPP work in IETF. Rather, it

discusses potential integration of IETF/wireline and 3GPP/wireless
technologies - first among parties who are familiar with both areas
and friendly with IETF/wireline technologies. If the ideas in this
document are deemed reasonable, feasible and desired among these
parties, they can then be brought to 3GPP for further discussions.

"Improve logging credibility by adding synchronization time information",

Fengsheng Wang, chenmeiling, Li Su, 2022-03-06,
<draft-chen-syslog-syscinfo-credibility-00.txt>

This document proposes a scheme to improve the credibility of log

reporting time by adding time synchronization information.

This document updates the "timeQuality" structured Data in RFC 5424

[RFC5424], The Syslog Protocol. By appending "SYNCINFO" information
after the "isSynced" parameter, the log collector can judge the
credibility of logs when correlating logs of different devices.

"Use Cases for Computing-aware Software-Defined Wide Area Network(SD-WAN)",

Shuai Zhang, Li Jianfei, Cheng Li, Xia Chen, 2022-03-06,
<draft-zhang-dyncast-computing-aware-sdwan-usecase-00.txt>

SD-WAN is aware of the computing power of applications deployed in

the multiple sites of enterprise and can perform the routing policy
according to such information. This is defined as the computing-
aware SD-WAN.This document describes the use cases for computing-
aware Software-Defined Wide Area Network(SD-WAN).

"MSR6(Multicast Source Routing over IPv6) Use Cases", Yisong Liu, Feng
Yang, Aijun Wang, XueruZhang, Xuesong Geng, Zhenbin Li, 2022-07-11,
<draft-liu-msr6-use-cases-01.txt>

MSR6 (Multicast Source Routing over IPv6) defines multicast

replication as a Layer 3 function. It reuses existing IPv6 headers,
functions, and capabilities to forward packets through non-multicast
nodes, and adds no flow state at intermediate network nodes.

This document introduces the use cases for MSR6.

"LSR for SR Proxy Forwarding", Zhibo Hu, Huaimo Chen, Junda Yao, Chris
Bowers, Yongqing Zhu, Yisong Liu, 2022-09-04,
<draft-hc-lsr-sr-proxy-fw-01.txt>

This document describes extensions to OSPF and IS-IS to support SR

proxy forwarding mechanism for fast protecting the failure of a node
with segments on a SR-TE path. The segments of the node include
adjacency, node or binding segments.

"IS-IS Traffic Engineering (TE) Metric LAN Extensions", Chenxi Li, Guoqi
Xu, Zhibo Hu, 2022-03-06,
<draft-li-lsr-isis-te-metric-lan-extensions-00.txt>

In certain networks, network-performance criteria (e.g., latency) are

becoming as critical to data-path selection as other metrics. This
document describes extensions to IS-IS Traffic Engineering (TE)
Metric Extensions (RFC 8570) for LAN subnetworks. These extensions
provide a way to distribute and collect network-performance
information in LAN subnetworks.

"Intent-based Routing", Zhenbin Li, Zhibo Hu, Jie Dong, Shuai Zhang, Li
Jianfei, 2022-03-06, <draft-li-apn-intent-based-routing-00.txt>

This document defines the intent-based routing mechanism through

which the packet can carry the intent information and the network
node can enforce the policy according to the intent information
(typically steering the packet into the SR policy or the underlay
slice which can meet the intent). The intent-based routing mechanism
provides a simple and scalable solution to meet the different service
requirements for the inter-domain routing.

"Oblivious Relay Feedback", Tirumaleswar Reddy.K, Dan Wing, Mohamed

Boucadair, Roberto Polli, 2022-07-10,
<draft-rdb-ohai-feedback-to-proxy-04.txt>

To provide equitable service to clients, servers often rate-limit

incoming requests, for example, based upon the source IP address.
However, oblivious HTTP removes the ability for the server to
distinguish amongst clients so the server can only rate-limit traffic
from the oblivious relay. This harms all clients behind that
oblivious relay.

This specification enables a server to convey rate-limit information

to an oblivious relay, which can use it to apply rate-limit policies
on clients. Cooperating oblivious relays can thus provide more
equitable service to their distinguishable clients without impacting
on all clients behind that oblivious relay.

"Network Programming Interface for Provisioning of Underlay Services to

Overlay Networks Using SRv6", Jingrong Xie, 2022-03-06,
<draft-xie-spring-srv6-npi-for-overlay-00.txt>

This document describes a framework and a detailed suite of network

programming interface (NPI) examples for provisioning of underlay
services to overlay networks. It provides background by reviewing
the growing pains that commonly faced today by enterprise for its
flexiable WAN sites connection. It assumes that WAN connection
services are and will continue to be provided by multiple underlay
networks operated by different administrative entities. Based on the
pains and the assumptions, this document propose to use SRv6 binding
SIDs (BSIDs) on a transport network (TN) edge router as NPI for
 service provisioning to be accessed remotely and securely by a
customer router that constitutes to a higher overlay network,
including the requirements of such service, the illustration of how
it may work, and the possible applicability of the solution.

"Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical
Networks", Sheng Liu, Haomian Zheng, Aihua Guo, Yang Zhao, 2022-07-11,
<draft-liu-ccamp-optical2cloud-problem-statement-02.txt>

Many applications, including optical leased line, cloud VR and

computing cloud, benefit from the network scenario where the data
traffic to cloud data centers (DCs) is carried end-to-end over an
optical network. This document describes the problem statement and
requirements for connecting to cloud DCs over optical networks, and
presents a gap analysis for existing control plane protocols for
supporting this network scenario.

"Multicast Tree Setup via PCEP", Huanan Li, Aijun Wang, Zhaohui Zhang,
Huaimo Chen, Ran Chen, 2022-03-20, <draft-li-pce-multicast-01.txt>

Multicast forwarding requires per-tree state on certain nodes. Even

with BIER, per-tree state is needed on ingress/egress BIER routers
(though not needed on transit BIER routers). This documents
specifies PCEP protocol to collect tree information (e.g. root, leaf,
constraints) to allow a PCE to calculate a tree, and the procedures
to set up per-tree forwarding state on relevant nodes for various
multicast trees and various replication technologies.

"BMP YANG Module", Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit
Claise, 2022-07-09, <draft-cptb-grow-bmp-yang-03.txt>

This document proposes a YANG module for BMP (BGP Monitoring

Protocol) configuration and monitoring. A complementary RPC triggers
a refresh of the session of a BMP station.

"RBS(Recursive BitString Structure) for Multicast Source Routing over

IPv6", Bing Xu, Xuesong Geng, Toerless Eckert, 2022-03-30,
<draft-xu-msr6-rbs-01.txt>

This document defines a new type of segment: End.RBS, and the

corresponding packet processing procedures over the IPv6 data plane
for the MSR6(Multicast Source Routing over IPv6) TE solutions.

"Observations about EAP-NOOB (RFC 9140)", Jan-Frederik Rieckers,

2022-03-07, <draft-rieckers-emu-eap-noob-observations-00.txt>

This memo is a random list of things the author noticed about EAP-
NOOB when looking at the draft and running the implementation while
capturing the packets (https://github.com/Vogeltak/hostap).

Most of the statements were written down before the author started
the implementation. By the time of writing this draft, a mostly
complete server implementation has been written. The implementation-
specific remarks are mostly thoughts the author had while planning
their own implementation.

"User-assisted Trust Establishment (EAP-UTE)", Jan-Frederik Rieckers,

2022-03-07, <draft-rieckers-emu-eap-ute-00.txt>
 The Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the EAP-UTE
authentication method for a User-assisted Trust Establishment between
the peer and the server. The EAP method is intended for
bootstrapping Internet-of-Things (IoT) devices without preconfigured
authentication credentials. The trust establishment is achieved by
transmitting a one-directional out-of-band (OOB) message between the
peer and the server to authenticate the in-band exchange. The peer
must have a secondary input or output interface, such as a display,
camera, microphone, speaker, blinking light, or light sensor, so that
dynamically generated messages with tens of bytes in length can be
transmitted or received.

"Application of FlexE Configuration Model", Minxue Wang, Liuyan Han,

Xiaobing NIU, Qilei Wang, 2022-03-07,
<draft-xiaobn-ccamp-application-flexe-cm-00.txt>

This document gives some application of FlexE configuration model,

including the configuration of the FlexE group and the FlexE client.
It is useful for the deployment of FlexE configuration model in
related network devices.

"Considerations of deploying AI services in a distributed approach",

Yong-Geun Hong, Joo-Sang Youn, Hyun-Kook Kahng, 2022-07-11,
<draft-hong-nmrg-ai-deploy-01.txt>

As the development of AI technology matured and AI technology began

to be applied in various fields, AI technology is changed from
running only on very high-performance servers with small hardware,
including microcontrollers, low-performance CPUs and AI chipsets. In
this document, we consider how to configure the system in terms of AI
inference service to provide AI service in a distributed approach.
Also, we describe the points to be considered in the environment
where a client connects to a cloud server and an edge device and
requests an AI service.

"OSPF Monitor Node", Alvaro Retana, Lin Han, 2022-03-07,

<draft-retana-lsr-ospf-monitor-node-00.txt>

This document specifies mechanisms that allow a node to monitor an

OSPF network actively without influencing the topology or affecting
its stability.

"Integer value for the CBOR Object Signing and Encryption (COSE) key
identifier", Goeran Selander, John Mattsson, 2022-03-21,
<draft-selander-cose-kid-int-01.txt>

This document extends the CBOR Object Signing and Encryption (COSE)
parameter kid to CBOR integer values.

"BGP Flowspec Redirect Load Balancing Group Community", Wu Zhiwen, Haibo

Wang, Lili Wang, Zhen Tan, 2022-03-07,
<draft-wu-idr-flowspec-redirect-group-00.txt>

This document defines an extension to "BGP Community Container

Attribute" [I-D.ietf-idr-wide-bgp-communities] , which allows
flowspec redirection to multiple paths. This extended community
serves to redirect traffic to a load balancing group and supports
both equal-cost multi-path(ECMP) and unequal-cost multi-path(UCMP)
 scenarios.

"Anycast Affiliation Advertisement", Zhaohui Zhang, 2022-03-07,

<draft-zzhang-lsr-anycast-affiliation-00.txt>

This document specifies the advertisement of addresses affiliated

with an anycast address in ISIS/OSPF/BGP, and describes one example
use of such advertisement in VxLAN interconnect with EVPN.

"HTTP Connection Reuse Based on TLS Encrypted ClientHello", Christopher

Wood, 2022-03-07, <draft-wood-httpbis-ech-coalescing-00.txt>

This document specifies new criteria under which HTTP/2 clients may
reuse connections. It updates [RFC7540].

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/chris-wood/draft-wood-httpbis-ech-coalescing.

"NVMe over Fabric Network Requirement", Liang Guo, Yi Feng, Jizhuang Zhao,
Lily Zhao, Haibo Wang, 2022-03-07, <draft-nof-requirement-00.txt>

NVMe over Fabrics defines a common architecture that supports a range

of storage networking fabrics for NVMe block storage protocol over a
storage networking fabric, such as Ethernet, Fibre Channel and
InfiniBand. For Ethernet-based network, RDMA or TCP technology can
be used to transport NVMe, but the network management mechanism is
simple, and fault detection is weak.

This document describes the solution requirements for automatic

device discovery to improve usability and quick switchover to improve
reliability.

"NVMe over Fabric Network Framework", Haibo Wang, Lily Zhao, Shuanglong
Chen, 2022-03-07, <draft-nof-framework-00.txt>

NVMe over Fabrics defines a common architecture that supports a range

of storage networking fabrics for NVMe block storage protocol over a
storage networking fabric, such as Ethernet, Fibre Channel and
InfiniBand. For Ethernet-based networks, RDMA or TCP technology can
be used to transport NVMe, but the network management mechanism is
simple, and fault detection is weak.

This document defines the architecture of the Ethernet-based NVMe

control optimization technology, including service processes between
hosts, storage devices and network switches, and fast fault-aware
switchover.

"Requirement of Fast Fault Detection for IP-based SANs", Liang Guo, Yi

Feng, Jizhuang Zhao, Fengwei Qin, Lily Zhao, Haibo Wang, 2022-07-11,
<draft-guo-nof-requirement-01.txt>

NVMe over Fabrics defines a common architecture that supports a range

of storage networking fabrics for NVMe block storage protocol over a
storage networking fabric, such as Ethernet, Fibre Channel and
InfiniBand. For IP-based network, RDMA or TCP technology can be used
 to transport NVMe, but the network fault detection is weak.

This document describes the solution requirements for fast fault

detection to improve reliability.

"Framework of Fast Fault Detection for IP-baesd SANs", Haibo Wang, Fengwei
Qin, Lily Zhao, Shuanglong Chen, 2022-07-11,
<draft-wang-nof-framework-01.txt>

NVMe over Fabrics defines a common architecture that supports a range

of storage networking fabrics for NVMe block storage protocol over a
storage networking fabric, such as Ethernet, Fibre Channel and
InfiniBand. For IP-based network, RDMA or TCP technology can be used
to transport NVMe commands. When a network fault occurs, NVMe
connections need to be switched over. Currently, no effective method
is available for quick detection, switchover is performed only based
on KA timeout, resulting in low performance.

This document defines the basic framework of how network-assisted

hosts and storage devices can quickly detect NVMe connection failures
caused by network faults for NVMe IP-based SANs.

"IPv4 routes with an IPv6 next hop", Juliusz Chroboczek, Warren Kumari,
Toke Hoeiland-Joergensen, 2022-03-07,
<draft-chroboczek-int-v4-via-v6-01.txt>

We propose "v4-via-v6" routing, a technique that uses IPv6 next-hop

addresses for routing IPv4 packets, thus making it possible to route
IPv4 packets across a network where routers have not been assigned
IPv4 addresses. We describe the technique, and discuss its
operational implications.

"ASPA Verification in the Presence of Regionalized AS-Relationships", Chen

Shen, Shicong Zhang, Tianran Zhou, Shunwan Zhuang, Shuanglong Chen, Haibo
Wang, 2022-08-15, <draft-shen-sidrops-regionalized-as-relationships-02.txt>

This document proposes a method for ASPA verification in the Presence

of Regionalized AS-Relationships.

"Registering Self-generated IPv6 Addresses using DHCPv6", Warren Kumari,

Suresh Krishnan, Sheng Jiang, Rajiv Asati, Lorenzo Colitti, 2022-07-28,
<draft-wkumari-dhc-addr-notification-02.txt>

This document defines a method to inform a DHCPv6 server that a

device has a self-generated or statically configured address.

"A YANG Data Model for Network Hardware Inventory", Chaode Yu, Italo Busi,
Aihua Guo, Sergio Belotti, Jean-Francois Bouquier, Fabio Peruzzini, Oscar
de Dios, Victor Lopez, 2022-07-11,
<draft-yg3bp-ccamp-network-inventory-yang-01.txt>

This document defines a YANG data model for network hardware

inventory data information.

The YANG data model presented in this document is intended to be used

as the basis toward a generic YANG data model for network hardware
inventory data information which can be augmented, when required,
with technology-specific (e.g., optical) inventory data, to be
defined either in a future version of this document or in another
 document.

The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"PCEP extensions for Circuit Style Policies", Samuel Sidor, Zafar Ali,
Praveen Maheshwari, Reza Rokui, Andrew Stone, Luay Jalil, Shuping Peng,
Tarek Saad, Dan Voyer, 2022-07-06,
<draft-sidor-pce-circuit-style-pcep-extensions-02.txt>

This document proposes a set of extensions for Path Computation

Element Communication Protocol (PCEP) for Circuit Style Policies -
Segment-Routing Policy designed to satisfy requirements for
connection-oriented transport services. New TLV is introduced to
control path recomputation and new flag to add ability to request
path with strict hops only.

"Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6",
Acee Lindem, Aditya Dogra, 2022-07-09,
<draft-addogra-rtgwg-vrrp-rfc5798bis-12.txt>

This document defines the Virtual Router Redundancy Protocol (VRRP)

for IPv4 and IPv6. It is version three (3) of the protocol, and it
is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and
in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an
election protocol that dynamically assigns responsibility for a
virtual router to one of the VRRP routers on a LAN. The VRRP router
controlling the IPv4 or IPv6 address(es) associated with a virtual
router is called the VRRP Active Router, and it forwards packets sent
to these IPv4 or IPv6 addresses. VRRP Active Routers are configured
with virtual IPv4 or IPv6 addresses, and VRRP Backup Routers infer
the address family of the virtual addresses being carried based on
the transport protocol. Within a VRRP router, the virtual routers in
each of the IPv4 and IPv6 address families are a domain unto
themselves and do not overlap. The election process provides dynamic
failover in the forwarding responsibility should the Active Router
become unavailable. For IPv4, the advantage gained from using VRRP
is a higher-availability default path without requiring configuration
of dynamic routing or router discovery protocols on every end-host.
For IPv6, the advantage gained from using VRRP for IPv6 is a quicker
switchover to Backup Routers than can be obtained with standard IPv6
Neighbor Discovery mechanisms.

The VRRP terminology has been updated conform to inclusive language

guidelines for IETF technologies. The IETF has designated National
Institute of Standards and Technology (NIST) "Guidance for NIST Staff
on Using Inclusive Language in Documentary Standards" for its
inclusive language guidelines. This document obsoletes VRRP Version
3 [RFC5798].

"Expressing Quality of Service Requirements (QoS) in Domain Name System

(DNS) Queries", Donald Eastlake, Haoyu Song, 2022-08-23,
<draft-eastlake-dnsop-expressing-qos-requirements-01.txt>

A method of encoding communication service quality requirements in a

Domain Name System (DNS) query is specified through inclusion of the
requirements in one or more label of the name being queried. This
enables DNS responses that are dependent on such requirements without
changes in the format of DNS protocol messages or DNS application
 program interfaces (APIs).

"IGP extensions for Advertising Offset for Flex-Algorithm", Louis Chan,

Krzysztof Szarkowicz, 2022-03-07, <draft-chan-lsr-igp-adv-offset-00.txt>

This document describes the IGP extensions to provide predictable

Adjacency-SIDs
per Flex-Algorithm [FLEXALGO] in segment routing.

We propose some methods to allow the advertisement of additional TLV in

IGP so that
the Flex-Algorithm specific Adjacency-SIDs could be
automatically derived.

With the proposed method, the size of advertisement on per node per link
basis is
greatly reduced. Each participating router would derive the
required labels
automatically.

Extensions for offset to derive Flex-Algorithm Prefix-SID is also

included in the
document.

"RAW multidomain extensions", Carlos Bernardos, Alain Mourad, 2022-03-07,

<draft-bernardos-raw-multidomain-00.txt>

This document describes the multi-domain RAW problem and explores and
proposes some extensions to enable RAW multi-domain operation.

"5G Distributed UPFs for 5G Multicast and Broadcast Services (5MBS)",

Tianji Jiang, 2022-03-07, <draft-tjiang-dmm-5g-dupf-5mbs-00.txt>

The companion draft [I-D.zzhang-dmm-5g-distributed-upf] has described

the 5G mobile user plane (MUP) via the refinement of distributed
UPFs, along with various user plane implementations that some vendors
and operators are exploring, with the requirement of not introducing
changes to 3GPP architecture & signaling. The document 3GPP TS
23.247 [_3GPP-23.247] for 5G multicast and broadcast services, or
5MBS, specifies the 5GS architecture to support MBS communication.
Thanks to the addition of new 5GS network functions (NFs) and MB-
interfaces on 5G CP & UP, this might post additional provisioning &
implementation challenges to the underlay transport infrastructure.

This document is not an attempt to do 3GPP SDO work in IETF.

Instead, it discusses how to potentially integrate distributed UPFs
with the delivery of 5MBS communication, as well as the benefits of
using distributed UPFs to handle 5MBS traffic delivery.

"STAR: Distributed Secret Sharing for Private Threshold Aggregation

Reporting", Alex Davidson, Shivan Sahib, Peter Snyder, 2022-07-11,
<draft-dss-star-01.txt>

Servers often need to collect data from clients that can be privacy-
sensitive if the server is able to associate the collected data with
a particular user. In this document we describe STAR, an efficient
and secure threshold aggregation protocol for collecting measurements
from clients by an untrusted aggregation server, while maintaining
K-anonymity guarantees.
"Supporting Bottleneck Structure Graphs in ALTO: Use Cases and
Requirements", Jordi Ros-Giralt, Sruthi Yellamraju, Qin WU, Luis Contreras,
Y. Yang, Kai Gao, 2022-03-23,
<draft-giraltyellamraju-alto-bsg-requirements-01.txt>

This document proposes an extension to the base Application-Layer

Traffic Optimization (ALTO) protocol to support bottleneck structures
as an efficient representation of the state of a network. Bottleneck
structures are efficient computational graphs that allow network
operators and application service providers to optimize application
performance in a variety of communication problems including routing,
flow control, flow scheduling, bandwidth prediction, and network
slicing, among others. This document introduces a new abstraction
called Bottleneck Structure Graph (BSG) and the necessary
requirements to integrate it into the ALTO standard.

"YANG Data Model for Network Resource Partition Policy", Tarek Saad, Vishnu
Beeram, Bin Wen, Daniele Ceccarelli, Shaofu Peng, Ran Chen, Luis Contreras,
Xufeng Liu, 2022-07-24, <draft-bestbar-teas-yang-nrp-policy-02.txt>

A Network Resource Partition (NRP) is a collection of resources

identified in the underlay network to support services (like IETF
Network Slices) that need logical network structures with required
characteristics to be created. An NRP policy is a policy construct
that enables instantiation of mechanisms in support of service
specific control and data plane behaviors on select topological
elements associated with the NRP. This document defines a YANG data
model for the management of NRP policies on NRP capable nodes and
controllers in IP/MPLS networks.

"Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet
X.509 Public Key Infrastructure", Sean Turner, Panos Kampanakis, Jake
Massimo, Bas Westerbaan, 2022-03-07,
<draft-turner-lamps-nist-pqc-kem-certificates-01.txt>

This document specifies algorithm identifiers and ASN.1 encoding

format for the US NIST's PQC KEM (United States National Institute of
Standards and Technology's Post Quantum Cryptography Key
Encapsulation Mechanism) algorithms. The algorithms covered are
Candidate TBD1. The encoding for public key and private key is also
provided.

[EDNOTE: This draft is not expected to be finalized before the NIST

PQC Project has standardized PQ algorithms. After NIST has
standardized its first algorithms, this document will replace TBD,
with the appropriate algorithms and parameters before proceeding to
ratification. The algorithm Candidate TBD1 has been added as an
example in this draft, to provide a more detailed illustration of the
content - it by no means indicates its inclusion in the final
version. This specification will use object identifiers for the new
algorithms that are assigned by NIST, and will use placeholders until
these are released.]

"Encrypted Client Hello Deployment Considerations", Andrew Campling, Paul

Vixie, David Wright, 2022-03-07,
<draft-campling-ech-deployment-considerations-01.txt>

This document is intended to inform the development of the proposed

 Encrypted Client Hello (ECH) standard that encrypts Server Name
Indication (SNI) and other data. Data encapsulated by ECH (ie data
included in the encrypted ClientHelloInner) is of legitimate interest
to on-path security actors including anti-virus software, parental
controls and consumer and enterprise firewalls.

The document includes observations on current use cases for SNI data
in a variety of contexts. It highlights how the use of that data is
important to the operators of private networks and shows how the loss
of access to SNI data will cause difficulties in the provision of a
range of services to many millions of end-users.

"Ethernet VPN Virtual Private Wire Services Gateway Solution", Jorge

Rabadan, Senthil Sathappan, Vinod Prabhu, Wen Lin, Patrice Brissette,
2022-03-07, <draft-sr-bess-evpn-vpws-gateway-00.txt>

Ethernet VPN Virtual Private Wire Services (EVPN VPWS) need to be

deployed in high scale multi-domain networks, where each domain can
use a different transport technology, such as MPLS, VXLAN or Segment
Routing with MPLS or IPv6 Segment Identifiers (SIDs). While the
transport interworking solutions on border routers spare the border
routers from having to process service routes, they do not always
meet the multi-homing, redundancy, and operational requirements, or
provide the isolation that each domain requires. This document
analyzes the scenarios in which an interconnect solution for EVPN
VPWS using EVPN Domain Gateways is needed, and adds the required
extensions to support it.

"Regional Internet Blocking Considerations", Lenny Giuliano, Melchior

Aelmans, Tony Li, 2022-03-07,
<draft-giuliano-blocking-considerations-00.txt>

Geopolitical conflicts can cause policy makers to question whether or

not blocking the Internet connectivity for an opposing region is a
constructive tactic. This document provides an overview of the
various technologies that can be used to implement regional blocking
of Internet connectivity and discusses the implications of these
options. This document does not advocate any policy or given
blocking mechanism, but does attempt to articulate the implications
of these blocking technologies for policy makers. The document also
intends to help inform policy makers from countries who could be
exposed to such blocking techniques on the implications of these
methods.

"BGP Signaling for Mobile User Plane", Zhaohui Zhang, Keyur Patel, Satoru
Matsushima, 2022-03-07, <draft-zpm-dmm-mup-bgp-signaling-00.txt>

This document specifies BGP signaling for router-based 5G User Plane

using Mobile User Plane SAFI and some of its route types as specified
in [draft-mpmz-idr-mup-safi].

"Resource Public Key Infrastructure (RPKI) object profile for Discard

Origin Authorizations (DOA)", Job Snijders, Mikael Abrahamsson, Ben
Maddison, 2022-03-07, <draft-spaghetti-sidrops-rpki-doa-00.txt>

This document defines a Cryptographic Message Syntax (CMS) profile

for Discard Origin Authorizations (DOAs), for use with the Resource
Public Key Infrastructure (RPKI). A DOA is a digitally signed object
that provides a means of verifying that an IP address block holder
 has authorized an Autonomous System (AS) to originate routes to one
or more prefixes within the address block tagged with a specific set
of Border Gateway Protocol (BGP) Communities, to signal a request to
discard IP traffic destined towards the tagged IP prefix.

"BGP Extensions for the Mobile User Plane (MUP) SAFI", Tetsuya Murakami,
Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, 2022-03-07,
<draft-mpmz-bess-mup-safi-00.txt>

This document defines a new SAFI known as a BGP Mobile User Plane
(BGP-MUP) SAFI to support MUP Extensions and a extended community for
BGP. This document also provides BGP signaling and procedures for
the new SAFI to convert mobile session information into appropriate
IP forwarding information. These extensions can be used by operators
between MUP PE, MUP GW and MUP Controller for integrating mobile user
plane into BGP MUP network using the IP based routing.

"Connecting 3GPP slices through IETF Network Slice services", Luis

Contreras, Ivan Bykov, Jose Ordonez-Lucena, 2022-03-07,
<draft-contreras-teas-3gpp-ietf-slice-mapping-00.txt>

3GPP is introducing the concept of slicing as a primary way of

service delivery. Slicing at 3GPP implies the differentiation of
services in terms of performance expectations as well as the
connection of different network entities also potentially
differentiated per slice. With that aim, 3GPP is defining a number
of logical constructs with the intent of being served with specific
characteristics, determined by different QoS profiles. This document
describes the connectivity of 3GPP slices through IETF Network Slice
services taking into account that specific service level objectives,
and identifies gaps existing nowadays on both 3GPP and IETF
specifications for an straightforward mapping of parameters between
both environments.

"A YANG Data Model for Open Source Path First (OSPF) Topology", Oscar de
Dios, Samier Barguil, Victor Lopez, 2022-03-07,
<draft-ogondio-opsawg-ospf-topology-00.txt>

This document defines a YANG data model for representing an abstract

view of the provider network topology that contains Open Source Path
First (OSPF) information. This document augments the 'ietf-network'
data model by adding OSPF concepts.

The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"Routing and Addressing Challenges Introduced by New Satellite

Constellations", Daniel King, Ning Wang, 2022-03-07,
<draft-kw-rtgwg-satellite-rtg-add-challanges-00.txt>

Future networks, including the Internet, will utilize an increasing

amount of space-based transport infrastructure. Control and
transport between Earth-based and space-based networks present
several problems - high dynamicity, spatial connectivity, continual
movement tracking and prediction, ocular obstruction, integration
with existing Internet infrastructure, all of which challenge
existing architectures, routing mechanisms and addressing schemes.

This document summerises near-to-mid-term space-networking problems;

 it outlines the key components, challenges, and requirements for
integrating future space-based network infrastructure with existing
networks and mechanisms. Furthermore, this document highlights the
network control and transport interconnection, and identify the
resources and functions required for successful interconnection of
space-based and Earth-based Internet infrastructure.

"Countersigning COSE Envelopes in Transparency Services", Henk Birkholz,

Maik Riechert, Antoine Delignat-Lavaud, Cedric Fournet, 2022-03-07,
<draft-birkholz-scitt-receipts-00.txt>

A transparent and authentic ledger service in support of a supply

chain's integrity, transparency, and trust requires all peers that
contribute to the ledgers operations to be trustworthy and authentic.
In this document, a countersigning variant is specified that enables
trust assertions on merkle-tree based operations for global supply
chain ledgers. A generic procedure how to produce payloads for
signing and validation is defined and leverages solutions and
principles from the Concise Signing and Encryption (COSE) space.

"HPCC++: Enhanced High Precision Congestion Control", Rui Miao, Hongqiang

Liu, Rong Pan, Jeongkeun Lee, Changhoon Kim, Barak Gafni, Yuval Shpigelman,
Jeff Tantsura, 2022-03-07, <draft-miao-rtgwg-hpccplus-00.txt>

Congestion control (CC) is the key to achieving ultra-low latency,

high bandwidth and network stability in high-speed networks.
However, the existing high-speed CC schemes have inherent limitations
for reaching these goals.

In this document, we describe HPCC++ (High Precision Congestion

Control), a new high-speed CC mechanism which achieves the three
goals simultaneously. HPCC++ leverages inband telemetry to obtain
precise link load information and controls traffic precisely. By
addressing challenges such as delayed signaling during congestion and
overreaction to the congestion signaling using inband and granular
telemetry, HPCC++ can quickly converge to utilize all the available
bandwidth while avoiding congestion, and can maintain near-zero in-
network queues for ultra-low latency. HPCC++ is also fair and easy
to deploy in hardware, implementable with commodity NICs and
switches.

"An Architecture for Trustworthy and Transparent Digital Supply Chains",

Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, 2022-03-07,
<draft-birkholz-scitt-architecture-00.txt>

Traceability of physical and digital artifacts in supply chains is a

long-standing, but increasingly serious security concern. The rise
in popularity of verifiable data structures as a mechanism to make
actors more accountable for breaching their compliance promises has
found some successful applications to specific use cases (such as the
supply chain for digital certificates), but lacks a generic and
scalable architecture that can address a wider range of use cases.

This memo defines a generic and scalable architecture to enable

transparency across any supply chain with minimum adoption barriers
for producers (who can register their claims on any TS, with the
guarantee that all consumers will be able to verify them) and enough
flexibility to allow different implementations of Transparency
Services with various auditing and compliance requirements.
"The IETF Will Continue Maintaining IPv4", Seth Schoen, John Gilmore, David
Taht, 2022-08-22, <draft-schoen-intarea-ietf-maintaining-ipv4-01.txt>

This document confirms the consensus of the IETF that IETF and its
affiliated working groups will continue to maintain the IPv4 protocol
family.

"IPv6-Only PE Design All SAFI", Gyan Mishra, Mankamana Mishra, Jeff

Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen,
2022-03-07, <draft-mishra-bess-ipv6-all-pe-design-any-safi-00.txt>

As Enterprises and Service Providers upgrade their brown field or

green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-
BGP)now plays an important role in the transition of their Provider
(P) core network as well as Provider Edge (PE) Inter-AS peering
network from IPv4 to IPv6. Operators must be able to continue to
support IPv4 customers when both the Core and Edge networks are
IPv6-Only.

This document details an important External BGP (eBGP) PE-PE Inter-AS

IPv6-Only peering design that leverages the MP-BGP capability
exchange by using IPv6 peering as pure transport, allowing both IPv4
Network Layer Reachability Information (NLRI) and IPv6 Network Layer
Reachability Information (NLRI)to be carried over the same (Border
Gateway Protocol) BGP TCP session for all Address Family Identifiers
(AFI) and Subsequent Address Family Identifiers(SAFI). The design
change provides the same Dual Stacking functionality that exists
today with separate IPv4 and IPv6 BGP sessions as we have today.
With this IPv6-Only PE Design, IPv4 address MUST not be configured on
the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR
(Autonomous System Boundary Router) to ASBR (Autonomous System
Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From
a control plane perspective a single IPv6-Only peer is required for
both IPv4 and IPv6 routing updates and from a data plane forwarindg
perspective an IPv6 address need only be configured on the PE to PE
Inter-AS peering interface for both IPv4 and IPv6 packet forwarding.
This document defines the IPv6-Only PE Design as a new PE-CE and PE-
PE BGP peering Standard which is described in the POC testing
document [I-D.ietf-bess-ipv6-only-pe-design] to all AFI/SAFI
ubiquitously. As service providers migrate to Segment Routing
architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus
Inter-AS options Option-A, Option-AB and Option-C are still
applicable and thus this extension of IPv6-Only peering architecure
extension to Inter-AS peering is very relevant to Segment Routing as
well.

"A Transport Services Mapping for QUIC", Tommy Pauly, 2022-03-19,

<draft-taps-quic-mapping-00.txt>

This document defines a Transport Services API mapping for QUIC

streams.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the QUIC Working Group

mailing list (quic@ietf.org), which is archived at
 https://mailarchive.ietf.org/arch/browse/quic/.

Source for this draft and an issue tracker can be found at

https://github.com/tfpauly/draft-taps-quic-mapping.

"IPv6-Only PE Design All SAFI", Gyan Mishra, Mankamana Mishra, Jeff

Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen,
2022-03-20, <draft-mishra-bess-ipv6-only-pe-design-all-safi-01.txt>

As Enterprises and Service Providers upgrade their brown field or

green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-
BGP)now plays an important role in the transition of their Provider
(P) core network as well as Provider Edge (PE) Inter-AS peering
network from IPv4 to IPv6. Operators must be able to continue to
support IPv4 customers when both the Core and Edge networks are
IPv6-Only.

This document details an important External BGP (eBGP) PE-PE Inter-AS

IPv6-Only peering design that leverages the MP-BGP capability
exchange by using IPv6 peering as pure transport, allowing all and
any IPv4 Network Layer Reachability Information (NLRI) and IPv6
Network Layer Reachability Information (NLRI)to be carried over the
same (Border Gateway Protocol) BGP TCP session for all Address Family
Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI).
The design change provides the same Dual Stacking functionality that
exists today with separate IPv4 and IPv6 BGP sessions as we have
today. With this IPv6-Only PE Design, IPv4 address MUST not be
configured on the the Provider Edge (PE) - Customer Edge (CE), or
Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous
System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge
(PE). From a control plane perspective a single IPv6-Only peer is
required for both IPv4 and IPv6 routing updates and from a data plane
forwarindg perspective an IPv6 address need only be configured on the
PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet
forwarding. This document defines the IPv6-Only PE Design as a new
PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is
described in the POC testing document
[I-D.ietf-bess-ipv6-only-pe-design] which is now extended to support
to all AFI/SAFI ubiquitously. As service providers migrate to
Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as
well, and thus Inter-AS options Option-A, Option-B, Option-AB and
Option-C are still applicable and thus this extension of IPv6-Only
peering architecure extension to Inter-AS peering is very relevant to
Segment Routing as well.

"Topology Identifier in IPv6 Extension Header", Zhenbin Li, Zhibo Hu, Jie
Dong, 2022-03-20, <draft-li-6man-topology-id-00.txt>

This document proposes a new Hop-by-Hop option of IPv6 extension

header to carry the topology identifier, which is used to identify
the forwarding table instance created by the Multi Topology Routing
or Flexible Algorithm.

"More Private Algorithms for DNSSEC", Paul Hoffman, 2022-03-24,

<draft-hoffman-more-private-algs-01.txt>

RFC 4034 allocates one value in the IANA registry for DNSSEC
algorithm numbers for private algorithms. That may be too few for
experimentation where multiple yet-to-be-assigned algorithms are
 used. This document assigns seven more values for this use case.

This document is currently maintained at

https://github.com/paulehoffman/draft-hoffman-more-private-algs.
Issues and pull requests are welcomed. If the document is later
adopted by a working group, a new repository will likely be created.

"Problem Statement and Use Cases of Adaptive Traffic Data Collection",

Xiaoming He, Dongfeng Mao, Qiufang Ma, Tianran Zhou, 2022-03-20,
<draft-he-netconf-adaptive-collection-usecases-00.txt>

IP carrier network needs to provide real-time traffic visibility to

help network operators quickly and accurately locate network
congestion and packet loss, and make timely path adjustment for
deterministic services in order to avoid congestion. It is essential
to explore the adaptive traffic data collection mechanism so as to
capture real-time network state at minimum resource consumption.

This document summarizes the problems currently faced by network

operators when attempting to provide timely traffic data collection
to satisfy the various scenarios that require real-time network state
and traffic visibility, and aggregates the requirements for adaptive
traffic collecting mechanism from a variety of deployment scenarios.

"IOAM Linkage Solution for the Protection Cases of 5G Bearer Network",

Zhenwen Li, 2022-07-11, <draft-li-ippm-ioam-path-protection-01.txt>

In-band operation and maintenance management (IOAM, In-band OAM), as

a network performance monitoring technology, is based on the
principle of path-associated detection to perform specific field
marking/coloring and identification on actual service flows, and
perform packet loss and delay measurement. It can quickly perceive
network performance-related faults, and accurately delimit boundaries
and do troubleshooting. However, the current IOAM solution has
shortcomings too. For example, after the service traffic path
switching, the IOAM cannot continue working. This paper proposes a
scheme to achieve automatic performance monitoring through service
path switching and linkage with IOAM, which enhances the feasibility
of the IOAM scheme in large-scale deployment and the completeness of
IOAM technology.

"A YANG Model for SRv6 Mobile User Plane", Mahesh Jethanandani, Tetsuya
Murakami, 2022-03-20, <draft-mahesh-bess-srv6-mup-yang-00.txt>

This document defines a YANG data model for configuration and

management of SRv6 for the Mobile User Plane (MUP).

"Centerlized EVPN Prefix Advertisement for Common Prefixes behind Different

CEs", Yubao Wang, 2022-03-21,
<draft-wang-bess-center-rt5-for-common-prefix-00.txt>

In Section 5.8 of [I-D.wang-bess-evpn-arp-nd-synch-without-irb],

centerlized RT-5 advertisement are used for common prefixes behind
different CEs, This draft describes the requirements for such
scenarios. Then this draft reuse the procedures defined in
Section 6.2.2 of [I-D.wz-bess-evpn-vpws-as-vrf-ac] to support this
scenario.

"Can Rules be adapted to a Meshed environment", Ivan Martinez, Laurent

Toutain, 2022-03-21, <draft-martinez-lpwan-meshed-rules-00.txt>

This document specifies how openSCHC handles the rule selection and
how this process can be extended to a meshed environment.

"Protocol extension and mechanism for fused service function chain", David
Dai, Xueshun Wang, Dongping Deng, Xiaoyun Zhang, 2022-03-21,
<draft-dai-sfc-fused-protocol-and-procedure-00.txt>

This document discusses the protocol extension and procedure that are
used to implement the fused service function chain. Fused service
function chain means that two or more service function chains are fused
to become a single service function chain from the view of data plane
and control plane. Fused service function chain is a extension for
service function chain.

"Related Certificates for Use in Multiple Authentications within a

Protocol", Alison Becker, Rebecca Guthrie, Michael Jenkins, 2022-06-29,
<draft-becker-guthrie-cert-binding-for-multi-auth-01.txt>

This document defines a new CSR attribute, relatedCertRequest, and a

new X.509 certificate extension, RelatedCertificate. The use of the
relatedCertRequest attribute in a CSR and the inclusion of the
RelatedCertificate extension in the resulting certificate together
provide additional assurance that two certificates each belong to the
same end entity. This mechanism is particularly useful in the
context of non-composite hybrid authentication, which enables users
to employ the same certificates in hybrid authentication as in
authentication done with only traditional or post-quantum algorithms.

"The Architecture of Network-Aware Domain Name System (DNS)", Haoyu Song,

Donald Eastlake, 2022-03-21, <draft-song-network-aware-dns-00.txt>

A simple method of enhancing Domain Name System (DNS) with network

awareness is discussed. This enables DNS system responses that are
dependent on communication service requirements such as QoS or path
without changes in the format of DNS protocol messages or application
program interfaces (APIs). The different enhancement methods and use
cases are discussed.

"Non-Composite Hybrid Authentication in PKIX and Applications to Internet

Protocols", Alison Becker, Rebecca Guthrie, Michael Jenkins, 2022-03-22,
<draft-becker-guthrie-noncomposite-hybrid-auth-00.txt>

The advent of cryptographically relevant quantum computers (CRQC)

will threaten the public key cryptography that is currently in use in
today's secure internet protocol infrastructure. To address this,
organizations such as the National Institute of Standards and
Technology (NIST) will standardize new post-quantum cryptography
(PQC) that is resistant to attacks by both classical and quantum
computers. After PQC algorithms are standardized, the widespread
implementation of this cryptography will be contingent upon adapting
current protocols to accommodate PQC. Hybrid solutions are one way
to facilitate the transition between traditional and PQ algorithms:
they use both a traditional and a PQ algorithm in order to perform
encryption or authentication, with the guarantee that the given
security property will still hold in the case that one algorithm
fails. Hybrid solutions can be constructed in many ways, and the
cryptographic community has already begun to explore this space.
 This document introduces non-composite hybrid authentication, which
requires updates at the protocol level and limits impact to the
certificate-issuing infrastructure.

"Recommendations for Creating IANA-Maintained YANG Modules", Mohamed

Boucadair, 2022-03-29, <draft-boucadair-netmod-iana-registries-03.txt>

This document provides a set of guidelines for YANG module authors

related to the design of IANA-maintained modules. These guidelines
are meant to leverage existing IANA registries and use YANG as
another format to present the content of these registriesn when
appropriate.

This document updates RFC 8407 by providing additional guidelines for

IANA-maintained modules. It does not change anything written in RFC
8407.

"Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using
Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, Gonzalo
Salgueiro, 2022-03-24, <draft-petithuguenin-tsvwg-stun-pmtud-00.txt>

The datagram exchanged between two Internet endpoints have to go

through a series of physical and virtual links that may have
different limits on the upper size of the datagram they can transmit
without fragmentation. Because fragmentation is considered harmful,
most transports and protocols are designed with a mechanism that
permits dynamic measurement of the maximum size of a datagram. This
mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD).
But the UDP transport and some of the protocols that use UDP were
designed without that feature. The Session Traversal Utilities for
NAT (STUN) Usage described in this document permits retrofitting an
existing UDP-based protocol with such a feature. Similarly, a new
UDP-based protocol could simply reuse the mechanism described in this
document.

"The Standards on a Cloud Intelligence Service Framework and Protocol for

Construction, Deployment,and Publishing of No-Code Scalable Web Software
Platform", Can Yang, Zijian Zhao, Kemin Qu, Guoqiang Han, 2022-03-24,
<draft-yangcan-cloud-intelligence-web-platform-00.txt>

This draft mainly focuses on the scalable architecture and publishing

protocol standard of REST-based SAAS cloud model Web software in non-
programming mode, stipulates the data structure pattern and data
exchange protocol for the construction and release of REST-based
scalable Web cloud service software systems. Using the standardized
framework and protocol, users can easily and quickly design their own
software systems in the cloud, transfer and release data, which may
make conventional software development so ease to improve the
efficiency of complex database construction and server management.
Without having to write codes under the standard framework, users can
get consistent style background to create service, rapidly develop
web application systems with the function of standard data management
and data maintenance, and directly publish the software system to the
end users of the Internet for access and use. And provide RESTful
APIs to facilitate external access to required service resources.
The framework can thus greatly shorten the software development life
cycle, and save a great deal of development cost and maintenance
overhead.
"PCEP Extension for INTERACTING-CAPBILITY", Minxue Wang, Liuyan Han,
Mianzhang Huang, Zhen Han, Jinyou Dai, 2022-03-25,
<draft-whh-pce-capability-advertize-00.txt>

The PCE communication Protocol (PCEP) is used to convey path

computation requests and responses both between Path Computation
Clients (PCCs), Path Computation Elements (PCEs) and cooperating
PCEs, support of traffic engineering in Multiprotocol Label Switching
(MPLS), Generalized MPLS (GMPLS) and Segment Routing (SR) networks.
In PCEP, due to the different implementing of PCC tunnel capability,
especially bidirectional SR tunnels, the PCE can only provides path
computation functions between the PCCs which adopt identical
mechanisms.

With the introduction and evolvement of 5G and other network

scenarios, the scale of bearing and transport network has developed
to a high level. On the other hand, with the improvement of network
slicing ability, network equipments can provide network slicing
service, such as enhanced VPNs (VPN+). Transport network employing
time slot isolation technology, such as FlexE,MTN,can provide
advanced timeslot slicing for the high quality customer services.
The high quality customer services, for example industry production
service, demand for superior SLA and end-to-end timeslot service
slicing, regardless of whether it is across of different network
equipment providers or across of different regions. Therefore, there
is an urgent need of a method to support PCE to provide end-to-end
path computation and establishment of SR tunnels regardless of PCC
enables different protocol selections.

This document specifies the extensions to PCE communication Protocol

(PCEP) to carry bidirectional SR tunnel capability advertisement
information in PCEP message to enhance PCE ability to perceive the
protocol mechanism supported by PCC.

"Hybrid Non-Composite Authentication in IKEv2", Rebecca Guthrie,

2022-03-25, <draft-guthrie-ipsecme-ikev2-hybrid-auth-00.txt>

This document describes how to extend the Internet Key Exchange

Protocol Version 2 (IKEv2) to allow hybrid non-composite
authentication. The intended purpose for this extension is to enable
the use of a Post-Quantum (PQ) digital signature and X.509
certificate in addition to the use of a traditional authentication
method. This document enables peers to signify support for hybrid
non-composite authentication, and send additional CERTREQ, AUTH, and
CERT payloads to perform multiple authentications.

"IGP Unreachable Prefix Announcement", Peter Psenak, Clarence Filsfils,

Stephane Litkowski, Dan Voyer, Amit Dhamija, 2022-03-25,
<draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>

In the presence of summarization, there is a need to signal loss of

reachability to an individual prefix covered by the summary in order
to enable fast convergence away from paths to the node which owns the
prefix which is no longer reachable. This document describes how to
use existing protocol mechanisms in IS-IS and OSPF to advertise such
prefix reachability loss.

"Yet Another Double Address and Translation Technique", Pascal Thubert,

2022-04-11, <draft-thubert-v6ops-yada-yatt-04.txt>
 This document provides a stepwise migration between IPv4 and IPv6
with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only
version, that allows portions of the nodes and of the networks to
remain IPv4, and reduces the need for dual stack and CG NATs between
participating nodes. A first mechanism named YADA to augment the
capacity of the current IPv4 Internet by interconnecting IPv4 realms
via a common footprint called the shaft. YADA extends RFC 1122 with
the support of an IP-in-IP format used to forward the packet between
parallel IPv4 realms. This document also provides a stateless
address and IP header translation between YADA and IPv6 called YATT
and extends RFC 4291 for the YATT format. The YADA and YATT formats
are interchangeable, and the stateless translation can take place as
a bump in the stack at either end, or within the network at any
router. This enables an IPv6-only stack to dialog with an IPv4-only
stack across a network that can be IPv6, IPv4, or mixed. YATT
requires that the IPv6 stack owns a prefix that derives from a YADA
address and that the IPv4 stack in a different realm is capable of
YADA, so it does not replace a generic 4 to 6 translation mechanism
for any v6 to any v4.

"The 'sipTrunkingCapability' Link Relation Type", Kaustubh Inamdar,

Sreekanth Narayanan, Derek Engi, Gonzalo Salgueiro, 2022-07-24,
<draft-engi-siptrunkingcapability-link-01.txt>

This specification defines the 'sipTrunkingCapability' link relation

type that may be used for the retrieval of capabilities and
configuration requirements from Internet Telephony Service Providers
(ITSPs). A Session Initiation Protocol (SIP) trunking capability set
is defined to allow the transfer of technical requirements needed for
seamless peering between SIP-based enterprise telephony networks and
ITSPs where an exchange of parameters and configuration information
is required.

"BGP SR Policy Extensions for Segment List Identifier", Changwang Lin,

Mengxiao Chen, 2022-03-28, <draft-lin-idr-sr-policy-seglist-id-00.txt>

Segment Routing is a source routing paradigm that explicitly

indicates the forwarding path for packets at the ingress node. An SR
Policy is a set of candidate paths, each consisting of one or more
segment lists. This document defines extensions to BGP SR Policy to
specify the identifier of segment list.

"Tracing process in IPv6 VPN Tunneling Networks", Yuanyang Yin, Shuping

Peng, zhaoranxiao, 2022-06-28, <draft-peng-6man-tracing-option-01.txt>

This document specifies the tracing process in IPv6 VPN tunneling

networks for diagnostic purposes. An IPv6 Tracing Option is
specified to collect and carry the required key information in an
effective manner to correctly construct ICMPv4 and ICMPv6 Time
Exceeded messages at the corresponding nodes, i.e. PE and P nodes,
respectively.

"TCP RST Diagnostic Payload", Mohamed Boucadair, Tirumaleswar Reddy.K,

2022-04-19, <draft-boucadair-tcpm-rst-diagnostic-payload-04.txt>

This document specifies a diagnostic payload format to be returned in

TCP RST segments. Such payloads are used to share with the endpoints
the reasons for which a TCP connection has been reset. This is meant
 to ease diagnostic and troubleshooting.

"The IP Geolocation HTTP Client Hint", Tommy Pauly, David Schinazi,

2022-03-30, <draft-pauly-httpbis-geoip-hint-00.txt>

This documents defines an HTTP Client Hint that allows a client to

share information about its IP Geolocation. This helps ensure that
servers have information about location that is consistent with what
a client expects and what other servers use.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/tfpauly/privacy-proxy.

"Content Negotiation for Message Layer Security (MLS)", Rohan Mahy,

2022-03-31, <draft-mahy-mls-content-neg-00.txt>

This document describes a default mechanism for the negotiation of

content inside an MLS group. It defines two new extensions to the
MLS (Messaging Layer Security) Protocol to allow for negotiation of
media types exchanged among members of an MLS group, and a minimal
framing format.

"LISP for Satellite Networks", Dino Farinacci, Victor Moreno, Padma

Pillay-Esnault, 2022-04-01, <draft-farinacci-lisp-satellite-network-00.txt>

This specification describes how the LISP architecture and protocols

can be used over satellite network systems. The LISP overlay runs on
earth using the satellite network system in space as the underlay.

"The Truths of Information Technology", Kyzer Davis, 2022-04-01,

<draft-davis-dispatch-the-truths-of-it-00.txt>

The internet and information technology landscape has changed in many

ways since The Twelve Networking Truths was original published via
[RFC1925] over twenty six years ago. As a result this document
attempts to extend the truths of information technology into the
twenty-first century. This memo does not specify a standard, except
in the sense that all standards MUST implicitly follow the
fundamental truths.

"Performance Measurement (PM) with Alternate Marking Method in Service

Function Chaining (SFC) Network Service Header (NSH) Domain", Greg Mirsky,
Giuseppe Fioccola, Tal Mizrahi, 2022-04-01,
<draft-mfm-ippm-sfc-nsh-pmamm-00.txt>

This document describes how the alternate marking method can be used
as the efficient performance measurement method taking advantage of
the actual data flows in a Service Function Chaining domain using
Network Service Header encapsulation.

"Distributed Routing Object Information Database (DROID)", Tony Li,

2022-04-04, <draft-li-lsr-droid-00.txt>

Over time, the routing protocols have been burdended with the
responsiblity of carrying a variety of information that is not
 directly relevant to their mission. This includes VPN parameters,
configuration information, and capability data. All of the
additional data impacts the performance and stability of the routing
protocols negatively.

This has been convenient since the backbone of a routing protocol is

a small distributed database of routing information. Any service
needing a distributed database has considered injecting its data into
a routing protocol so that it can leverage the protocols database
service. Architecturally, this is a mistake that puts the protocol
at risk from undue complexity and overhead.

To avoid this, DROID is a subsystem that is tangential to, but

independent of the routing protocols, and provides distributed
database services for other routing services. It is based on the
publish-subscribe (pub/sub) architecture and is intentionally crafted
to be an open mechanism for the transport of ancillary data.

"Authentic Chained Data Containers (ACDC)", Samuel Smith, 2022-05-16,

<draft-ssmith-acdc-02.txt>

An authentic chained data container (ACDC) [ACDC_ID][ACDC_WP][VCEnh]

is an IETF [IETF] internet draft focused specification being
incubated at the ToIP (Trust over IP) foundation [TOIP][ACDC_TF]. An
ACDC is a variant of the W3C Verifiable Credential (VC) specification
[W3C_VC]. The W3C VC specification depends on the W3C DID
(Decentralized IDentifier) specification [W3C_DID]. A major use case
for the ACDC specification is to provide GLEIF vLEIs (verifiable
Legal Entity Identifiers) [vLEI][GLEIF_vLEI][GLEIF_KERI]. GLEIF is
the Global Legal Entity Identifier Foundation [GLEIF]. ACDCs are
dependent on a suite of related IETF focused standards associated
with the KERI (Key Event Receipt Infrastructure) [KERI_ID][KERI]
specification. These include CESR [CESR_ID], SAID [SAID_ID], PTEL
[PTEL_ID], CESR-Proof [Proof_ID], IPEX [IPEX_ID], did:keri [DIDK_ID],
and OOBI [OOBI_ID]. Some of the major distinguishing features of
ACDCs include normative support for chaining, use of composable JSON
Schema [JSch][JSchCp], multiple serialization formats, namely, JSON
[JSON][RFC4627], CBOR [CBOR][RFC8949], MGPK [MGPK], and CESR
[CESR_ID], support for Ricardian contracts [RC], support for chain-
link confidentiality [CLC], a well defined security model derived
from KERI [KERI][KERI_ID], _compact_ formats for resource constrained
applications, simple _partial disclosure_ mechanisms and simple
_selective disclosure_ mechanisms. ACDCs provision data using a
synergy of provenance, protection, and performance.

"ACME-Based Provisioning of IoT Devices", Michael Sweet, 2022-08-08,

<draft-sweet-iot-acme-02.txt>

This document extends the Automatic Certificate Management

Environment (ACME) [RFC8555] to provision X.509 certificates for
local Internet of Things (IoT) devices that are accepted by existing
web browsers and other software running on End User client devices.

"Redefining ELI considered harmful; NPL considered harmful", Stewart

Bryant, John Drake, Tony Li, 2022-04-07,
<draft-li-mpls-redefining-eli-00.txt>

Recent work on MPLS Network Actions (MNA) has produced two drafts
that propose to redefine the MPLS Entropy Label Indicator (ELI) for
 use with MNA. [I-D.jags-mpls-ext-hdr] [I-D.gandhi-mpls-ioam] This
work also proposes the use of a Network Programming Label (NPL) as
another option for use with MNA. This document considers both of
these options harmful in the sense of [GOTO].

"HTTP Access Service Description Objects", Benjamin Schwartz, 2022-07-01,

<draft-schwartz-masque-access-descriptions-02.txt>

HTTP proxies can operate several different kinds of access services.

This specification provides a format for identifying a collection of
such services.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

https://datatracker.ietf.org/doc/draft-schwartz-masque-access-
descriptions/.

Source for this draft and an issue tracker can be found at

https://github.com/bemasc/access-services.

"Key Consistency for Oblivious HTTP by Double-Checking", Benjamin Schwartz,

2022-07-01, <draft-schwartz-ohai-consistency-doublecheck-02.txt>

The assurances provided by Oblivious HTTP depend on the client's

ability to verify that it is using the same Gateway, Target, and
KeyConfig as many other users. This specification defines a protocol
to enable this verification.

"SM2 Digital Signature Algorithm for DNSSEC", Cuiling Zhang, Yukun Liu,
Feng Leng, Qi Zhao, Zheng He, 2022-07-26,
<draft-cuiling-dnsop-sm2-alg-01.txt>

This document describes how to specify SM2 Digital Signature

Algorithm keys and signatures in DNS Security (DNSSEC). It lists
the curve and uses SM3 as hash algorithm for signatures.

"IS-IS Extension to Advertise SRv6 SIDs using SID Block", Weiqiang Cheng,
Jiang Wenying, Changwang Lin, Mengxiao Chen, Liyan Gong, 2022-04-08,
<draft-cheng-lsr-isis-srv6-sid-block-00.txt>

This document proposes a simplified method to advertise SRv6 SIDs in

IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs
within the address range of a Locator. When a SID is assigned from
the SID Block, it is described by an index based on the SID Block,
instead of the whole 128-bit IPv6 address.

"Advertising Exclusive Links for Flex-Algorithm in IGP", Liyan Gong,

Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Ran Chen, Yanrong Liang,
2022-08-29, <draft-gong-lsr-exclusive-link-for-flex-algo-03.txt>

This document proposes the method to advertise exclusive links for

Flex-Algorithm in IGP.

"Active Update of DNS Cache", Zhang Xinqing, Wu Shuangli, Yifang Qin, Wei
Wang, Xu Zhou, 2022-07-07, <draft-shuangli-dnsop-update-of-dns-cache-01.txt>
 Under the caching mechanism in [RFC1035], the local DNS server cannot
obtain the update status of the authoritative server in time, this
makes the data inconsistent. Shortening TTL increases server load.
In the passive query of the authoritative server, an active
notification method is added to update the DNS mapping cache of the
local DNS server in order to improve the efficiency of DNS
resolution. Authoritative servers actively send DNS update packets
after updating resource records. This document designs the API for
receiving DNS update packets on the local DNS server.

"The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model

using ALTO", Ziyang Xing, Xiaoqiang Di, Hui Qi, 2022-08-20,
<draft-xing-alto-sdn-controller-aware-mptcp-mpquic-06.txt>

This document aims to study and implement Multipath Transmission

Control Protocol (MPTCP) and Multipath QUIC (MP_QUIC) using
application layer traffic optimization (ALTO) in software defined
network (SDN). In a software-defined network, ALTO server collects
network cost indicators (including link delay, number of paths,
availability, network traffic, bandwidth and packet loss rate etc.),
and the controller extracts MPTCP or MPQUIC packet header to allocate
MPTCP or MPQUIC packet to suitable transmission path according to the
network cost indicators by ALTO, which can reduce the probability of
transmission path congestion and improving path utilization.

"Interface specification for physical layer fingerprint access

authentication framework of IoT devices", Hao Fang, Hua FU, Ling Jin, Yu
Jiang, Aiqun Hu, 2022-04-12,
<draft-hao-physical-layer-fingerprint-interface-00.txt>

This document is for access authentication framework of Internet of

Things (IoT) devices using physical layer fingerprint. This document
specifies the interface functions of the authentication framework.
This document applies to the construction and management of secure
access at the edge of the IoT. This document assumes that the reader
is familiar with the concepts of physical layer fingerprint
technique.

Terminology

"Guidelines for Network Operating System Testing", Yubo Mu, 2022-04-13,

<draft-mu-nos-testing-00.txt>

This document presents a list of tests for implementers of Network

Operating System(NOS) compliant Processes. This document specifies
guidelines for a series of tests that can be run to probe the conformity
and robustness of the NOS implementations. These tests cover several
important functions, in order to gain a level of confidence in the NOS
implementation.

"BGP Flow Specification for Network Resource Partition", Ran Chen, Haisheng
Wu, 2022-04-15, <draft-chen-idr-flowspec-nrp-00.txt>

[RFC8955] defines BGP flow specification version 1 (FSv1) and

[I-D.hares-idr-flowspec-v2] defines BGP flow specification (FSv2)
protocol. This document proposes extensions to BGP Flow
Specification Version 2 to support IETF network slice filtering.

"IANA Considerations for Internet Group Management Protocols", Brian

Haberman, 2022-04-15, <draft-haberman-pim-3228bis-00.txt>

This document specifies revised IANA Considerations for the Internet

Group Management Protocol and the Multicast Listener Discovery
protocol. This document specifies the guidance provided to IANA to
manage values associated with various fields within the protocol
headers of the group management protocols.

This document obsoletes RFC 3228 and updates RFC 4443.

"DetNet Queuing Option for IPv6", Quan Xiong, Aihua Liu, 2022-07-10,
<draft-xiong-detnet-6man-queuing-option-01.txt>

This document introduces new IPv6 options to identify the DetNet

queuing related information for DetNet flows in IPv6 and SRv6
networks.

"SR Policies Extensions for NRP in BGP-LS", Ran Chen, Detao Zhao,
2022-04-22, <draft-chen-idr-bgp-ls-sr-policy-nrp-00.txt>

This document defines a new TLV which enable the headed to report the
configuration and the states of SR policies carrying NRP information
by using BPG-LS.

"Automatic Integration of Secure Silicon (AISS) Attestation Token", Hannes

Tschofenig, Arto Kankaanpaa, Nick Bowler, tushar khandelwal, 2022-04-22,
<draft-tschofenig-rats-aiss-token-00.txt>

This specification defines a profile of the Entity Attestation Token

(EAT) for use in special System-on-Chip (SoC) designs that are
generated automatically utilizing a methodology currently developed
in a DARPA funded project.

"Framework of MPLS Reference Augmented Forwarding", Robert Raszuk,

2022-04-25, <draft-raszuk-mpls-raf-fwk-00.txt>

This document specifies an architectural framework for enabling MPLS

based forwarding with optional reference based packet processing in
transit network elements.

"SRv6 Egress Protection in Multi-home scenario", Weiqiang Cheng, Jiang

Wenying, Changwang Lin, Zhibo Hu, Yuanxiang Qiu, 2022-07-08,
<draft-cheng-rtgwg-srv6-multihome-egress-protection-01.txt>

This document describes a SRv6 egress node protection mechanism in

multi-home scenarios.

"Epoch Markers", Henk Birkholz, Thomas Fossati, Wei Pan, Carsten Bormann,
2022-05-04, <draft-birkholz-rats-epoch-markers-01.txt>

Abstract Text

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

https://datatracker.ietf.org/doc/draft-birkholz-rats-epoch-markers/.
 Discussion of this document takes place on the rats Working Group
mailing list (mailto:rats@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/rats/.

Source for this draft and an issue tracker can be found at

https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker.

"BGP Blockchain", Mike McBride, Dirk Trossen, David Guzman, 2022-06-29,

<draft-mcbride-rtgwg-bgp-blockchain-01.txt>

A variety of mechanisms have been developed and deployed over the

years to secure BGP including the more recent RPKI/ROA mechanisms.
Is it also possible to use a distributed ledger such as Blockchain to
secure BGP? BGP provides decentralized connectivity across the
Internet. Blockchain provides decentralized secure transactions in a
append-only, tamper-resistant ledger. This document reviews possible
opportunities of using Blockchain to secure BGP policies within a
domain and across the global Internet.

"DNS message fragments", haisheng yu, Yan Liu, 2022-04-27,

<draft-hsyu-message-fragments-00.txt>

This document describes a method to transmit DNS messages over

multiple UDP datagrams by fragmenting them at the application layer.
The objective is to allow authoriative servers to successfully reply
to DNS queries via UDP using multiple smaller datagrams, where larger
datagrams may not pass through the network successfully.

"Secure Asset Transfer Protocol", Martin Hargreaves, Thomas Hardjono,

Rafael Belchior, 2022-05-02, <draft-hargreaves-sat-core-00.txt>

This memo This memo describes the Secure Asset Transfer (SAT)
Protocol for digital assets. SAT is a protocol operating between two
gateways that conducts the transfer of a digital asset from one
gateway to another. The protocol establishes a secure channel
between the endpoints and implements a 2-phase commit to ensure the
properties of transfer atomicity, consistency, isolation and
durability.

"Out-Of-Band-Introduction (OOBI) Protocol", Samuel Smith, 2022-05-02,

<draft-ssmith-oobi-00.txt>

An Out-Of-Band Introduction (OOBI) provides a discovery mechanism

that associates a given URI or URL with a given AID (Autonomic
IDentifier) or SAID (Self-Addressing IDentifier)
[KERI_ID][KERI][SAID_ID][OOBI_ID]. The URI provided by an OOBI acts
as a service endpoint for the discovery of verifiable information
about the AID or SAID. As such an OOBI itself is not trusted but
must be verified. To clarify, any information obtained from the
service endpoint provided in the OOBI must be verified by some other
mechanism. An OOBI, however, enables any internet and web search
infrastructure to act as an out-of-band infrastructure to discover
information that is verified using an in-band mechanism or protocol.
The primary in-band verification protocol is KERI [KERI_ID][KERI].
The OOBI protocol provides a web-based bootstrap and/or discovery
mechanism for the KERI and the ACDC (Authentic Chained Data
Container) protocols [KERI_ID][ACDC_ID][OOBI_ID]. Thus the security
(or more correctly the lack of security) of an OOBI is out-of-band
with respect to a KERI AID or an ACDC that uses KERI. To clarify,
 everything in KERI or that depends on KERI is end-verifiable,
therefore it has no security dependency nor does it rely on security
guarantees that may or may not be provided by web or internet
infrastructure. OOBIs provide a bootstrap that enables what we call
Percolated Information Discovery (PID) which is based on Invasion
Percolation Theory [IPT][DOMIP][PT][FPP]. This bootstrap may then be
parlayed into a secure mechanism for accepting and updating data.
The principal data acceptance and update policy is denoted BADA
(Best-Available-Data-Acceptance).

"Routers Verses Hosts; Devices Verses Functions", Mark Smith, 2022-08-23,

<draft-smith-ietf-routers-vs-hosts-04.txt>

This memo discusses the differences between routers verses hosts, as

devices verses functions.

"Entropy Values", Tony Li, 2022-05-12, <draft-li-mpls-entropy-01.txt>

Equal Cost Multi-Path (ECMP) forwarding is an essential function in

distributing traffic across parallel paths. Packets within a flow
must be kept on a single path to avoid reordering, while different
flows must be distributed across paths to achieve parallelism.

Previously, MPLS has addressed this through the use of an entropy

label, providing up to 20 bits of entropy that can be added to the
label stack to distinguish different flows. [RFC6790] With the
interest in MPLS Network Actions, there are proposals to embedding
entropy into alternate structures, so it is an appropriate time to
consider how many bits should be used for entropy in the future.
[I-D.bocci-mpls-miad-adi-requirements][I-D.andersson-mpls-mna-fwk]

In this document, we examine the question of how to provide adequate

entropy through a simple stochastic simulation. This is not intended
to be a comprehensive and extensive treatise, but rather a simple
investigation to build intuition into the issues.

"Network-based mobility management in Dyncast network environment",

Jaehwoon Lee, 2022-05-05, <draft-jaehwoon-dmm-dyncast--mobility-00.txt>

Dynamic anycast (Dyncast) network architecture is to choose the best

edge computing server by considering both the network environment and
available computing/storage resources of the edge computing server.
This draft describes the mechanism in which service continuity is
provided even when the client moves and connects to a new ingress
Dyncast anycast Node (DAN) by using the PMIPv6-based mobility
management method in the Dyncast-based edge computing networking
environment.

"YANG Data Model for DetNet Mapping with Network Slice", Xueyan Song,
Haisheng Wu, 2022-05-06, <draft-sw-detnet-network-slice-mapping-yang-00.txt>

This document considers the applicability of Deterministic Networking

(DetNet) mapping with network slice in the context of IP/MPLS
network. It identifies the mapping requirements and YANG data models
being defined by the IETF to support the deployment.

Existing data models are identified for deterministic networking,

this document outlines the applicability of DetNet for network
slicing. It also identifies the features for necessity of mapping
 network slicing with DetNet and indicates where the DetNet YANG might
be extended.

"Dangerous Labels in DNS and E-mail", Daniel Gillmor, 2022-07-27,

<draft-dkg-intarea-dangerous-labels-02.txt>

This document establishes registries that list known security-

sensitive labels in the DNS and in e-mail contexts.

It provides references and brief explanations about the risks

associated with each known label.

The registries established here offer guidance to the security-minded

system administrator, who may not want to permit registration of
these labels by untrusted users.

"Updates to the Cipher Suites in Secure Syslog", Chris Lonvick, Sean

Turner, Joseph Salowey, 2022-05-09,
<draft-uta-ciphersuites-in-sec-syslog-00.txt>

This document updates the cipher suites in RFC 5425, Transport Layer
Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram
Transport Layer Security (DTLS) Transport Mapping for Syslog. It
also updates the transport protocol in RFC 6012.

"Automated Certificate Management Environment (ACME) Onion Identifier

Validation Extension", Seo Suchan, 2022-05-10,
<draft-suchan-acme-onion-00.txt>

This document specifies identifiers and challenges required to enable

the Automated Certificate Management Environment (ACME) to issue
certificates for Tor Project's onion V3 addresses.

"Multicast Extension for QUIC", Jake Holland, Lucas Pardue, Max Franke,
2022-07-11, <draft-jholland-quic-multicast-02.txt>

This document defines a multicast extension to QUIC to enable the

efficient use of multicast-capable networks to send identical data
streams to many clients at once, coordinated through individual
unicast QUIC connections.

"Automated Certificate Management Environment (ACME) Device Attestation

Extension", Brandon Weeks, 2022-08-07,
<draft-bweeks-acme-device-attest-01.txt>

This document specifies new identifiers and a challenge for the

Automated Certificate Management Environment (ACME) protocol which
allows validating the identity of a device using attestation.

"An Advanced Scheduling Option for Multipath QUIC", Yunfei Ma, Yanmei Liu,
Christian Huitema, Xiaobo Yu, 2022-05-17, <draft-ma-quic-mpqoe-00.txt>

This document specifies an advanced scheduling option for multipath

QUIC protocol. The goal is to enable the use of multipath QUIC for
applications that have tight latency constraints. For general
purpose multipath packet scheduling, please refer to
[I-D.bonaventure-iccrg-schedulers].

Discussion Venues
 This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/yfmascgy/draft-ma-quic-advance-scheduling.

"SCION Overview", Corine de Kater, Nicola Rustignoli, Adrian Perrig,

2022-08-26, <draft-dekater-panrg-scion-overview-02.txt>

The Internet has been successful beyond even the most optimistic
expectations and is intertwined with many aspects of our society.
But although the world-wide communication system guarantees global
reachability, the Internet has not primarily been built with security
and high availability in mind. The next-generation inter-network
architecture SCION (Scalability, Control, and Isolation On Next-
generation networks) aims to address these issues. SCION was
explicitly designed from the outset to offer security and
availability by default. The architecture provides route control,
failure isolation, and trust information for end-to-end
communication. It also enables multi-path routing between hosts.

This document discusses the motivations behind the SCION architecture

and gives a high-level overview of its fundamental components,
including its authentication model and the setup of the control- and
data plane. A more detailed analysis of relationships and
dependencies between components is available in
[I-D.rustignoli-scion-components]. As SCION is already in production
use today, the document concludes with an overview of SCION
deployments.

"Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers
(4PE)", Gyan Mishra, Jeff Tantsura, 2022-05-18,
<draft-mishra-idr-v4-islands-v6-core-4pe-01.txt>

The 4Provider Edge (4PE) design explains how to interconnect IPv4

islands over a Multiprotocol Label Switching (MPLS) LDPv6 enabled,
Segment Routing (SR) enabled SR-MPLS IPv6 or SRv6 IPv6-Only core.
The 4PE routers exchange the IPv4 reachability information
transparently over the core using the Multiprotocol Border Gateway
Protocol (MP-BGP) over IPv6. In doing so, the BGP Next Hop field is
used to convey the IPv6 address of the 4PE router so that dynamically
established IPv6-signaled MPLS Label Switched Paths (LSPs) or SRv6
Network Programming IPv6 forwarding path instantiation and can be
utilized without any explicit tunnel configuration.

"IPv4-Only PE Design for IPv6-NLRI with IPv4-NH", Gyan Mishra, Jeff

Tantsura, Mankamana Mishra, Sudha Madhavi, Qing Yang, Adam Simpson,
Shuanglong Chen, 2022-07-07, <draft-mishra-bess-ipv4-only-pe-design-02.txt>

As Enterprises and Service Providers try to decide whether or not to

upgrade their brown field or green field MPLS/SR core to an IPv6
transport, Multiprotocol BGP (MP-BGP)now plays an important role in
the transition of their Provider (P) core network as well as Provider
Edge (PE) Edge network from IPv4 to IPv6. Operators must be able to
continue to support IPv4 customers when both the Core and Edge
networks are IPv4-Only.

This document details an important External BGP (eBGP) PE-CE Edge

IPv4-Only peering design that leverages the MP-BGP capability
 exchange by using IPv4 peering as pure transport, allowing both IPv4
Network Layer Reachability Information (NLRI) and IPv6 Network Layer
Reachability Information (NLRI)to be carried over the same (Border
Gateway Protocol) BGP TCP session. The design change provides the
same Dual Stacking functionality that exists today with separate IPv4
and IPv6 BGP sessions as we have today. With this design change from
a control plane perspective a single IPv4 is required for both IPv4
and IPv6 routing updates and from a data plane forwarindg perspective
an IPv4 address need only be configured on the PE and CE interface
for both IPv4 and IPv6 packet forwarding.

This document provides a IPv4-Only PE design solution for use cases

where operators are not yet ready to migrate to IPv6 or SRv6 core and
would like to stay on IPv4-Only Core short to long term and maybe
even indefinitely. With this design, operators can now remain with
an IPv4-Only Core and do not have to migrate to an IPv6-Only Core.

From a technical standpoint the underlay can remain IPv4 and still
transport IPv6 NLRI to support IPv6 customers, and so does not need
to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design
solution , IPv4 addressing only needs to be provisioned for the
IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6
provisioning at the Edge. This core and edge IPv4-Only peering
design can apply to any eBGP peering, public internet or private,
which can be either Core networks, Data Center networks, Access
networks or can be any eBGP peering scenario. This document provides
vendor specific test cases for the IPv4-Only peering design as well
as test results for the five major vendors stakeholders in the
routing and switching indusrty, Cisco, Juniper, Arista, Nokia and
Huawei. With the test results provided for the IPv4-Only Edge
peering design, the goal is that all other vendors around the world
that have not been tested will begin to adopt and implement this new
Best Current Practice for eBGP IPv4-Only Edge peering.

This Best Current Practice IPv4-only eBGP peering design

specification will help in use cases where operators are not yet
ready to migrate to IPv6 or SRv6 core or for very lage operator core
with thousdands of nodes where it maybe impractical to change the
underlay infrastructure to IPv6, and can now keep the existing IPv4
data plane IP, MPLS or SR-MPLS underlay intact indefinitely.

This document also defines a new IPv4 next hop encoding for IPv6 NLRI
over IPv4 Next Hop to uses 4 byte IPv4 address for the next hop and
not a IPv4 mapped IPv6 address. This encoding has been adopted by
the industry but has not been standardized until now with this
document.

"SRv6 Upper-Layer Checksum", Xiao Min, Liu Yao, Chongfeng Xie, 2022-05-18,
<draft-xiao-6man-srv6-checksum-00.txt>

This document provides a unified mechanism that makes the upper-layer

checksum computation rule defined in IPv6 Specification applicable,
whether SRv6 SIDs or SRv6 compressed SIDs are used.

"EVPN Mpls Ping Extension", DIKSHIT Saumya, Gyan Mishra, Srinath Rao,
Santosh Easale, Ashwini Dahiya, 2022-05-30,
<draft-saum-evpn-lsp-ping-extension-01.txt>

In an EVPN or any other VPN deployment, there is an urgent need to

 tailor the reachability checks of the client nodes via off-box tools
which can be triggered from a remote Overlay end-point or a
centralized controller. There is also a ease of operability needed
when the knowledge known is partial or incomplete. This document
aims to address the limitation in current standards for doing so and
provides solution which can be made standards in future. As an
additional requirement, in network border routers, there are liaison/
dummy VRFs created to leak routes from one network/fabric to another.
There are scenarios wherein an explicit reachability check for these
type of VRFs is not possible with existing mpls-ping mechanisms.
This draft intends to address this as well. Few of missing pieces
are equally applicable to the native lsp ping as well.

"FC1: A Non-Deterministic, Alien-Resistant, Cipher Where The Modulo Is The

Symmetric Key", Michele Fabbrini, 2022-05-21,
<draft-fabbrini-fc1-a-new-symmetric-key-cipher-00.txt>

In this paper we describe a symmetric key algorithm that offers an

unprecedented grade of confidentiality. Based on the uniqueness of
the modular multiplicative inverse of a positive integer a modulo n
and on its computability in a polynomial time, this non-deterministic
cipher can easily and quickly handle keys of millions or billions of
bits that an attacker does not even know the length of.
The algorithm's primary key is the modulo, while the ciphertext is
given by the concatenation of the modular inverse of blocks of
plaintext whose length is randomly chosen within a predetermined
range. In addition to the full specification here defined, in a
related work we present an implementation of it in Julia Programming
Language, accompanied by real examples of encryption and decryption.

"FC1 Algorithm Ushers In The Era Of Post-Alien Cryptography", Michele

Fabbrini, 2022-05-22,
<draft-fabbrini-algorithm-post-alien-cryptography-00.txt>

This memo aims to introduce the concept of "post-alien cryptography",

presenting a symmetric encryption algorithm which, in our opinion,
can be considered the first ever designed to face the challenges
posed by contact with an alien civilization. FC1 cipher offers an
unprecedented grade of confidentiality. Based on the uniqueness of
the modular multiplicative inverse of a positive integer a modulo n
and on its computability in a polynomial time, this non-deterministic
cipher can easily and quickly handle keys of millions or billions of
bits that an attacker does not even know the length of.
The algorithm's primary key is the modulo, while the ciphertext is
given by the concatenation of the modular inverse of blocks of
plaintext whose length is randomly chosen within a predetermined
range. In addition to the full specification here defined, in a
related work we present an implementation of it in Julia Programming
Language, accompanied by real examples of encryption and decryption.

"Combination Method of NASs", Liu Yao, Zheng Zhang, 2022-05-24,

<draft-liu-mpls-nas-combination-00.txt>

This document provides an alternate mechanism to provide different

ordering of in-stack data for MNA solutions which leverage the fixed
bit catalogs.

"Service Aware Network Framework", Daniel Huang, Bin Tan, 2022-05-24,

<draft-huang-service-aware-network-framework-00.txt>
 Cloud has been migrating from concentrated center sites to edge nodes
with responsive and agile services to the subscribers. This
industry-wide trend would be reasonably expected to continue into the
future which would enjoy geographically ubiquitous services. Rather
than transmitting service data streams to the stable and limited
service locations such as centered cloud sites, routing and
forwarding network will have to adapt to the emerging scenarios where
the service instances would be highly dynamic and distributed, and
further more, demand more fine-grained networking policies than the
current routing and forwarding scheme unaware of service SLA
requirements. This proposal is to demonstrate a framework under
which the above-mentioned requirements would be satisfied.

"Transport Layer Security (TLS) Extension: Validation Request", Robert

Segers, Ashley Kopman, 2022-08-24,
<draft-segers-tls-cert-validation-ext-04.txt>

This document describes the Server-based Certificate Validation

Protocol (SCVP) Validation Request extension to the Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)
protocols.

The Validation Request Extension provides a new protocol for TLS/DTLS

allowing inclusion of SCVP certificate path validation information in
the TLS/DTLS handshake.

"EAT Media Types", Laurence Lundblade, Henk Birkholz, Thomas Fossati,

2022-05-26, <draft-lundblade-rats-eat-media-type-00.txt>

Payloads used in Remote Attestation Procedures may require an

associated media type for their conveyance, for example when used in
RESTful APIs.

This memo defines media types to be used for Entity Attestation

Tokens (EAT).

"Use Case Validation Request TLS Extension", Robert Segers, Ashley Kopman,
2022-05-26, <draft-segers-tls-cert-val-ext-use-case-00.txt>

This document describes a civil aviation, air-to-ground communication

use case for the Path Validation extension to Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS) using the
Server-based Certificate Validation Protocol (SCVP).

"Multiple Core Performance Hint Option", Herbert Robinson, 2022-05-26,

<draft-robinson-intarea-mcphint-00.txt>

This standard defines a method for differentiating between unrelated

data streams when the source and destination ports are encrypted.
This method MAY be used by hardware or software to evenly distribute
incoming workload between multiple CPU cores and/or other processing
elements.

"The New Webiquette", Kate, 2022-05-26,

<draft-kate-the-new-webiquette-00.txt>

The inspiration for this document came from RFC 1855 ("Netiquette"),
which is now partially obsolete and no longer maintained. A lot has
 happened on the Internet since then (social media, video
conferencing, deepfakes, ad networks), which should be applied in a
netiquette. Like in RFC 1855 this is only a minimal standard.

"Path Tracing in SR-MPLS networks", Clarence Filsfils, Ahmed Abdelsalam,

Pablo Camarillo, Israel Meilik, Mike Valentine, Ruediger Geib, Jonathan
Desmarais, 2022-05-30, <draft-filsfils-spring-path-tracing-srmpls-00.txt>

Path Tracing provides a record of the packet path as a sequence of

interface ids. In addition, it provides a record of end-to-end
delay, per-hop delay, and load on each interface that forwards the
packet.

Path Tracing has the lowest MTU overhead compared to alternative

proposals such as [INT], [I-D.ietf-ippm-ioam-data],
[I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa].

Path Tracing supports fine grained timestamp. It has been designed

for linerate hardware implementation in the base pipeline.

This document defines the Path Tracing specification for the SR-MPLS
dataplane. The Path Tracing specification for the SRv6 dataplane is
defined in [I-D.filsfils-spring-path-tracing].

"Entity Attestation Token (EAT) Collection Type", Simon Frost, 2022-06-27,

<draft-frost-rats-eat-collection-01.txt>

The default top-level definitions for an EAT [I-D.ietf-rats-eat]

assume a hierarchy involving a leading signer within the Attester.
Some token use cases do not match that model. This specification
defines an extension to EAT allowing the top-level of the token to
consist of a collection of otherwise defined tokens.

"Shared OpenPGP Certificate Directory", Nora Widdecke, Justus Winter,

2022-05-31, <draft-nwjw-openpgp-cert-d-00.txt>

This document defines a generic OpenPGP certificate store that can be

shared between implementations. It also defines a way to root trust,
and a way to associate petnames with certificates. Sharing
certificates and trust decisions increases security by enabling more
applications to take advantage of OpenPGP. It also improves privacy
by reducing the required certificate discoveries that go out to the
network.

"Reliability Considerations of Native Short Addressing", Guangpeng Li, Zhe

Lou, Luigi Iannone, 2022-06-01, <draft-li-nsa-reliability-00.txt>

Native Short Address (NSA [I-D.li-6lo-native-short-address]),

proposes to algorithmically assign short addresses to nodes in a 6lo
environment so to achieve stateless forwarding, hence, avoiding using
a routing protocol. NSA is more suitable in case of stable and
static wireline connectivity, in order to avoid renumbering due to
topology changes. Even in such kind of scenarios, reliability
remains an issue. This memo tackles specifically reliability in NSA
deployments, analyzing possible broad solution categories to solve
the issue.

"Secure Asset Transfer (SAT) Interoperability Architecture", Thomas

Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna,
2022-06-01, <draft-hardjono-sat-architecture-00.txt>

This document proposes an interoperability architecture for the

secure transfer of assets between two networks or systems based on
the gateway model.

"TACACS+ Security and SSH Public Keys", Thorsten Dahm, dcmgash@cisco.com,

Andrej Ota, John Heasley, 2022-06-02,
<draft-dahm-opsawg-tacacs-security-00.txt>

The TACACS+ Protocol [RFC8907] provides device administration for

routers, network access servers and other networked computing devices
via one or more centralized servers. This document, a companion to
the TACACS+ protocol [RFC8907], adds new packet formats to improve
security and function and support for SSH [RFC4716] public keys.

"Extended relation information for Semantic Definition Format (SDF)", Petri

Laari, 2022-06-03, <draft-laari-asdf-relations-00.txt>

The Semantic Definition Format (SDF) base specification defines set

of basic information elements that can be used for describing a large
share of the existing data models from different ecosystems. While
these data models are typically very simple, such as basic sensors
definitions, more complex models, and in particular bigger systems,
benefit from ability to describe additional information on how
different definitions relate to each other. This document specifies
an extension to SDF for describing complex relationships and
additional information about them.

"The Architecture for Internet of Things Network", Yan Liu, Yang Song,
haisheng yu, 2022-06-07, <draft-liu-iot-arch-00.txt>

In this document, it identifies gateways for field-bus networks, data

storages for archiving and developing data sharing platform, and
application units to be important system components for developing
digital communities: i.e., building-scale and city-wide ubiquitous
facility networking infrastructure. The standard defines a data
exchange protocol that generalizes and interconnects these components
(gateways, storages, application units) over the IPv6-based networks.
This enables integration of multiple facilities, data storages,
application services such as central management, energy saving,
environmental monitoring and alarm notification systems.

"BGP Extensions of SR Policy for Headend Behavior", Changwang Lin, Jiang

Wenying, Yisong Liu, Mengxiao Chen, Hao Li, 2022-06-10,
<draft-lin-idr-sr-policy-headend-behavior-00.txt>

This document defines extensions to Border Gateway Protocol (BGP) to

distribute SR policies carrying headend behavior.

"Distribute SRv6 Locator by DHCP", Weiqiang Cheng, RuiboHan, Changwang Lin,

Yuanxiang Qiu, 2022-07-27,
<draft-cheng-dhc-distribute-srv6-locator-by-dhcp-01.txt>

In SRv6 network, locators need to be assigned to each SRv6 Endpoint,

and segments are created based on locators. This document describes
the method of assigning locators to SRv6 Endpoints through DHCPv6.

"Parametrized Content-Format for CoAP", Thomas Fossati, Henk Birkholz,

2022-06-10, <draft-fossati-core-parametrized-cf-00.txt>

This document specifies a "parametrized" CoAP Content-Format data

item that allows supplementing a Content-Format with additional media
type parameters.

This document also defines two new CoAP Options, Parmetrized-Content-

Format and Parametrized-Multi-Valued-Accept, that build upon the
"parametrized" Content-Format data item to work around some of the
limitations of the existing Accept and Content-Format Options.

"IS-IS Application-Specific Link Attributes", Les Ginsberg, Peter Psenak,

Stefano Previdi, Wim Henderickx, John Drake, 2022-07-24,
<draft-ginsberg-lsr-rfc8919bis-02.txt>

Existing traffic-engineering-related link attribute advertisements

have been defined and are used in RSVP-TE deployments. Since the
original RSVP-TE use case was defined, additional applications (e.g.,
Segment Routing Policy and Loop-Free Alternates) that also make use
of the link attribute advertisements have been defined. In cases
where multiple applications wish to make use of these link
attributes, the current advertisements do not support application-
specific values for a given attribute, nor do they support indication
of which applications are using the advertised value for a given
link. This document introduces new link attribute advertisements
that address both of these shortcomings.

This document obsoletes RFC 8919.

"OSPF Application-Specific Link Attributes", Peter Psenak, Les Ginsberg,

Wim Henderickx, Jeff Tantsura, John Drake, 2022-07-24,
<draft-ppsenak-lsr-rfc8920bis-02.txt>

Existing traffic-engineering-related link attribute advertisements

have been defined and are used in RSVP-TE deployments. Since the
original RSVP-TE use case was defined, additional applications (e.g.,
Segment Routing Policy and Loop-Free Alternates) that also make use
of the link attribute advertisements have been defined. In cases
where multiple applications wish to make use of these link
attributes, the current advertisements do not support application-
specific values for a given attribute, nor do they support indication
of which applications are using the advertised value for a given
link. This document introduces new link attribute advertisements in
OSPFv2 and OSPFv3 that address both of these shortcomings.

This document obsoletes RFC 8920.

"LSP Ping/Traceroute for SR-MPLS NRP SIDs", Liu Yao, Shaofu Peng,
2022-06-13, <draft-liu-mpls-lsp-ping-nrp-00.txt>

[RFC8287] defines the extensions to MPLS LSP ping and traceroute for
Segment Routing IGP-Prefix and IGP-Adjacency SIDs with an MPLS data
plane. To correctly identify and validate an SR NRP SID, the
validating device also requires NRP-ID to be supplied in the FEC
Stack sub-TLV. This document introduces new Target FEC Stack sub-
TLVs to perform MPLS LSP ping and traceroute for NRP SIDs.

"Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)",
Kotikalapudi Sriram, Igor Lubashev, Doug Montgomery, 2022-06-15,
<draft-sriram-sidrops-bar-sav-00.txt>

Designing an efficient source address validation (SAV) filter

requires minimizing false positives (i.e., avoiding dropping
legitimate traffic) while maintaining directionality (see RFC8704).
This document advances the technology for SAV filter design through a
method that makes use of BGP UPDATE messages, Autonomous System
Provider Authorization (ASPA), and Route Origin Authorization (ROA).
The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be
used by network operators to derive more robust SAV filters and thus
improve network resilience.

"Client Roaming Control", Eugene Adell, 2022-06-15,

<draft-adell-client-roaming-00.txt>

This document describes the Client Roaming Control (CRC) technique to

allow an organization to control the access to third-party
applications over Internet. It specifies the _crc Global Underscored
Node Name for organizations willing to implement this technique. A
new Client Roaming Support (CRS) Resource Record is also introduced
for the applications supporting an authorization mechanism honoring
the CRC, in order to inform of this support.

"Extensible In-band Processing (EIP) Architecture and Framework", Stefano

Salsano, Hesham ElBakoury, Diego Lopez, 2022-06-15, <draft-eip-arch-00.txt>

Extensible In-band Processing (EIP) extends the functionality of the

IPv6 protocol considering the needs of future Internet services / 6G
networks. This document discusses the architecture and framework of
EIP. Two separate documents respectively analyze a number of use
cases for EIP and provide the protocol specifications of EIP.

"NETCONF over TLS 1.3", Sean Turner, Russ Housley, 2022-06-16,

<draft-turner-netconf-over-tls13-00.txt>

RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This
document describes how to protect NETCONF messages with TLS 1.3.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Network Configuration

Working Group mailing list (netconf@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/netconf/.

Source for this draft and an issue tracker can be found at

https://github.com/seanturner/netconf-over-tls13.

"a simple way to provide informations for contributors", Valentin Binotto,

2022-06-22, <draft-valentinbinotto-contributingtxt-01.txt>

Open source projects rely on the cooperation of third parties. Other

websites also rely on user feedback, for example, when bugs occur.
There are various platforms that enable effective collaboration.
However, this diversity also presents a challenge. Where should
users who have discovered an error report it? Or how can third
parties participate in a project? This document presents one way to
communicate such information in a consistent manner.
"IPv6 Options for Cyclic Queuing and Forwarding Variants", Yizhou Li,
Shoushou Ren, Guangpeng Li, Fan Yang, Jeong-dong Ryoo, Peng Liu,
2022-06-19, <draft-yizhou-detnet-ipv6-options-for-cqf-variant-00.txt>

The fundamental Cyclic Queuing and Forwarding (CQF) defined by Time-

Sensitive Networking (TSN) requires no per-stream per-hop state
maintenance and at the same time its end-to-end bounded latency and
jitter can be easily computed. Such features are attractive and
therefore CQF is being considered in wider deployments. To
accommodate the different deployments, there are variants of CQF
enhancement. This document introduces a new IPv6 option to include
the cycle identification to help leverage CQF variants in DetNet
network to facilitate the deployments.

"S-BFD Proxy", Qing Yang, Feng Zhu, Victor Wen, Jianwei Hu, Beixin Huang,
Nian Liu, 2022-06-23, <draft-yang-bfd-sbfd-proxy-01.txt>

This document proposes an extension to Seamless Bidirectional

Forwarding Detection (S-BFD).

The S-BFD initiator will send packets that carry extra information,
and this enables reflector to act as a proxy, and respond with the
extra information in consideration.

This document updates RFC 7880.

"A YANG Model for BGP-LS, BGP-LS-VPN, and BGP-LS-SPF", Mahesh Jethanandani,
Keyur Patel, 2022-06-20, <draft-mahesh-lsvr-bgp-ls-yang-00.txt>

This document defines a YANG data model for configuration and

management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF.

"IPv4-Only PE Design All SAFI", Gyan Mishra, Jeff Tantsura, Mankamana

Mishra, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen,
2022-07-07, <draft-mishra-bess-ipv4-only-pe-design-all-safi-01.txt>

As Enterprises and Service Providers try to decide whether or not to

upgrade their brown field or green field MPLS/SR core to an IPv6
transport, Multiprotocol BGP (MP-BGP)now plays an important role in
the transition of their Provider (P) core network as well as Provider
Edge (PE) Edge network from IPv4 to IPv6. Operators must be able to
continue to support IPv4 customers when both the Core and Edge
networks are IPv4-Only.

[I-D.mishra-bess-ipv4-only-pe-design] details an important External

BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-
BGP capability exchange by using IPv4 peering as pure transport,
allowing both IPv4 Network Layer Reachability Information (NLRI) and
IPv6 Network Layer Reachability Information (NLRI)to be carried over
the same (Border Gateway Protocol) BGP TCP session. The design
change provides the same Dual Stacking functionality that exists
today with separate IPv4 and IPv6 BGP sessions as we have today.
With this design change from a control plane perspective a single
IPv4 is required for both IPv4 and IPv6 routing updates and from a
data plane forwarindg perspective an IPv4 address need only be
configured on the PE and CE interface for both IPv4 and IPv6 packet
forwarding.
 [I-D.mishra-bess-ipv4-only-pe-design] provides a IPv4-Only PE design
solution for use cases where operators are not yet ready to migrate
to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short
to long term and maybe even indefinitely. With this design,
operators can now remain with an IPv4-Only Core and do not have to
migrate to an IPv6-Only Core. From a technical standpoint the
underlay can remain IPv4 and still transport IPv6 NLRI to support
IPv6 customers, and so does not need to be migrated to IPv6-Only
underlay. With this IPv4-Only PE Design solution , IPv4 addressing
only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge
peering design, thereby eliminating IPv6 provisioning at the Edge.
This core and edge IPv4-Only peering design can apply to any eBGP
peering, public internet or private, which can be either Core
networks, Data Center networks, Access networks or can be any eBGP
peering scenario.

This document details an important External BGP (eBGP) PE-PE Inter-AS

IPv6-Only peering design that leverages the MP-BGP capability
exchange by using IPv6 peering as pure transport, allowing all and
any IPv4 Network Layer Reachability Information (NLRI) and IPv6
Network Layer Reachability Information (NLRI)to be carried over the
same (Border Gateway Protocol) BGP TCP session for all Address Family
Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI).
The design change provides the same Dual Stacking functionality that
exists today with separate IPv4 and IPv6 BGP sessions as we have
today. With this IPv4-Only PE Design, IPv6 address MUST not be
configured on the the Provider Edge (PE) - Customer Edge (CE), or
Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous
System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge
(PE). From a control plane perspective a single IPv4-Only peer is
required for both IPv4 and IPv6 routing updates and from a data plane
forwarindg perspective an IPv4 address need only be configured on the
PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet
forwarding. This document defines the IPv4-Only PE Design as a new
PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard which is
described in the POC testing document
[I-D.mishra-bess-ipv4-only-pe-design] which is now extended to
support to all AFI/SAFI ubiquitously. As service providers migrate
to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits
as well, and thus Inter-AS options Option-A, Option-B, Option-AB and
Option-C are still applicable and thus this extension of IPv4-Only
peering architecure extension to Inter-AS peering is very relevant to
Segment Routing as well.

"Framework of Multi-domain IPv6-only Network", Chongfeng Xie, Chenhao Ma,

Xing Li, Gyan Mishra, Mohamed Boucadair, 2022-06-20,
<draft-xie-v6ops-framework-multi-domain-ipv6only-00.txt>

For the IPv6 transition, dual-stack deployments require both IPv4 and
IPv6 transfer capabilities are deployed in parallel. IPv6-only is
considered as the ultimate stage where only IPv6 transfer
capabilities are used while ensuring global reachability for both
IPv6 and IPv4(IPv4aaS). This document specifies requirements and
propose a general framework when deploying IPv6-only in multi-domain
network.

"Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12

Syntax", Hubert Kario, 2022-06-21, <draft-kario-pkcs12-pbmac1-00.txt>
 This document specifies additions and amendments to RFC 7292
[RFC7292]. It defines a way to use the Password Based Message
Authentication Code 1, defined in RFC 8018 [RFC8018], inside the PKCS
#12 syntax. The purpose of this specification is to permit use of
more modern PBKDFs and allow for regulatory compliance.

"Privacy Considerations for Web Feed Readers", Mark Nottingham, 2022-06-21,

<draft-nottingham-feed-privacy-00.txt>

This specification collects privacy-enhancing guidelines for Web feed

readers.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

https://datatracker.ietf.org/doc/draft-nottingham-feed-privacy/.

information can be found at https://mnot.github.io/I-D/.

Source for this draft and an issue tracker can be found at

https://github.com/mnot/I-D/labels/feed-privacy.

Note to Readers

This draft is a quick straw-man; it is intended to assess implementer

and community interest in the topic, not to state concrete
requirements (yet). Feedback much appreciated.

"Concise TA Stores (CoTS)", Carl Wallace, Russ Housley, 2022-06-22,

<draft-wallace-rats-concise-ta-stores-00.txt>

Trust anchor (TA) stores may be used for several purposes in the
Remote Attestation Procedures (RATS) architecture including verifying
endorsements, reference values, digital letters of approval,
attestations, or public key certificates. This document describes a
Concise Reference Integrity Manifest (CoRIM) extension that may be
used to convey optionally constrained trust anchor stores containing
optionally constrained trust anchors in support of these purposes.

"Key Attestation Extension for Certificate Management Protocols", Carl

Wallace, Sean Turner, 2022-08-10,
<draft-wallace-lamps-key-attestation-ext-01.txt>

Certification Authorities (CAs) issue certificates for public keys

conveyed to the CA via a certificate management message or protocol.
In some cases, a CA may wish to tailor certificate contents based on
whether the corresponding private key is secured by hardware in non-
exportable form. This document describes extensions that may be
included in any of several widely used certificate management
protocols to convey attestations about the private key to the CA to
support this determination.

"SDP Offer/Answer for RTP using QUIC as Transport - Design Issues", Spencer
Dawkins, 2022-06-22, <draft-dawkins-avtcore-sdp-rtp-quic-issues-00.txt>

This document is intended to capture SDP aspects of RTP over QUIC

design issues that have arisen, been discussed by the AVTCORE working
 group, and have reached a resolution that can be included in "SDP
Offer/Answer for RTP using QUIC as Transport".

This document is a companion document to "SDP Offer/Answer for RTP

using QUIC as Transport". That document focuses on the description
and registration of SDP "proto" attribute parameters with IANA, to
allow applications that rely on SDP Offer/Answer to negotiate the
QUIC protocol as an encapsulation for RTP.

"SDP Offer/Answer for RTP using QUIC as Transport" is itself a

companion document to "RTP over QUIC", and follows the lead of the
latter specification as it evolves.

"RTP Control Protocol (RTCP) Messages for Green Metadata", Yong He, Waqar
Zia, Christian Herglotz, Edouard Francois, 2022-07-29,
<draft-he-avtcore-rtcp-green-metadata-01.txt>

This memo describes an RTCP feedback message format for the ISO/IEC
International Standard 23001-11, known as Energy Efficient Media
Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/
WG 3 MPEG System. The RTCP payload format specified in this document
enables receivers to provide feedback to the senders and thus allows
for short-term adaptation and feedback-based energy efficient
mechanisms to be implemented. The payload format has broad
applicability in real-time video communication services.

"REST API Linked Data Keywords", Roberto Polli, 2022-06-23,

<draft-polli-restapi-ld-keywords-00.txt>

This document defines two keywords to provide semantic information in

OpenAPI Specification and JSON Schema documents.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

https://datatracker.ietf.org/doc/draft-polli-restapi-ld-keywords/.

information can be found at https://github.com/ioggstream/draft-

polli-restapi-ld-keywords.

Source for this draft and an issue tracker can be found at

https://github.com/ioggstream/draft-polli-restapi-ld-keywords/issues.

"DetNet Queue Encapsulation with MPLS Data Plane", Xueyan Song, Quan Xiong,
2022-06-24, <draft-sx-detnet-mpls-queue-00.txt>

This document specifies format and principals for the MPLS header
which contains the queuing delay information, designed for use over a
DetNet network with MPLS data plane. The guaranteed delay support
enables forwarding and scheduling decisions for time-sensitive
service running on DetNet transit nodes that operate within a
constrained network domain. This document also specifies a
representation for the delay field values in such networks.

"Framework of Multi-domain IPv6-only Underlay Networks and IPv4 as a

Service", Chongfeng Xie, Chenhao Ma, Xing Li, Gyan Mishra, Mohamed
Boucadair, Thomas Graf, 2022-08-18,
<draft-xie-v6ops-framework-md-ipv6only-underlay-03.txt>

For the IPv6 transition, dual-stack deployments require both IPv4 and
IPv6 forwarding capabilities to be deployed in parallel. IPv6-only
is considered as the ultimate stage where only IPv6 transfer
capabilities are used while ensuring global reachability for both
IPv6 and IPv4 (usually known as IPv4aaS). This document specifies
requirements and proposes a framework for deploying IPv6-only as the
underlay in multi-domain networks.

"Asynchronous Deterministic Networking Framework for Large-Scale Networks",

Jinoo Joung, Jeong-dong Ryoo, Tae-sik Cheung, Yizhou Li, Peng Liu,
2022-06-26, <draft-joung-detnet-asynch-detnet-framework-00.txt>

This document describes an overall framework of Asynchronous

Deterministic Networking (ADN) for large-scale networks. It
specifies the functional architecture and requirements for providing
latency and jitter bounds to high priority traffic, without time-
synchronization of network nodes.

"Inter-Gateway Discovery and Communications in Building Automation

Systems", Michael Richardson, Wei Pan, 2022-06-26,
<draft-richardson-snac-building-use-case-00.txt>

This document describes a use case where gateways need to discover

each other in order to maintain building safety systems

"Use Case of Remote Driving and its Network Requirements", Lijun Dong,
Richard Li, Jungha Hong, 2022-06-27,
<draft-dong-remote-driving-usecase-00.txt>

This document illustrates the use case of remote driving that

leverages the human driver's advanced perceptual and cognitive skills
to enhance autonomous driving when it is absent or falls short.
Specifically the document analyzes the end-to-end latency that is
required in the network to support collision avoidance in remote
driving. The document also summarizes the other necessary
requirements that the networking services shall support.

"IoT Information-Model Standards Description ("Nutrition Label")",

Milenkovic, 2022-06-27,
<draft-milenkovic-t2trg-iot-standards-description-00.txt>

Implementation of IoT systems imposes a requirement of M2M semantic

interoperability. This problem is addressed by a number of ongoing
attempts to define and standardize IoT information and data models.
At present this work is fragmented across several standards with
different approaches, scope, objectives, terminology, and assumptions
that makes them difficult to understand and compare. This document
is part of the effort to alleviate that problem by means of more
streamlined presentations and descriptions.

We are advocating for clear articulation of the intent and implicit

or explicit assumptions in SDO specifications using the common
terminology. Such clarifications would aid IoT practitioners and
potential adopters to make meaningful comparisons and facilitate
selection of IoT specifications that are the best fit for their
intended purpose. To that end, we propose that creators of IoT
standards address a list of questions that would characterize their
 work in comparable ways, somewhat akin to the intent of nutrition
labels for food.

This paper describes the basic design principles and practices of IoT
information and data model definitions, and proposes an initial list
of questions that SDOs may address to facilitate understanding and
comparisons. Our intent is to evolve and refine this list over time
by actively soliciting and incorporating feedback and suggestions of
IoT community.

"A YANG Data Model for requesting Path Computation in an Optical Transport
Network (OTN)", Italo Busi, Aihua Guo, Sergio Belotti, 2022-07-10,
<draft-gbb-ccamp-otn-path-computation-yang-01.txt>

This document describes a YANG data model for a Remote Procedure

Calls (RPC) to request Path Computation in an Optical Transport
Network (OTN).

The YANG data models defined in this document conforms to the Network
Management Datastore Architecture (NMDA).

"Credentials Provisioning and Management via EAP (EAP-CREDS)", Massimiliano

Pala, Yuan Tian, 2022-06-30, <draft-pala-tian-eap-creds-00.txt>

With the increase number of devices, protocols, and applications that

rely on strong credentials (e.g., digital certificates, keys, or
tokens) for network access, the need for a standardized credentials
provisioning and management framework is paramount. The 802.1x
architecture allows for entities (e.g., devices, applications, etc.)
to authenticate to the network by providing a communication channel
where different methods can be used to exchange different types of
credentials. However, the need for managing these credentials (i.e.,
provisioning and renewal) is still a hard problem to solve. Usually,
credentails used in an access network can be in different levels
(e.g., network-level, user-level) and sometimes tend to live
unmanaged for quite a long time due to the challenges of operation
and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed
Networks (e.g., Cable Modems), could enable our operators to offer a
registration and credentials management service integrated in the
home WiFi thus enabling visibility about registered devices. During
initialization, EAP-CREDS also allows for MUD files or URLs to be
transferred between the EAP Peer and the EAP Server, thus giving
detailed visibility about devices when they are provisioned with
credentials for accessing the networks. The possibility provided by
EAP-CREDS can help to secure home or business networks by leveraging
the synergies of the security teams from the network operators thanks
to the extended knowledge of what and how is registered/
authenticated. This specifications define how to support the
provisioning and management of authentication credentials that can be
exploited in different environments (e.g., Wired, WiFi, cellular,
etc.) to users and/or devices by using EAP together with standard
provisioning protocols.

"Credentials Provisioning and Management via EAP Method (EAP-CREDS)",

Massimiliano Pala, Yuan Tian, 2022-06-30,
<draft-pala-tian-eap-creds-spp-01.txt>

With the increase number of devices, protocols, and applications that

rely on strong credentials (e.g., digital certificates, keys, or
 tokens) for network access, the need for a standardized credentials
provisioning and management framework is paramount. The 802.1x
architecture allows for entities (e.g., devices, applications, etc.)
to authenticate to the network by providing a communication channel
where different methods can be used to exchange different types of
credentials. EAP-CREDS is an EAP method that specifically designed
for credential provisioning and management. If implemented in Access
Networks (e.g., wired), EAP-CREDS can offer credentials management
services such as registration, provisioning, and renewal. Besides,
EAP-CREDS provides protocol encapsulation mechanism that allows it to
use with other credential management protocols. Therefore, this
document defines how to use EAP-CREDS with the Simple Provisioning
Protocol (SPP) to support the provisioning and management of
authentication credentials for user and/or devices in an access
network. Other credential provisioning protocols can also use this
document as a guideline and template for its own encapsulation with
EAP-CREDS.

"Discarding Priority of RTP Video Packets", Lijun Dong, Richard Li, Stuart
Clayman, Muge Sayit, 2022-07-10, <draft-dong-priority-rtp-packet-02.txt>

This document illustrates that significance difference or discarding

priority might exist among RTP packets which encapsulate video
streaming data with the existing modern video codecs, i.e., H.264/
AVC, SVC, H.265/HEVC and H.266/VVC.

The document overviews the RTP NALU header format for the existing
modern video codecs. Each contains at least one field that indicates
the RTP packet's relative significance within the video stream. With
the dominance of video traffic in the Internet, selectively dropping
RTP packets from competing video streams according to their
significances or discarding priorities could be a complementary
mechanism when dealing with network congestion. The document
proposes the Differentiated Services Code Point (DSCP) value mapping
to the RTP packet discarding priority carried in the RTP NALU header.
The document also proposes a new Hop-by-Hop Extension Header (HbH-EH)
with a value that is copied from the discarding priority of the RTP
packet, if the 6-bit DSCP value is not long enough for the mapping.

"Neighbor Discovery support for Multi-home Multi-prefix", Eduard, Paolo

Volpato, 2022-07-01, <draft-vv-6man-nd-support-mhmp-00.txt>

Multi-home Multi-prefix IPv6 environment is the norm for businesses

that need to have uplink resiliency.

For any considered destination, the MHMP challenge may be split into
3 sub-challenges (important to solve in the below order):
1) the host should choose the proper source address for the packet,
2) the host should choose the best default router as the next-hop,
3) site topology may be complicated and may need the source routing
through the site.

This draft is concerned with the solution for the first two problems
that need improvement for the ND (RFC 4861) SLAAC (RFC 4862) and
Default Address Selection (RFC 6724). The last problem is considered
as properly discussed by Multihoming in Enterprise (RFC 8678).

"A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS
Technologies", Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, John
Drake, Mohamed Boucadair, Luis Contreras, Ivan Bykov, 2022-07-01,
<draft-srld-teas-5g-slicing-00.txt>

5G slicing is a new feature that was introduced by the 3rd Generation

Partnership Project (3GPP) in mobile networks. It covers slicing
requirements for all mobile domains, including RAN (Radio Access
Network), Core and Transport.

This document describes a basic IETF Network Slice realization model

in IP/MPLS networks, with a focus on fulfilling 5G slicing
requirements. This IETF Network Slice realization model reuses many
building blocks currently commonly used in communication service
provider (CSP) networks.

"Secure IP Binding Synchronization via BGP EVPN", DIKSHIT Saumya, Gadekal,

Reddy, 2022-07-02, <draft-saumthimma-evpn-ip-binding-sync-00.txt>

The distribution of clients of L2 domain across extended, networks

leveraging overlay fabric, needs to deal with synchronizing the
Client Binding Database. The 'Client IP Binding' indicates the IP,
MAC and VLAN details of the clients that are learnt by security
protocols. Since learning 'Client IP Binding database' is last mile
solution, this information stays local to the end point switch, to
which clients are connected. When networks are extended across
geographies, that is, both layer2 and layer3, the 'Client IP Binding
Database' in end point of switches of remote fabrics should be in
sync. This literature intends to align the synchronization of
'Client IP Binding Database" through an extension to BGP control
plane constructs and as BGP is a typical control plane protocol
configured to communicate across network boundries.

"Problem Statement and Requirements for the Operation and Control Networks
(OCNs)", Tooba Faisal, Diego Lopez, Jose Ordonez-Lucena, Kiran Makhijani,
2022-07-02, <draft-tf-ocn-ps-00.txt>

The emergence of applications based on machine-to-machine

communications require control systems to be extended beyond their
closed environments. Specifically, autonomous systems that bring
about physical and mechanical changes to an environment, heavily rely
on their remote operations and control.

This document provides an overview of the issues associated with the

communications in the control systems to support network-based
operations in a generic manner at any-scale environments.

The term Operations and Control networks (OCN) is used to describe

the common characteristics emerging from the requirements for such
control systems.

The OCNs are technology-agnostic concept. This document aims to

discuss the requirements for establishing common interfaces and
functions.

"Operations and Control Networks - Reference Model and Taxonomy", Kiran

Makhijani, Tooba Faisal, Richard Li, 2022-07-02,
<draft-km-intarea-ocn-00.txt>

This text formulates a specialized network concept to support

communication constraints in automated systems. These specialized
 networks, formulated as Operations and Control networks (OCN), are
significant to many application scenarios involving the control and
monitoring of mechanical and digital devices. The document defines
the OCN reference model, describing the associated components,
interfaces, and reference points. The reference model is independent
of any specific technology. Standardized mechanisms will facilitate
large-scale machine-to-machine communication and help with the
integration between OCN and the Internet.

"One-way delay measurement method based on Digital Twin Network", Hongwei

Yang, Danyang Chen, 2022-07-03, <draft-yc-nmrg-dtn-owd-measurement-00.txt>

This document implements an accurate network delay measurement method

based on the digital twin network. This method does not need to send
measurement packets, change the physical network configuration,
change the format of service packets, and do not require physical
network elements to support the time synchronization protocol. Two-
way delay and one-way delay measurement of any service packet.The
digital twin network architecture of this document follows the NMRG
working group paper draft-irtf-nmrg-network-digital-twin-arch-00.

"Digital Twin Network Flow Simulation", Hongwei Yang, Cheng Zhou,

2022-07-03, <draft-yz-nmrg-dtn-flow-simulation-00.txt>

Some important application scenarios of digital twin network, such as

network new technology experiment, network configuration
verification, network performance optimization, etc., all require the
virtual traffic in the twin network to accurately simulate the real
traffic in the physical network.The real traffic in the physical
network is called the physical traffic, and the virtual traffic in
the twin network is called the twin traffic. In order to realize the
high-fidelity simulation of the physical traffic by the twin traffic,
this paper proposes that the twin traffic and the physical traffic
should satisfy three consistent characteristics, and An
implementation method of twin flow is introduced.

"Sub-slicing for SRv6", Louis Chan, 2022-07-03,

<draft-chan-spring-srv6-sub-slice-00.txt>

This document describes how to achieve further slicing or traffic

engineering
interoperability between vendors without the use of SRH.

Slicing or traffic engineering information is encapsulated as part of

the SRv6 SID.
Use of IP longest prefix match approach to identify the
further slicing via sub-
slice identifier.

The traffic engineering from one end to another end is seen as segment
by segment
approach. This approach could solve the scalability of
traffic engineering tunnels
required in a huge network, which order of
N^2 has be considered.

"Forward Requests Return Multicast (FRRM) Communication Semantic", Dirk

Trossen, 2022-07-04, <draft-trossen-rtgwg-frrm-00.txt>
 This document introduces a communication semantic for multicast that
is initiated through forward requests, resulting in dynamic return
multicast to the set of initiating clients. The key dynamic nature
here is the return multicast relations being possibly different for
every transmission.

We introduce this semantic more formally, present exemplifying use

cases and then focus on realizing this semantic using two multicast
technologies.

Although this document formally introduces the FRRM semantic as a new

communication semantic, it does not intend to show the realization of
it through the specific multicast technologies in all details. This
is left for separate documents, if desired.

"A well-known BGP community to denote prefixes used for Anycast",

Maximilian Wilhelm, Fredy Kuenzler, 2022-07-24,
<draft-wilhelm-grow-anycast-community-01.txt>

In theory routing decisions on the Internet and by extension within

ISP networks should always use hot-potato routing to reach any given
destination. In reality operators sometimes choose to not use the
hot-potato paths to forward traffic due to a variety of reasons,
mostly motivated by traffic engineering considerations. For prefixes
carrying anycast traffic in virtually all situations it is advisable
to stick to the hot-potato principle. As operators mostly don't know
which prefixes are carrying unicast or anycast traffic, they can't
differentiate between them in their routing policies.

To allow operators to take well informed decisions on which prefixes

are carrying anycast traffic this document proposes a well-known BGP
community to denote this property.

"Static Multicast Routing", tathagata nandy, Anil Raj, Muthukumar,

Subramanian, 2022-07-05, <draft-nandy-pim-static-routing-00.txt>

This document specifies the Static Provision of Multicast route as an

alternate to Layer 3 Multicast protocols like PIM-SM (Protocol
Independent Multicast - Sparse Mode), PIM SSM (Source-Specific
Multicast), or PIM BIDI (Bidirectional). Unlike the other Multicast
Routing protocols, this feature does not depend on Unicast Routing
Protocols to build the Multicast tree. It works like a standalone
Multicast Route provisioning feature that can interoperate with other
dynamic Multicast protocols like PIM-SM or with L2 protocols like
IGMP (Internet Group Management Protocol) and MLD (Multicast Listener
Discovery).

"IS-IS extensions for BIER-TE (Tree Engineering for Bit Index Explicit
Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua
Wei, BenChong Xu, 2022-07-24, <draft-zwx-bier-te-isis-extensions-01.txt>

This document describes the IS-IS protocol extension that is required

for BIER-TE with MPLS and non-MPLS encapsulation.

"OSPFv2 extensions for BIER-TE (Tree Engineering for Bit Index Explicit
Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua
Wei, BenChong Xu, 2022-07-05, <draft-zwx-bier-te-ospf-extensions-00.txt>

This document describes the OSPF protocol extension that is required

 for BIER-TE with MPLS and non-MPLS encapsulation.

"OSPFv3 extensions for BIER-TE (Tree Engineering for Bit Index Explicit
Replication) with MPLS and non-MPLS Encapsulation", Zheng Zhang, Yuehua
Wei, BenChong Xu, 2022-07-24, <draft-zwx-bier-te-ospfv3-extensions-01.txt>

This document describes the OSPFv3 protocol extension that is

required for BIER-TE with MPLS and non-MPLS encapsulation.

"Path MTU (PMTU) for Segment Routing Policy", Shuping Peng, Dhruv Dhody,
Ketan Talaulikar, Gyan Mishra, 2022-07-05,
<draft-peng-spring-pmtu-sr-policy-00.txt>

This document defines the Path MTU (PMTU) for SR Policy (called SR-
PMTU) and it applies to both SRv6 and SR-MPLS. The framework of SR-
PMTU for SR Policy is specified, including link MTU collection, SR-
PMTU Computation, SR-PMTU Enforcement, and Handling behaviors on the
headend.

"MPLS Network Action (MNA) Header Encodings", Jaganbabu Rajamanickam,

Rakesh Gandhi, Jisu Bhattacharya, Bruno Decraene, Royi Zigler, Weiqiang
Cheng, Luay Jalil, Haoyu Song, Xiao Min, Bin Wen, Sami Boutros, 2022-07-25,
<draft-jags-mpls-mna-hdr-01.txt>

This document defines the MPLS Network Action (MNA) Header encoding
formats to carry Network Actions and optionally Ancillary Data in the
MPLS Label Stack and after the Label Stack. The MPLS Network Action
can influence the forwarding decisions or can carry additional OAM
information in the MPLS packet. This document follows the MNA
requirements specified in draft-ietf-mpls-mna-requirements.

"Early Data Option for CoAP", Hannes Tschofenig, Thomas Fossati,

2022-07-06, <draft-tschofenig-core-early-data-option-00.txt>

This document defines mechanisms that allow clients to communicate

with servers about CoAP requests that are sent in early data.
Techniques are described that use these mechanisms to mitigate the
risk of replay.

"Destination/Source Routing", David Lamparter, Anton Smirnov, Jen Linkova,

Shu Yang, 2022-07-06, <draft-llsyang-rtgwg-dst-src-routing-00.txt>

This note specifies using packets' source addresses in route lookups

as additional qualifier to be used in hop-by-hop routing decisions.
This applies to IPv6 [RFC2460] in general with specific
considerations for routing protocol left for separate documents.
There is nothing precluding similar operation in IPv4, but this is
not in scope of this document.

Note that destination/source routing, source/destination routing,

SADR, source-specific routing, source-sensitive routing, S/D routing
and D/S routing are all used synonymously.

"Passive Probing for Path MTU Discovery with QUIC", Pyung Kim, 2022-07-06,
<draft-pskim-passive-probing-pmtud-00.txt>

This draft consider an alternative PMTUD for QUIC. To discover the

best PMTU, the passive probing approach is adopted. The process of
discovering the best PMTU is not carried out separately, but is
 carried out simultaneously in the actual application data
communication. A probe packet is defined newly using 1-RTT packet
which includes actual application data as well as a short packet
header and a PING_EXT frame. The PING_EXT frame is also defined
newly. Until the best PMTU is discovered, the size of the probe
packet is changed according to the size of the PMTU candidate. A
simple discovery algorithm using only the PMTU candidate sequence
with linear upward is described in this draft. Other rather complex
discovery algorithms that consider various PMTU candidate sequences
will be dealt with in the future.

"Proxying Listener UDP in HTTP", David Schinazi, 2022-07-06,

<draft-schinazi-connect-udp-listen-00.txt>

The mechanism to proxy UDP in HTTP only allows each proxying request
to transmit to a specific host and port. This is well suited for UDP
client-server protocols such as HTTP/3, but is not sufficient for
some UDP peer-to-peer protocols like WebRTC. This document proposes
an extension to UDP Proxying in HTTP that enables those use-cases.

"IGP Flexible Algorithm with Common Address", Zhibo Hu, Guoqi Xu, Jie Dong,
2022-07-07, <draft-hu-lsr-igp-ca-flex-algorithm-00.txt>

An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute

constraint-based paths. IGP Flex-Algorithm can be used with Segment
Routing (SR) or IP data plane. When used with SR data plane, Flex-
Algorithm requires to allocate algorithm specific Prefix Segment
Identifiers (SIDs) or algorithm specific SRv6 Locators. When used
with IP data plane, Flex-Algorithm requires to allocate algorithm
specfic IPv4 or IPv6 prefixes. This increases the complexity and
overhead of managing, advertising and maintaining additional SR SIDs,
SRv6 Locators and IPv4 or IPv6 prefixes, which may not be affordable
to some networks and network devices.

This document extends IGP Flex-Algorithm to allow the use of common

SR SIDs, SRv6 Locators and IP prefixes among multiple Flex-
Algorithms.

"IGP Flexible Algorithms Reverse Affinity Constraint", Peter Psenak, Jakub

Horn, Amit Dhamija, 2022-07-07,
<draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-00.txt>

An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute

constraint-based paths.

This document extends IGP Flex-Algorithm with additional constraints.

"Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)",

Michael Tuexen, Randall Stewart, Peter Lei, Eric Rescorla, 2022-07-08,
<draft-tuexen-tsvwg-rfc4895-bis-02.txt>

This document describes a new chunk type, several parameters, and

procedures for the Stream Control Transmission Protocol (SCTP). This
new chunk type can be used to authenticate SCTP chunks by using
shared keys between the sender and receiver. The new parameters are
used to establish the shared keys.

"Stub Router Flag in ICMPv6 Router Advertisement Messages", Jonathan Hui,

2022-07-07, <draft-hui-stub-router-ra-flag-00.txt>
 This document defines a new Stub Router flag in the Router
Advertisement message to distinguish configuration information sent
by stub routers from infrastructure routers. For example, the Stub
Router flag allows stub routers to easily identify when an
infrastructure router is advertising a usable IPv6 prefix, triggering
the stub router to not advertise its own routable prefix.

"OCN Use Cases for Industry control Networks", Cedric Westphal, Kiran
Makhijani, Kapal Dev, Luca Foschini, 2022-07-07,
<draft-wmdf-ocn-use-cases-00.txt>

This document present industrial networking use cases for Operations

and Control Networks (OCN). It is a companion document to the OCN
reference model and the OCN problem statement and requirements
document. This document compiles a list of potential use cases where
new industrial networking protocols could be beneficial.

"Export of Forwarding Path Delay in IPFIX", Thomas Graf, Benoit Claise,

Alex Feng, 2022-07-28, <draft-tgraf-opsawg-ipfix-inband-telemetry-01.txt>

This document introduces new IP Flow Information Export (IPFIX)

information elements to expose the Inband Telemetry measured
forwarding path delay on the IOAM transit and decapsulation nodes.

"Terminology for Post-Quantum Traditional Hybrid Schemes", Florence D,

2022-07-08, <draft-driscoll-pqt-hybrid-terminology-00.txt>

One aspect of the transition to post-quantum algorithms in

cryptographic protocols is the development of hybrid schemes that
incorporate both post-quantum and traditional asymmetric algorithms.
This document defines terminology for such schemes. It is intended
to ensure consistency and clarity across different protocols,
standards, and organisations.

"Overlay Routing Problem Statement", Shangling Deng, Geng Li, Yong Cui,
2022-07-08, <draft-deng-overlay-routing-ps-00.txt>

This document considers the limitations of existing technologies in

addressing the challenges of low network latency. It analyzes the
problem of signaling redundancy on control plane and problem of non-
global optimal path selection policy for overlay network and explores
possible solutions.

"Dynamic-Anycast (Dyncast) Gap analysis and Requirements", Peng Liu, Tianji

Jiang, Philip Eardley, Dirk Trossen, Cheng Li, 2022-07-08,
<draft-liu-dyncast-gap-reqs-00.txt>

This document provides gap analysis and requirements for the problems
and use cases that champion the joint optimization of both network
and computing resources as outlined in[I-D.liu-dyncast-ps-usecases].
It also identifies the key engineering investigation areas which
require adequate architectures and protocols to achieve balanced
computing and networking resource utilization among facilities
providing the services.

"Usecases of SRv6 Based Computing Interconnection Network", Xiaoqiu Zhang,

Feng Yang, Weiqiang Cheng, Zhihua Fu, 2022-07-08,
<draft-zhang-rtgwg-srv6-computing-connect-usecases-00.txt>
 The requirements of computing interconnection are increasingly
attracting the attention of service providers. They have been thinking
about how to leverage their network advantages to provide integrated
networking and computing services. This document describes some
scenarios of using SRv6 based network technology which can partially
meet the service requirement of computing interconnection.

"SRv6 Underlay tunnel Programming", Liuyan Han, Minxue Wang, Ran Chen,
Aihua Liu, 2022-07-08,
<draft-han-spring-srv6-underlay-tunnel-programming-00.txt>

This document defines a new SRv6 Endpoint behavior which can be used
for SRv6 underlay tunnel (e.g.L1 channel) Programming, called
END.BXC, this behavior are used to bind an underlay tunnel.

"Cryptographically Generated Addresses (CGA) Light", Eduard, 2022-07-08,

<draft-ev-6man-cga-light-00.txt>

This document specifies a method for securely associating link-layer

addresses (MAC) to the IPv6 address by a cryptography method similar
to blockchain mining.
It permits guarantee security at the IPv6 layer to the same degree
as at the link layer (that node is dependent on anyway).

"Algorithms and Identifiers for Post-Quantum Algorithms", Jake Massimo,

Panos Kampanakis, Sean Turner, Bas Westerbaan, 2022-07-08,
<draft-massimo-lamps-pq-sig-certificates-00.txt>

Digital signatures are used within X.509 certificates, Certificate

Revocation Lists (CRLs), and to sign messages. This document
describes the conventions for using Dilithium quantum-resistant
signatures in Internet X.509 certificates and certifiate revocation
lists. The conventions for the associated post-quantum signatures,
subject public keys, and private key are also described.

"METADATA frame for HTTP/2 and HTTP/3", Bence Beky, Biren Roy, 2022-08-01,
<draft-beky-httpbis-metadata-02.txt>

This document describes a mechanism to send meta information over

HTTP/2 and HTTP/3 connections that refers to either the entire
connection or a specific stream without changing the semantics of the
HTTP messages. This mechanism can be used, for example, to gather
information for accounting or logging purposes.

"IGP Monitoring Protocol (IMP)", Robert Raszuk, 2022-07-08,

<draft-raszuk-lsr-imp-00.txt>

This document defines a new point to point protocol to carry

information present in link state database of OSPF and ISIS Interior
Gateway Protocols (IGPs) as well as in Traffic Engineering Database
(TED).

"The BBS Signature Scheme", Tobias Looker, Vasilis Kalos, Andrew Whitehead,
Mike Lodder, 2022-07-08, <draft-looker-cfrg-bbs-signatures-01.txt>

BBS is a digital signature scheme categorized as a form of short

group signature that supports several unique properties. Notably,
the scheme supports signing multiple messages whilst producing a
 single output digital signature. Through this capability, the
possessor of a signature is able to generate proofs that selectively
disclose subsets of the originally signed set of messages, whilst
preserving the verifiable authenticity and integrity of the messages.
Furthermore, these proofs are said to be zero-knowledge in nature as
they do not reveal the underlying signature; instead, what they
reveal is a proof of knowledge of the undisclosed signature.

"Hierarchical segment routing solution of CAN", Daniel Huang, Zongpeng Du,

Chen Zhang, 2022-07-08,
<draft-huang-two-segment-routing-solution-of-can-00.txt>

CAN (Computing Aware Network) is designed to enable the routing

network to be aware of computing status thus deliver the service flow
accordingly. Nevertheless, computing and networking is quite
different in terms of resource granularity as well as its status
stability. It would gain significant benefits to accommodate the
computing status to that of networking by employing a hierarchical
computing routing segment scheme. The network-accommodated computing
status could be maintained at remote CAN nodes while the rest could
reside at local CAN nodes. By enabling the network to schedule and
route computing services in a compatible way with the current IP
routing network, CAN would bring benefits to the industry by both
efficiently pooling the computing resources and rendering services
through perspective of converged networking and computing.

"Encapsulation of BFD for SRv6 Policy", Yisong Liu, Weiqiang Cheng,

Changwang Lin, Mengxiao Chen, Xiao Min, 2022-07-11,
<draft-liu-bfd-srv6-policy-encap-01.txt>

Bidirectional Forwarding Detection (BFD) mechanisms can be used for

fast detection of failures in the forwarding path of SR Policy. This
document describes the encapsulation of BFD for SRv6 Policy, which
can be applied for both S-BFD and U-BFD. The BFD packets may be
encapsulated in transport mode or tunnel mode.

"Ensuring CDS/CDNSKEY Consistency is Mandatory", Peter Thomassen,

2022-07-09, <draft-thomassen-dnsop-cds-consistency-00.txt>

For maintaining DNSSEC Delegation Trust, DS records have to be kept

up to date. [RFC7344] automates this by having the child publish CDS
and/or CDNSKEY records which hold the prospective DS parameters.
Parent-side entities (e.g. Registries, Registrars) can use these
records to update the delegation's DS records. A common method for
detecting changes in CDS/CDNSKEY record sets is to query them
periodically from the child zone ("polling"), as described in
Section 6.1 of [RFC7344].

This document specifies that if polling is used, parent-side entities

MUST ensure that CDS/CDNSKEY record sets are equivalent across all of
the child's authoritative nameservers, before taking any action based
on these records.

"Use Cases for Parent SR Policy", Jiang Wenying, Weiqiang Cheng, Changwang
Lin, Yuanxiang Qiu, 2022-07-09,
<draft-jiang-spring-parent-sr-policy-use-cases-00.txt>

Segment Routing is a source routing paradigm that explicitly

indicates the forwarding path for packets at the ingress node. An SR
 Policy is associated with one or more candidate paths, and each
candidate path is dynamic, explicit or composite. This document
illustrates some use cases for parent SR policy in MPLS and IPv6
environment.

"Intra-domain SAVNET method", Changwang Lin, Yuanxiang Qiu, 2022-07-09,

<draft-lin-savnet-lsr-intra-domain-method-00.txt>

This document proposes a method of Source Address Validation in

Intra-domain, which can be applied to OSPF and IS-IS protocols. By
extending IGP and adding the protocol calculation procedure, the SAV
information can be accurately calculated to realize the source
address verification.

"Network Resource Partition Identifier (NRP-ID) in SRv6 segment", Yisong

Liu, Changwang Lin, Hao Li, Liyan Gong, 2022-07-09,
<draft-liu-spring-nrp-id-in-srv6-segment-00.txt>

This document proposes a method to carry the Network Resource

Partition Identifier (NRP-ID) with the packet in the SRv6 segment.

"Considerations about Generalized IETF Network Slicing", Zhenbin Li, Jie

Dong, 2022-07-10, <draft-li-teas-generalized-ietf-network-slicing-00.txt>

IETF network slice has been introduced to meet specific service

requirements, such as the connectivity requirements and the
associated network capabilities such as bandwidth, latency, jitter
and network functions with the resource behaviors such as computing
and storage availability.

For the realization of IETF network slices, one or more network

resource partitions (NRPs) can be created in the network. Each NRP
is a collection of network resources (buffer, queuing, scheduling,
etc.) allocated in the underlay network. The connectivity constructs
from one or more IETF network slices can be mapped to an NRP. NRP
specific identifiers could be carried in the IETF network slice
packets, which could be used to determine the set of network
resources to be used for the processing and forwarding of the packets
in the corresponding NRP.

With the development of IETF network slicing technologies and the

deployment of IETF network slices in different types of networks,
there are emerging requirements about the new capability and
functionality of IETF network slices. To meet those requirements, it
is expected that the concept IETF network slice and NRP needs be
generalized.

This document describes the considerations about possible

generalization of IETF network slice and NRP.

"Segment Routing based Solution for Hierarchical IETF Network Slices",

Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Jie Dong, Ran
Chen, Yanrong Liang, 2022-07-10,
<draft-gong-teas-hierarchical-slice-solution-00.txt>

This document describes a Segment Routing based solution for two-

level hierarchical IETF network slices. Level-1 network slice is
realized by associating Flex-Algo with dedicated sub-interfaces, and
level-2 network slice is realized by using SR Policy with additional
 NRP-ID on data plane.

"Source Address Validation in Intra-domain Networks (Intra-domain SAVNET)

Gap Analysis, Problem Statement and Requirements", Dan Li, Jianping Wu,
Lancheng Qin, Mingqing Huang, Nan Geng, 2022-07-10,
<draft-li-savnet-intra-domain-problem-statement-00.txt>

Source Address Validation in Intra-domain Networks (Intra-domain

SAVNET) aims to make improvements to existing intra-domain Source
Address Validation (SAV). This document provides the gap analysis of
existing intra-domain SAV mechanisms, describes the fundamental
problems, and defines the requirements for improvements.

"Source Address Validation in Inter-domain Networks (Inter-domain SAVNET)

Gap Analysis, Problem Statement and Requirements", Jianping Wu, Dan Li,
Lancheng Qin, Mingqing Huang, Nan Geng, 2022-07-10,
<draft-wu-savnet-inter-domain-problem-statement-00.txt>

Source Address Validation in Inter-domain Networks (Inter-domain

SAVNET) focuses on narrowing the technical gaps of existing source
address validation (SAV) mechanisms in inter-domain scenarios. This
document provides a gap analysis of existing SAV efforts, describes
the problem statement based on the analysis results, and concludes
the requirements for improving inter-domain SAV.

"BGP Flowspec for IETF Network Slice Traffic Steering", Jie Dong, Subin
Wang, Jiang Wenying, 2022-07-10,
<draft-dong-idr-flowspec-network-slice-ts-00.txt>

BGP Flow Specification (Flowspec) provides a mechanism to distribute

traffic flow specifications and the forwarding actions to be
performed to the specific traffic flows. A set of Flowspec
components are defined to specify the matching criteria that can be
applied to the packet, and a set of BGP extended communities are
defined to encode the actions a routing system can take on a packet
which matches the flow specification.

An IETF Network Slice enables connectivity between a set of Service

Demarcation Points (SDPs) with specific Service Level Objectives
(SLOs) and Service Level Expectations (SLEs) over a common underlay
network. To meet the connectivity and performance requirement of
specific network slice services, network slice service traffic needs
to be mapped to an Network Resource Partition (NRP). The edge nodes
of the NRP needs to identify the traffic flows which belong to a
network slice and steer the matched traffic to the corresponding NRP
or a specific path within the corresponding NRP.

BGP Flowspec can be used to distribute the matching criteria and the
forwarding actions to be preformed on specific network slice
services. The existing Flowspec components can be used for the
matching of specific network slice services flows at the edge of an
NRP. While new traffic action needs to be defined for the steering
of network slice service flows into an NRP. This document defines
the extensions to BGP Flowspec for IETF network slice traffic
steering (NS-TS).

"RAW multidomain extensions", Carlos Bernardos, Alain Mourad, 2022-07-10,

<draft-bernardos-detnet-multidomain-00.txt>
 This document addresses the multi-domain DetNet problem, analyzing
what the technical gaps are and exploring some possible solutions.
Application, control and data plane aspects are in scope. The goal
is to help understanding what might be the next steps towards
enabling DetNet in multi technology and/or administrative domains.

"BGP Entropy Label Capability, Version 3", John Scudder, Kireeti Kompella,
satyamoh@cisco.com, Jim Uttaro, Bin Wen, 2022-08-18,
<draft-scudder-idr-entropy-label-01.txt>

This specification defines the Entropy Label Capability Attribute

version 3 (ELCv3), a BGP attribute that can be used to inform an LSP
ingress router about an LSP egress router's ability to process
entropy labels. This version of the attribute corrects a
specification error in the first version, and an improper code point
reuse in the second.

"Data Collection Requirements and Technologies for Digital Twin Network",

Cheng Zhou, Danyang Chen, Pedro Martinez-Julia, 2022-07-10,
<draft-zcz-nmrg-digitaltwin-data-collection-00.txt>

The Digital Twin Network is a network system with Physical Network

and Twin Network, which can be mapped interactively in real time.
The construction of Digital Twin Network requires real-time data of
Physical Network to update the state of Twin Network. This document
aims to describe the data collection requirements and provide data
collection methods or tools to build the data repository for digital
twin network.

"Transporting IP/UDP Payload-only in VPNs", Zhaohui Zhang, Keyur Patel,

2022-07-10, <draft-zzhang-bess-ipvpn-payload-only-00.txt>

This document specifies an option for IP-VPN to transport IP/UDP

payload only, without transporting IP/UDP headers, which are removed
by an ingress PE and re-added by an egress PE.

"Generalized IPv6 Tunnel (GIP6)", Zhenbin Li, Shuanglong Chen, Haibo Wang,
2022-07-10, <draft-li-rtgwg-generalized-ipv6-tunnel-00.txt>

This document defines the generalized IPv6 tunnel based on the

analysis of challenges of the existing problems of IP tunnels.

"Generalized Arguments of SRv6 Segment", Zhenbin Li, Jianwei Mao, Cheng Li,
2022-07-10, <draft-lm-spring-srv6-generalized-arguments-00.txt>

This document analyzes the challenges of Arguments of SRv6 SID, and

the chance of using Arguments of SRv6 SID to reduce the length of the
IPv6 extension header. According to these analysis, this document
specifies a kind of generalized and structured Arguments for SRv6
SID, which can carry multiple Arguments parts for a SRv6 SID.

"DetNet Enhanced Data Plane", Fan Yang, Tianran Zhou, Li Zhang, 2022-07-10,
<draft-yzz-detnet-enhanced-data-plane-00.txt>

Aiming at providing the bounded latency to DetNet services, DetNet

data plane is required to be enhanced. This document provides a
method to extend DetNet data plane by introducing the Bounded Latency
Information (BLI), which facilitates DetNet transit nodes to
guarantee the bounded latency transmission in data plane.
"Research Challenges in Coupling Artificial Intelligence and Network
Management", Jerome Francois, Alexander Clemm, Dimitri Papadimitriou,
Stenio Fernandes, Stefan Schneider, 2022-07-10,
<draft-francois-nmrg-ai-challenges-00.txt>

This document is intended to introduce the challenges to overcome

when network management problems may require to be couple with AI
solutions. On one hand, there are many difficult problems in Network
Management that to this date have no good solutions, or where any
solutions come with significant limitations and constraints.
Artificial Intelligence may help produce novel solutions to those
problems. On the other hand, for several reasons (computational
costs of AI solutions, privacy of data), distribution of AI tasks
became primordial. It is thus also expected that network SHOULD be
operated efficiently to support those tasks.

To identify the right set of challenges, the document defines a

method based on the evolution and nature of NM problems. This will
be done in parallel with advances and the nature of existing
solutions in AI in order to highlight where AI and NM have been
already coupled together or could benefit from a higher integration.
So, the method aims at evaluating the gap between NM problems and AI
solutions. Challenges are derived accordingly, assuming solving
these challenges will help to reduce the gap between NM and AI.

"Segment Routing for Enhanced DetNet", Xuesong Geng, Zhenbin Li, Tianran
Zhou, 2022-07-11, <draft-geng-spring-sr-enhanced-detnet-00.txt>

One of the goals of DetNet is to provide bounded end-to-end latency

for critical flows. This document defines how to leverage Segment
Routing(SR) and Segment Routing over IPv6 (SRv6) to implement bounded
latency. Specifically, new SRv6 SID function is used to specify
bounded latency information for a packet. When forwarding devices
along the path follow the instructions carried in the packet, the
bounded latency is achieved by different implementations based on
bounded latency information.

"IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID", Changwang Lin,
Mengxiao Chen, Hao Li, 2022-07-11, <draft-lin-lsr-srv6-service-sid-00.txt>

The IPv6 backbone networks only deploying IGP may be required to

interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be
used to realize such requirements. This document extends IS-IS and
OSPFv3 to advertise SRv6 Service SIDs.

"A YANG Data Model for Alternate Marking Method", Minxue Wang, Liuyan Han,
Xiao Min, Guo Jun, 2022-07-11, <draft-wang-ippm-alt-mark-yang-00.txt>

Alternate-Marking Method (AMM) is a technique used to perform packet

loss, delay, and jitter measurements on live traffic. This document
defines a YANG data model for Alternate Marking Method.

"Define the Value 255 in Last Entry field of Segment Routing Header",
Tianran Zhou, Jingrong Xie, 2022-07-11,
<draft-zhou-spring-srh-le-change-00.txt>

This document proposes to define the value 255 in Last Entry field in
Segment Routing Header (SRH) [RFC8754], to indicate an SRH without
 any SID left.

"Network Resource Programming with SRv6", Weiqiang Cheng, Jiang Wenying,

Ran Chen, Detao Zhao, Changwang Lin, 2022-07-11,
<draft-cheng-spring-srv6-resource-programming-00.txt>

This document defines a new SRv6 network function which can be used
for SRv6 Network Resource Programming. A new SRv6 Endpoint behavior
is used to associate with a set of network resource partition,
called End.NRP. By using the End.NRP SID , the SRv6 policy can
provide the capability of network resources programming.

"Genralized IPv6 Tunnel for MPLS", Zhenbin Li, Jie Dong, Shuanglong Chen,
2022-07-11, <draft-li-mpls-gip6-mpls-00.txt>

With the development of new services, MPLS faces many problems and
technical challenges. This document defines the method to implement
MPLS through the GIP6 tunnel.

"Computing Resource Modeling for CAN", Peng Liu, Zongpeng Du, Lanlan Rui,
Wenjing Li, Cheng Li, Daniel Huang, 2022-07-11,
<draft-liu-can-computing-resource-modeling-00.txt>

This document describes the considerations and potential architecture

of modeling the computing resource in the Computing-Aware
Network(CAN).

Moreover, the network and application based modeling are also

presented in this document to meet the potential requirements of
integrated and hierarchical modeling.

"Internet Addressing Considerations", Yihao Jia, Dirk Trossen, Luigi

Iannone, Paulo Mendes, Nirmala Shenoy, Laurent Toutain, Abraham Chen, Dino
Farinacci, 2022-07-11,
<draft-iannone-internet-addressing-considerations-00.txt>

There exist many extensions to Internet addressing, as it is defined

in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively. Those
extensions have been developed to evolve the addressing capabilities
beyond the basic properties of Internet addressing. This document
outlines those properties as a baseline against which the extensions
are categorized in terms of methodology used to extend the addressing
model, together with examples of solutions doing so.

While introducing such extensions, we outline the shortcomings we see

with those extensions. This ultimately leads to consider whether or
not a more consistent approach to tackling the identified use cases,
beyond point-wise extensions as done so far, would be beneficial.
The benefits are the ones detailed in the companion document
[I-D.jia-intarea-scenarios-problems-addressing], where, leveraging on
the shortcomings identified in this memo and scenarios provided in
[I-D.jia-intarea-scenarios-problems-addressing], a clear problem
statement is provided.

"Control Options For DNS Client Proxies", Philip Homburg, 2022-07-11,

<draft-homburg-add-codcp-00.txt>

The introduction of many new transport protocols for DNS in recent

years (DoT, DoH, DoQ) significantly increases the complexity of DNS
 stub resolvers that want to support these protocols. A practical way
forward is to have a DNS client proxy in the host operating system.
This allows applications to communicate using Do53 and still get the
privacy benefit from using more secure protocols over the internet.
However, such a setup leaves the application with no control over
which transport the proxy uses. This document introduces EDNS(0)
options that allow a stub resolver to request certain transport and
allow the proxy to report capabilities and actual transports that are
available.

"Advertising Redundancy Policy in BGP", Fan Yang, Xuesong Geng, Tianran

Zhou, 2022-07-11, <draft-yang-idr-bgp-redundancy-policy-00.txt>

Redundancy Protection is a generalized protection mechanism by

replicating and transmitting copies of flow packets on redundancy
node over multiple different and disjoint paths, and further
eliminating the redundant packets at merging node. In order to
support the replication behavior of redundancy protection, Redundancy
Policy is used to instruct the replication of service packets and
assign more than one redundancy forwarding paths. This document
defines the extensions to BGP to advertise the redundancy policy.

"SR Policy for enhanced DetNet", Li Zhang, Xuesong Geng, Zhenbin Li,
2022-07-11, <draft-zhang-sr-policy-enhanced-detnet-00.txt>

SR Policy is a set of candidate SR paths consisting of one or more

segment lists and necessary path attributes. It enables
instantiation of an ordered list of segments with a specific intent
for traffic steering. DetNet provides the capability to carry
specified unicast or multicast data flows with extremely low data
loss rates and bounded end-to-end latency within a network domain.
This document defines the SR policy enhancement to carry the Bounded
Latency Information with a candidate path of SR policy. So that BLI
behavior can be enabled automatically when the SR Policy is applied.

"PCEP for Enhanced DetNet", Li Zhang, Xuesong Geng, Tianran Zhou,

2022-07-11, <draft-zhang-pce-enhanced-detnet-00.txt>

PCEP is used to provide a communication between a PCC and a PCE.

This document defines the extensions to PCEP to support the bounded-
latency path computation. Specifically, two new objects and three
new TLVs are defined for the transmission of bounded latency
information between PCC and PCE to guarantee the bounded latency
transmission in control plane.

"Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for

Constrained Environments (OSCORE) Profile for Authentication and
Authorization for Constrained Environments (ACE)", Goeran Selander, John
Mattsson, Marco Tiloca, Rikard Hoeglund, 2022-07-11,
<draft-selander-ace-edhoc-oscore-profile-00.txt>

This document specifies a profile for the Authentication and

Authorization for Constrained Environments (ACE) framework. It
utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
mutual authentication between an OAuth 2.0 Client and Resource
Server, and it binds an authentication credential of the Client to an
OAuth 2.0 access token. EDHOC also establishes an Object Security
for Constrained RESTful Environments (OSCORE) Security Context, which
is used to secure communications when accessing protected resources
 according to the authorization information indicated in the access
token. A resource-constrained server can use this profile to
delegate management of authorization information to a trusted host
with less severe limitations regarding processing power and memory.

"ISIS-TE Extensions for Enhanced DetNet", Xuesong Geng, Zhenbin Li, Tianran
Zhou, 2022-07-11, <draft-geng-lsr-isis-te-extension-enhanced-detnet-00.txt>

This document defines extensions to ISIS to distribute the enhanced

DetNet information at node and/or link granularity.

"BGP - Link State (BGP-LS) Advertisement of IGP DetNet Extensions", Xuesong

Geng, Zhenbin Li, Tianran Zhou, 2022-07-11,
<draft-geng-idr-bgp-ls-enhanced-detnet-00.txt>

This document defines extensions to BGP-LS to distribute the enhanced

DetNet information

"IGP Extensions for Advertising Node Index", Huaimo Chen, Donald Eastlake,
Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu,
2022-07-11, <draft-chen-lsr-adv-ni-00.txt>

This document describes OSPF and IS-IS extensions for distributing

the node index configured on a node.

"IGP Extensions for Advertising Link Numbers", Huaimo Chen, Donald

Eastlake, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng
Liu, 2022-07-11, <draft-chen-lsr-adv-lkno-00.txt>

This document describes OSPF and IS-IS extensions for distributing

the link numbers assigned to the links originating at a node.

"Stateless Best Effort Multicast Using MRH", Huaimo Chen, Donald Eastlake,
Mike McBride, Yanhe Fan, Gyan Mishra, Yisong Liu, Aijun Wang, Xufeng Liu,
Lei Liu, 2022-07-11, <draft-chen-pim-be-mrh-00.txt>

This document describes stateless best effort Multicast along the

shortest paths to the egress nodes of a P2MP Path/Tree. The
multicast data packet is encapsulated in an IPv6 Multicast Routing
Header (MRH). The MRH contains the egress nodes represented by the
indexes of the nodes and flexible bit strings for the nodes. The
packet is delivered to each of the egress nodes along the shortest
path. There is no state stored in the core of the network.

"L2VPN VPWS Seamless with EVPN VPWS over SRv6", fuzheng, Tong Zhu,
renhuajun, 2022-07-11, <draft-fu-bess-evpn-vpws-seamless-00.txt>

This document provides a solution for migrating L2VPN virtual private

wire service(VPWS) to Ethernet VPN Virtual Private wire service
(EVPN-VPWS) over SRv6. The service provider may want to migrate
L2VPN VPWS to EVPN-VPWS, and deploy EVPN-VPWS over SRv6 network.
When co-existing of EVPN-VPWS over SRv6 network and a legacy L2VPN
VPWS over MPLS/IP network, the next hop of the EVPN Ethernet-AD per
EVI route is different from the nexthop of VPWS AD routes or the
source of LDP-LM message of the legacy L2VPN VPWS. As a result,
whether the pseudowire of the EVPN VPWS and legacy L2VPN VPWS is same
cannot be identified by the next hop of the EVPN Ethernet-AD per EVI
route and VPWS AD routes or LDM messages. This document provides a
solution to identify whether the pseudowire of EVPN VPWS is same with
 the pseudowire of L2VPN VPWS, which allows migrating VPWS to EVPN-
VPWS under the same vpn instance but over different network.

"Architecture of Computing Power Optical Network", Zhengjie Sun,

4875690059616E67, Chao Li, Sheng Liu, Haomian Zheng, 2022-07-11,
<draft-sun-alto-arch-computing-optical-network-01.txt>

This document describes the architecture of computing power optical

network.

"Design Consideration of IPv6 Multicast Source Routing (MSR6)", Weiqiang

Cheng, Gyan Mishra, Zhenbin Li, Aijun Wang, Zhuangzhuang Qin, Chi Fan,
2022-07-11, <draft-cheng-msr6-design-consideration-00.txt>

This document discusses the design consideration of IPv6 source

routing multicast solution.

"Distributed Learning Architecture based on Edge-cloud Collaboration", Chao

Li, 4875690059616E67, Zhengjie Sun, Sheng Liu, Haomian Zheng, 2022-07-11,
<draft-li-coinrg-distributed-learning-architecture-00.txt>

This document describes the distributed learning architecture based

on edge-cloud collaboration.

"BGP Usage for 5G Edge Computing Service Metadata", Linda Dunbar, Kausik
Majumdar, Haibo Wang, Gyan Mishra, 2022-07-11,
<draft-dunbar-idr-5g-edge-compute-bgp-usage-00.txt>

This draft describes the problems in the 5G Edge computing

environment and how BGP can be used to propagating additional
information, so that the ingress routers in the 5G Local Data
Network can make path selection not only based on the routing
distance but also the running environment of the destinations.
The goal is to improve latency and performance for 5G EC
services.

"SCION Components Analysis", Nicola Rustignoli, Corine de Kater,

2022-08-26, <draft-rustignoli-panrg-scion-components-01.txt>

SCION is an inter-domain Internet architecture that focuses on

security and availability. Its fundamental functions are carried out
by a number of components.

This document analyzes its core components from a functionality

perspective, describing their dependencies, outputs, and properties
provided. The goal is to answer the following questions:

* What are the main components of SCION and their dependencies? Can

"Path Computation Element Communication Protocol (PCEP) Extensions to

Redundancy Policy", Fan Yang, Xuesong Geng, Tianran Zhou, 2022-07-11,
<draft-yang-pce-pcep-redundancy-policy-00.txt>

PCEP is used to provide a communication between a PCC and a PCE.

This document defines the extensions to PCEP to support the
redundancy paths computation. Specifically, two new TLVs are defined
to support the request of redundancy path computation and protection
method, and one TLV is defined to distribute the Candidate Path Flag
of an SR Policy.
"EAP defaults for devices that need to onboard", Alan DeKok, Michael
Richardson, 2022-07-25, <draft-richardson-emu-eap-onboarding-01.txt>

This document describes a method by which an unconfigured device can

use EAP to join a network on which further device onboarding, network
attestation or other remediation can be done. While RFC 5216
supports EAP-TLS without a client certificate, that document defines
no method by which unauthenticated EAP-TLS can be used. This draft
addresses that issue. First, by defining the @eap.arpa domain, and
second by showing how it can be used to provide quarantined network
access for onboarding unauthenticated devices.

"IETF and Energy - An Overview", Toerless Eckert, Mohamed Boucadair, Pascal

Thubert, Jeff Tantsura, 2022-07-11,
<draft-eckert-ietf-and-energy-overview-03.txt>

This memo provides an overview of work performed by or proposed

within the IETF related to energy and/or green: awareness,
management, control or reduction of consumption of energy, and
sustainability as it related to the IETF.

This document is written to help those unfamiliar with the work but
interested in it, in the hope to raise more interest in energy-
related activities within the IETF, such as identifying gaps and
investigating solutions as appropriate.

"A Performance-Oriented Digital Twin for Carrier Networks", Jordi

Paillisse, Paul Almasan, Miquel Ferriol, Pere Barlet, Albert Cabellos,
Shihan Xiao, Xiang Shi, Xiangle Cheng, Diego Perino, Diego Lopez, Antonio
Pastor, 2022-07-11, <draft-paillisse-nmrg-performance-digital-twin-00.txt>

This draft introduces the concept of a Network Digital Twin (NDT) for
performance evaluation. A Performance NDT is able to produce
performance estimates (delay, jitter, loss) of a given input network
with a specific topology, traffic demand, and routing and scheduling
configuration. Also, this draft discusses the interface of the
digital twin, how it relates to existing control plane elements, use
cases, and possible implementation options.

"Mobility challenges in virtualization environments", Carlos Bernardos,

Alain Mourad, 2022-07-11,
<draft-bernardos-dmm-mobility-virtualization-00.txt>

Mobility is no longer restricted to physical end systems roaming

among radio points of attachment. Current mobile network deployments
do not only consider the traditional client-server model, but also
include scenarios in which services are decomposed into functions
that run on virtualized resources, thus becoming virtual functions.
This opens the door for new scenarios in which mobility now includes:
(i) the end-system mobility (traditional scenario), (ii) a physical
resource hosting a virtual function (part of a service being consumed
by a end-system) moving, and (iii) a virtual function part of a
service moving (migrating) to a different physical resource. As
these scenarios are expected to be more commonly deployed in the
short future, this documents aims at presenting the new mobility-
related scenarios and the potential gaps in terms of IETF protocols.

"Using Attestation in Transport Layer Security (TLS) and Datagram Transport

Layer Security (DTLS)", Hannes Tschofenig, Thomas Fossati, Paul Howard,
Ionut Mihalcea, Yogesh Deshpande, 2022-08-26,
<draft-fossati-tls-attestation-01.txt>

Various attestation technologies have been developed and formats have

been standardized. Examples include the Entity Attestation Token
(EAT) and Trusted Platform Modules (TPMs). Once attestation
information has been produced on a device it needs to be communicated
to a relying party. This information exchange may happen at
different layers in the protocol stack.

This specification provides a generic way of passing attestation

information in the TLS handshake.

"ECH for Enterprises and Organizations", Arnaud Taddei, Simon Edwards,

2022-07-11, <draft-taddei-ech4ent-introduction-00.txt>

This paper reviews some of the Enterprises and Organizations

requirements and constraints and tests the current Encrypted Client
Hello (ECH) proposal in these environments. In particular it
highlights the need for several clarifications as well as highlights
known attack vectors which will become easier with the current ECH
proposal. The current ECH drafts should consider how they want to
include enterprises operational security capabilities to mitigate
these attacks.

"Mandatory-to-Implement Algorithms for Creators and Consumers of Software

Update for the Internet of Things manifests", Brendan Moran, 2022-07-27,
<draft-moran-suit-mti-01.txt>

This document specifies algorithm profiles for SUIT manifest parsers

and authors to ensure better interoperability.

"Recursive Bitstring Structure (RBS) for Multicast Source Routing over IPv6
(MSR6)", Toerless Eckert, Xuesong Geng, Xiuli Zheng, Rui Meng, Fengkai Li,
2022-07-11, <draft-eckert-msr6-rbs-00.txt>

This document defines an encoding and corresponding packet processing

procedures for native IPv6 multicast source routing (MSR6) using a
so-called "Recursive Bitstring" (RBS) address structure.

The RBS address structure encodes the source-routed multicast tree as

a tree of bitstrings. Each router on the tree only needs to examine
and perform replication for the one bitstring destined for it.

The MSR6/RBS IPv6 extension header encoding and processing is modeled

after that of unicast source routing headers, RFC6554 and RFC8754,
and shares all elements that can be shared. To support the RBS
structure, it is replacing the "Segments Left" pointer to the next
segment with two fields to point to the next sub-tree to parse.

"Defined-Trust Transport (DeftT) Protocol for Limited Domains", Kathleen

Nichols, Van Jacobson, Randy King, 2022-07-11,
<draft-nichols-tsv-defined-trust-transport-00.txt>

This document describes a broadcast-friendly, many-to-many Defined-

trust Transport (DeftT) that makes it simple to express and enforce
application and deployment specific integrity, authentication, access
control and behavior constraints directly in the protocol stack.
 DeftT combined with IPv6 multicast and modern hardware-based methods
for securing keys and code provides an easy to use foundation for
secure and efficient communications in Limited Domains (RFC8799), in
particular for Operational Technology (OT) networks.

"Green Networking Metrics", Alexander Clemm, Lijun Dong, Greg Mirsky,

Laurent Ciavaglia, Jeff Tantsura, Marie-Paule Odini, 2022-07-11,
<draft-cx-green-metrics-00.txt>

This document explains the need for network instrumentation that

allows to assess the power consumption, energy efficiency, and carbon
footprint associated with a network, its equipment, and the services
that are provided over it. It also suggests a set of related metrics
that, when provided visibility into, can help to optimize a network's
energy efficiency and "greenness".

"ALTO extensions for handling Service Functions", Luis Contreras, Sabine

Randriamasy, Xufeng Liu, 2022-07-11,
<draft-lcsr-alto-service-functions-01.txt>

This document proposes the usage of ALTO (and its extensions) to

provide information about service functions to clients (e.g.,
external systems) that could consume such information for decisions
requiring network information (service composition, traffic steering
to service chains, etc).

"BIER Extension Headers", Zhaohui Zhang, Xiao Min, Yisong Liu, Hooman
Bidgoli, 2022-07-11, <draft-zzhang-bier-extension-headers-00.txt>

Bit Index Explicit Replication (BIER) is a multicast technology with

a new encapsulation and forwarding paradigm. BIER encapsulation is
specified in RFC8296, and this document specifies extension headers
used with BIER encapsulation header.

"Cryptographically Generated Device identifiers", Sri Gundavelli, Mark

Grayson, 2022-07-11, <draft-gundavelli-dmm-device-identifier-00.txt>

Network Access Identifier (NAI) is an identifier used by access

networks for identifying users requesting access to the network. A
user may access the network using more than one device, but all using
the same NAI and the associated credentials. There are various use-
cases where an access network needs to unambiguously identify a
device used for accessing the network, and NAI is not sufficient for
such determination.

This document describes a device identifier structure and also

identifies the potential stable identifiers that are present on a
dual-radio device which can be used as a device identifiers. This
document also describes mechanisms where the device can generate
device identifiers using cryptographic methods. These generated
identifiers are transient in nature and are unique to a given access
network. Device identifier is intended to be shared only with a
trusted access network which holds the user's network access
credentials and for which the identifier was generated.

"A Domain Name System (DNS) Service Parameter and Resource Record for
Tunneling Information", Donald Eastlake, Haoyu Song, 2022-07-11,
<draft-eastlake-dnsop-svcb-rr-tunnel-00.txt>
 A Domain Name System (DNS) Service Binding (SVCB) Service Parameter
Type and a DNS Resource Record (RR) Type are specified for storing
connection tunneling / encapsulation Information in the DNS.

"Composite KEM For Use In Internet PKI", Mike Ounsworth, John Gray,
2022-07-11, <draft-ounsworth-pq-composite-kem-00.txt>

The migration to post-quantum cryptography is unique in the history

of modern digital cryptography in that neither the old outgoing nor
the new incoming algorithms are fully trusted to protect data for the
required data lifetimes. The outgoing algorithms, such as RSA and
elliptic curve, may fall to quantum cryptanalysis, while the incoming
post-quantum algorithms face uncertainty about both the underlying
mathematics as well as hardware and software implementations that
have not had sufficient maturing time to rule out classical
cryptanalytic attacks and implementation bugs.

Cautious Implementers may wish to layer cryptographic algorithms such

that an attacker would need to break all of them in order to
compromise the data being protected. For digital signatures, this is
referred to as "dual", and for encryption key establishment this as
referred to as "hybrid". This document, and its companions, defines
a specific instantiation of the dual and hybrid paradigm called
"composite" where multiple cryptographic algorithms are combined to
form a single key, signature, or key encapsulation mechanism (KEM)
such that they can be treated as a single atomic object at the
protocol level.

EDNOTE: the terms "dual" and "hybrid" are currently in flux. We

anticipate an Informational draft to normalize terminology, and will
update this draft accordingly.

This document defines a Composite key encapsulation mechanism (KEM)

procedure, for use with Composite keys which consist of combinations
of Encryption or KEM algorithms for each composite component
algorithm. This document also introduces the idea of assigning an
Object Identifier (OID) to a shared secret combiner so that stronger
combiners can be implemented in the future without needing to re-
issue this specification.

This document is intended to be coupled with the composite keys

structure define in [I-D.ounsworth-pq-composite-keys] and the CMS
KEM-TRANS mechanism in [I-D.perret-prat-lamps-cms-pq-kem].

"Challenges and Opportunities in Green Networking", Alexander Clemm, Cedric

Westphal, Jeff Tantsura, Laurent Ciavaglia, Marie-Paule Odini, 2022-07-11,
<draft-cx-green-ps-00.txt>

Reducing technology's carbon footprint is one of the big challenges

of our age. Networks are an enabler of applications that reduce this
footprint, but also contribute to this footprint substantially
themselves. The biggest opportunities to reduce the energy footprint
may not be networking specific, for instance general power efficiency
gains in hardware or hosting of equipment in more cooling-efficient
buildings. Yet methods to make networking technology itself
"greener" also need to be explored. This document outlines a
corresponding set of opportunities, along with associated research
challenges, for reducing this footprint and reducing network energy
demand.
"IETF Network Slice Application in 5G End-to-End Network Slice", Xuesong
Geng, Luis Contreras, Jie Dong, Reza Rokui, Ivan Bykov, 2022-07-11,
<draft-gcdrb-teas-5g-network-slice-application-00.txt>

Network Slicing is one of the core features in 5G, which provides

different network service as independent logical networks. To
provide 5G network slices service, an end-to-end network slice needs
to consists of 3 major types of network segments: Radio Access
Network (RAN), Mobile Core Network (CN) and Transport Network (TN).
This document describes the application of IETF network slice in
providing 5G end-to-end network slices, including the network slice
identification mapping, network slice parameter mapping and 5G IETF
Network Slice NBI.

"More Instant Messaging Interoperability (MIMI) message content", Rohan

Mahy, 2022-07-11, <draft-mahy-mimi-content-00.txt>

This document describes content semantics common in Instant Messaging

(IM) systems and describes an example profile suitable for instant
messaging interoperability of messages end-to-end encrypted inside
the MLS (Message Layer Security) Protocol. It adapts prior work
(CPIM) to work well in the MLS context.

"Simple Protocol for Inviting Numbers (SPIN)", Jonathan Rosenberg, Cullen

Jennings, Alissa Cooper, Jon Peterson, 2022-07-11,
<draft-rosenberg-dispatch-spin-00.txt>

This document introduces a framework and a protocol for facilitating

voice, video and messaging interoperability between application
providers. This work is motivated by the recent passage of
regulation in the European Union - the Digital Markets Act (DMA) -
which, amongst many other provisions, requires that vendors of
applications with a large number of users enable interoperability
with applications made by other vendors. While such interoperability
is broadly present within the public switched telephone network, it
is not yet commonplace between over-the-top applications, such as
Facetime, WhatsApp, and Facebook Messenger. This document
specifically defines the Simple Protocol for Inviting Numbers (SPIN)
which is used to deliver invitations to mobile phone numbers that can
bootstrap subsequent communications over the Internet.

"Flex-Algorithm TLV in PIM Join Attributes", BenChong Xu, Zheng Zhang,

2022-07-11, <draft-xz-pim-flex-algo-00.txt>

This document defines a PIM join attribute to support building

multicast distribution trees flowing Flex-Algorithm path.

"More Instant Messaging Interoperability (MIMI) problem outline", Rohan

Mahy, 2022-07-11, <draft-mahy-mimi-problem-outline-00.txt>

Instant Messaging interoperability requirements have changed

dramatically since the IETF last activity in the space. This
document presents an outline of problems that need to be addressed to
make possible interoperability of modern Instant Messaging systems.
The goal of this problem outline is to point at more detailed drafts
which spawn discussion and eventually spur the IETF standards
process.
"More Instant Messaging Interoperability (MIMI) Identity Concepts", Rohan
Mahy, 2022-07-11, <draft-mahy-mimi-identity-00.txt>

This document discusses concepts in instant messaging identity

interoperability when using end-to-end encryption, for example with
the MLS (Message Layer Security) Protocol. The goal is to explore
the problem space in preparation for framework and requirements
documents.

"Performance Measurement (PM) with Flow-ID in Bit Index Explicit

Replication (BIER)", Xin Zhang, Aijun Wang, 2022-07-12,
<draft-zhang-ippm-pmfi-bier-ioam-00.txt>

This document proposes one new performance measurement method of Bit

Index Explicit Replication (BIER) IOAM information. The controller
can realize the closed-loop control of end-to-end quality assurance
for BIER through collecting and analyzing of BIER IOAM and related
path algorithms in the new method.

"Problem statement for Inter-domain Intent-aware Routing using Color",

Shraddha Hegde, Dhananjaya Rao, Srihari Sangli, Swadesh Agrawal, Clarence
Filsfils, Ketan Talaulikar, Keyur Patel, Jim Uttaro, Bruno Decraene, Alex
Bogdanov, Luay Jalil, Andrew Alston, Xiaohu Xu, Arkadiy Gulko, Mazen
Khaddam, Luis Contreras, Dirk Steinberg, Jim Guichard, Wim Henderickx,
Chris Bowers, 2022-07-15,
<draft-hr-spring-intentaware-routing-using-color-00.txt>

This draft describes the scope, set of use-cases and requirements for
a distributed routing based solution to establish end-to-end intent-
aware paths spanning multi-domain packet networks. The document
focuses on BGP given its predominant use in inter-domain routing
deployments, however the requirements may also apply to other
solutions.

"Encapsulation of MPLS Network Actions and associated Data", Jie Dong,

Tianran Zhou, 2022-07-24, <draft-dong-mpls-mna-encaps-00.txt>

This document specifies a solution for carrying MPLS network actions

and the associated data either in the MPLS label stack or after the
MPLS label stack.

"Circuit Style Segment Routing Policies", Christian Schmutzer, Clarence

Filsfils, Zafar Ali, Francois Clad, Praveen Maheshwari, Reza Rokui, Andrew
Stone, Luay Jalil, Shuping Peng, Tarek Saad, Dan Voyer, 2022-07-24,
<draft-schmutzer-spring-cs-sr-policy-00.txt>

This document describes how Segment Routing (SR) policies can be used
to satisfy the requirements for strict bandwidth guarantees, end-to-
end recovery and persistent paths within a segment routing network.
SR policies satisfying these requirements are called "circuit-style"
SR policies (CS-SR policies).

"JSON Web Proof", Jeremie Miller, David Waite, Michael Jones, 2022-07-24,
<draft-jmiller-jose-json-web-proof-00.txt>

The JOSE set of standards established JSON-based container formats

for Keys (https://datatracker.ietf.org/doc/rfc7517/), Signatures
(https://datatracker.ietf.org/doc/rfc7515/), and Encryption
(https://datatracker.ietf.org/doc/rfc7516/). They also established
 IANA registries (https://www.iana.org/assignments/jose/jose.xhtml) to
enable the algorithms and representations used for them to be
extended. Since those were created, newer cryptographic algorithms
that support selective disclosure and unlinkability have matured and
started seeing early market adoption.

This document defines a new container format similar in purpose and

design to JSON Web Signature (JWS) called a _JSON Web Proof (JWP)_.
Unlike JWS, which integrity-protects only a single payload, JWP can
integrity-protect multiple payloads in one message. It also
specifies a new presentation form that supports selective disclosure
of individual payloads, enables additional proof computation, and
adds a protected header to prevent replay and support binding
mechanisms.

"JSON Proof Algorithms", Jeremie Miller, Michael Jones, 2022-07-24,

<draft-jmiller-jose-json-proof-algorithms-00.txt>

The JSON Proof Algorithms (JPA) specification registers cryptographic

algorithms and identifiers to be used with the JSON Web Proof (JWP)
(https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof-
00.html) and JSON Web Key (JWK) specifications. It defines several
IANA registries for these identifiers.

"JSON Proof Token", Jeremie Miller, Michael Jones, 2022-07-24,

<draft-jmiller-jose-json-proof-token-00.txt>

JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving

representation of claims to be transferred between three parties.
The claims in a JPT are encoded as base64url-encoded JSON objects
that are used as the payloads of a JSON Web Proof (JWP)
(https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof-
00.html) structure, enabling them to be digitally signed and
selectively disclosed. JPTs also support reusability and
unlinkability when using Zero-Knowledge Proofs (ZKPs).

"Issues with the SMTP/IMF 'for' Clause and Remedies", John Klensin,
2022-07-24, <draft-klensin-email-for-clause-00.txt>

The "for" clause of the "Received:" header field goes back to the
first widely deployed version of SMTP (RFC 821). However SMTP also
allows multiple-recipient messages to be transmitted in a single mail
transaction. The combination may, in some cases, lead to undesirable
disclosure of information, including disclosing mail addresses that
were intended to be kept hidden from other recipients. In the
process of working on revisions to RFC 5321 and developing a new
Applicability Statement in the EMAILCORE WG, there have been attempts
to fix the problems by find-tuning text about actions and warnings.
This document is an attempt to explore the issues in somewhat more
depth for members of the community who are, or should be,
participating in the WG.

"BGP Colorful Prefix Routing (CPR) for SRv6 based Services", Haibo Wang,
Jie Dong, Jingrong Xie, Xinjun Chen, 2022-07-25, <draft-wang-idr-cpr-00.txt>

This document describes a mechanism to advertise different IPv6

prefixes which are associated with different color attributes to
establish end-to-end intent aware paths. Such IPv6 prefixes are
called "colorful prefixes", and this mechanism is called Colorful
 Prefix Routing (CPR). The colorful prefixes are the SRv6 locator
prefixes associated with different intent. SRv6 services (e.g. SRv6
VPN services) could be assigned with SRv6 SIDs under the SRv6 locator
prefix with the required intent, so that the SRv6 service traffic can
be steered to the end-to-end intent aware paths of the corresponding
SRv6 locator prefix to meet the service requirements. The existing
IPv6 unicast Address Family could be used for the advertisement of
colorful prefixes, thus this mechanism is easy to interoperate and
allows incremental deployment in multi-domain networks.

"I2NSF Analytics Interface YANG Data Model", Patrick Lingga, Jaehoon Jeong,
Yunchul Choi, 2022-07-25, <draft-lingga-i2nsf-analytics-interface-dm-00.txt>

This document describes an information model and a YANG data model

for the Analytics Interface between an Interface to Network Security
Functions (I2NSF) Analyzer and a Security Controller in an I2NSF
system in a Network Functions Virtualization (NFV) environment. The
YANG data model described in this document is based on the I2NSF NSF-
Facing Interface and the I2NSF Monitoring Interface for enabling the
delivery of analytics information based on monitoring data received
from a Network Security Function (NSF).

"WebRTC-HTTP egress protocol (WHEP)", Sergio Murillo, Cheng Chen,

2022-07-25, <draft-murillo-whep-00.txt>

This document describes a simple HTTP-based protocol that will allow

WebRTC-based viewers to watch content from streaming services and/or
Content Delivery Networks (CDNs) or WebRTC Transmission Network
(WTNs).

"Video BFrame RTP Header Extension", openser, 2022-07-25,

<draft-deping-avtcore-video-bframe-00.txt>

This document describes an RTP header extension used to convey

decoding time information about video when Bi-directional predicted
frames exist.It adds CompositionTime(CTS) as value so that receiver
can decode video with correct sequence.

"The "xml2rfc" version 3 Vocabulary as Implemented", John Levine,

2022-07-27, <draft-irse-draft-irse-xml2rfcv3-implemented-01.txt>

This document describes the "xml2rfc" version 3 vocabulary as

implemented in xml2rfc tools at the time of publication.

"Encryption algorithm Rocca-S", Yuto Nakano, Kazuhide Fukushima, Takanori

Isobe, 2022-08-11, <draft-nakano-rocca-s-01.txt>

This document defines Rocca-S encryption scheme, which is an

Authenticated Encryption with Associated Data (AEAD), using a 256-bit
key and can be efficiently implemented utilizing the AES New
Instruction set (AES-NI).

"CBOR Object Type Extension (COTX)", Anders Rundgren, 2022-07-26,

<draft-rundgren-cotx-01.txt>

This document describes a CBOR tag for providing type information to

CBOR data. Unlike the native CBOR tagging scheme which builds on
integers in a IANA registry, this specification supports arbitrary
type identifiers, including using URLs. The latter enable type
 identifiers to potentially point to associated human readable
definitions as well.

"Extensible Provisioning Protocol (EPP) Mapping for DNS Time-To-Live (TTL)

values", Gavin Brown, 2022-07-27, <draft-regext-brown-epp-ttl-00.txt>

This document describes how the Time-To-Live (TTL) value used for
domain name delegation records can be managed in EPP.

"Representing IP addresses in TLS Server Name Indication (SNI)", Erik

Nygren, Rich Salz, 2022-07-27, <draft-nygren-tls-ip-in-sni-00.txt>

This specification provides a mechanism for clients to send IP

addresses in a TLS Server Name Indication (SNI) extension as part of
TLS handshakes, allowing servers to return a certificate containing
that subjectAltName. This is done by converting the IP address to a
special-use domain name.

"A Larger Internet Key Exchange version 2 (IKEv2) Payload", Yoav Nir,
2022-07-27, <draft-nir-ipsecme-big-payload-00.txt>

The messages of the Internet Key Exchange version 2 (IKEv2) protocol

are made up of payloads. The current protocol limits each of these
payloads to 64KB by having a 2-byte length field. While this is
usually enough, several of the payloads may need to be larger.

This document defines an extension to IKEv2 that allows larger

payloads.

"IBM i Telnet Enhancements", Russel Garvey, Barbara Smith, Timothy

Mullenbach, 2022-07-27, <draft-garvey-networking-rfc4777bis-00.txt>

This document describes the interface to the Telnet server on IBM's i

Power Systems line of business computers. This interface allows
Telnet clients to request a Telnet terminal or printer session using
specific session attributes related to device names, password hash,
language support, auto-sign-on, response codes, session association,
etc.

These support functions are implemented primarily using the Telnet

Environment option negotiation RFC 1572 to define USERVAR
variables that will be recognized by IBM i Telnet server.

This obsoletes RFC4777 with an enhanced automatic sign-on a password

hash and update on how non-complient 5250 negotiations are handled.

"Problem Satement of IPv6 Multicast Source Routing (MSR6)", Yisong Liu,

Tianji Jiang, Zhenbin Li, Zhuangzhuang Qin, 2022-07-28,
<draft-liu-msr6-problem-statement-00.txt>

This document analyses the problem of the existing IPv6 multicast

solutions according to the usecases of MSR6. To solve these
problems, MSR6 can be used as a complementary multicast solution.

"SCIM Referential Value Location Extension", Danny Zollner, 2022-07-29,

<draft-zollner-scim-referential-value-location-01.txt>

The System for Cross-domain Identity Management standard's schema RFC

[RFC7643], as well as custom schemas, may have attribute values that
 have a finite set of acceptable values. These acceptable values are
frequently tied to a value on another resource. For instance, an
organization may only allow values in the Enterprise User schema's
costCenter attribute that are valid identifiers of cost centers
defined in another location. This draft aims to provide a way for a
SCIM client to determine if an attribute in a schema is limited to a
specific set of values, and where those values may be located on
another SCIM resource type.

"Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched
Paths (LSPs)", Greg Mirsky, 2022-07-28, <draft-mirsky-mpls-stamp-00.txt>

Simple Two-way Active Measurement Protocol (STAMP), defined in RFC

8762 and RFC 8972, is expected to be able to monitor the performance
of paths between systems that use a wide variety of encapsulations.
This document defines encapsulation and bootstrapping of a STAMP test
session over an MPLS Label Switched Path.

"An Unreliable Extension to QUIC", Jianping Chen, Tianyi Liu, Junxian Jing,
Yongyi Yu, 2022-07-28, <draft-chen-quic-quicu-00.txt>

QUIC Unreliable (QUICU) is an extension of the QUIC protocol for

unreliable data transmission, mainly through the definition and use
of three new types of frames, namely the Expire Offset Frame,
Boundary Frame, and Correlation Frame. The main purpose of this
extension is to reduce data delivery delay. Through controlling the
timing and scope of packet losses, QUICU reduces useless transmission
to improve transmission efficiency, reduces head-of-line blocking to
improve transmission timeliness, which are beneficial to delay-
sensitive applications, especially audio and video applications.

This document describes the motivation, the operations, and the wire
formats of the three new types of frames.

"PCAP Capture File Format", Guy Harris, Michael Richardson, 2022-07-29,

<draft-richardson-opsawg-pcaplinktype-00.txt>

This document creates a registry for the PCAP and PCAPNG LINKTYPE
values. The PCAP and PCAPNG formats are used to save network
captures from programs such as tcpdump and wireshark, when using
libraries such as libpcap.

"Requirement of Lightweight Authentication and Key Agreement Protocols for

IoT", Yaping Liu, henryzs, Zhiyu Han, 2022-07-29,
<draft-liu-zhang-han-lakapiot-00.txt>

This document specifies the requirement of lightweight authentication

and key agreement protocols for Internet of Things (LAKAPIoT).
The authentication and key agreement protocols are very crucial for
IoT since it can prevent unauthorized or malicious IoT devices from
accessing the network. However, most IoT devices have limited storage,
computing and communication capacity. Moreover, the network archi-
tecture of IoT is very different from the traditional network.
Therefore, designing authentication and key agreement protocols for
IoT is an essential step to ensure its security. In this draft, the
requirement of lightweight authentication and key agreement protocols
for IoT is proposed.

"EdDSA value for IPSECKEY", Robert Moskowitz, Tero Kivinen, 2022-08-10,

<draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt>

This document assigns a value for EdDSA Public Keys to the IPSECKEY
IANA registry.

"Byte Range PATCH", Austin Wright, 2022-08-02,

<draft-wright-http-patch-byterange-00.txt>

This document specifies a media type for PATCH payloads that

overwrites a specific byte range, to allow random access writes, or
allow a resource to be uploaded in several segments.

"DAP Interoperation Test Design", David Cook, 2022-08-31,

<draft-dcook-ppm-dap-interop-test-design-01.txt>

This document defines a common test interface for implementations of

the Distributed Aggregation Protocol for Privacy Preserving
Measurement (DAP-PPM) and describes how this test interface can be
used to perform interoperation testing between the implementations.
Tests are orchestrated with containers, and new test-only APIs are
introduced to provision DAP-PPM tasks and initiate processing.

"IP Number for SCHC", Robert Moskowitz, Stuart Card, Adam Wiethuechter,
2022-08-05, <draft-moskowitz-intarea-ipnumber-00.txt>

This document requests an Internet Protocol Number assignment for

SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.

"Carrying a Generic Identifier in IPv6 packets", Justin Iurman, 2022-08-06,

<draft-iurman-6man-generic-id-00.txt>

Some recent use cases seem to have a need for carrying IDs within
packets. Two examples are _I-D.draft-ietf-6man-enhanced-vpn-vtn-id_
and _I-D.draft-li-6man-topology-id_. While they might perfectly make
sense on their own, each document requires IANA to allocate a new
code point for a new option, which could quickly exhaust the
allocation space if similar designs are proposed in the future. As
an example, one might need an 8-bit ID, while another one might need
a 24-bit, 32-bit, or 64-bit ID. Or, even worse, one might need a
32-bit ID in a specific context, while someone else might also need a
32-bit ID in another context. Therefore, allocating a new code point
for each similar option is probably not the way to go.

"RFC Format Framework As Implemented", Paul Hoffman, 2022-08-09,

<draft-hoffman-rfc-format-framework-as-implemented-01.txt>

RFC 7990 "serves as the framework that provides the problem

statement, lays out a road map of the documents that capture the
specific requirements, and describes the transition plan" for the
format of RFCs. The eventual implementation of the framework
happened somewhat differently than was described in RFC 7990. This
document describes how the framework was, and is being, implemented.

"Canonical Format for RFCs", Paul Hoffman, 2022-08-09,

<draft-hoffman-rfc7990-updates-01.txt>

This document updates RFC 7990 by changing the definition of the

"canonical format" for RFCs.
"Nomcom Eligibility", Martin Duke, 2022-08-11,
<draft-duke-elegy-rfc8989bis-00.txt>

The IETF Nominating Committee (NomCom) appoints candidates to most

IETF leadership committee. RFC8713 provides criteria for membership
on Nomcom that attempts to ensure that NomCom volunteers are members
of the loosely defined IETF community, by requiring in-person
attendance in three of the past five in- person meetings. In 2020
and 2021, the IETF had six consecutive fully online plenary meetings
that drove rapid advancement in remote meeting technologies and
procedures, including an experiment that included remote attendance
for NomCom eligibility. This document updates RFC8713 by building a
new set of eligibility criteria from first principles, with
consideration for the increased salience of remote attendance.

"Remove SHA-1 from active use within DNSSEC", Wes Hardaker, 2022-08-12,
<draft-hardaker-dnsop-must-not-sha1-00.txt>

This document retires the use of SHA-1 within DNSSEC

"The Transit Measurement Option", Tal Mizrahi, Tianran Zhou, Shahar Belkar,
Reuven Cohen, 2022-08-15,
<draft-mzbc-ippm-transit-measurement-option-00.txt>

This document specifies an IPv6 option that contains a compact set of

fields which can be used for transit delay measurement and congestion
detection. This option can be incorporated into data packets and
updated by transit nodes along the path, enabling lightweight
measurement and monitoring using constant-length data that does not
depend on the number of hops in the network.

"Algorithm Implementation Requirements and Usage Guidance for DNSSEC", Wes

Hardaker, Paul Wouters, Ondrej Sury, 2022-08-15,
<draft-hardaker-dnsop-rfc8624-bis-00.txt>

The DNSSEC protocol makes use of various cryptographic algorithms in

order to provide authentication of DNS data and proof of non-
existence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements
and usage guidance for DNSSEC. This document obsoletes [RFC6944].

"ECN Over Aggregating Tunnels", Martin Duke, 2022-08-15,

<draft-duke-tsvwg-ecn-aggregating-tunnels-00.txt>

Explicit Congestion Notification (ECN) provides two bits in the IP

header for routers to signal congestion to endpoints without
resorting to packet loss. RFC6040 provided guidance for how IP-in-IP
tunnels should transfer (ECN) markings between inner and outer IP
headers. However, that document implicitly assumes that no more than
one inner packet is present in an outer packet. As numerous
tunneling technologies have since emerged that break this assumption,
further guidance is needed.

"Real-Time Monitoring Link/Protocol Neighbor State", Tianran Zhou, Feng Xu,

Shunwan Zhuang, Haibo Wang, 2022-08-15,
<draft-zhou-grow-monitoring-neighbor-state-00.txt>

Various protocols are deployed in today's networks, such as BGP /

ISIS / OSPF etc. Link neighbor state changes and protocol neighbor
state changes are the most important network events that need to be
processed with the highest priority. In particular, the SDN
controller needs to quickly sense the link neighbor and protocol
neighbor state change information in the network. Thus, the various
policies applied by the SDN controller to the network can quickly
match the current state of the network. This document discusses some
possible scenarios and the relevant requirements.

"Abstract next-hop addresses in IP VPNs", Igor Malyushkin, 2022-08-17,

<draft-malyushkin-bess-ip-vpn-abstract-next-hops-00.txt>

draft-malyushkin-bess-ip-vpn-abstract-next-hops-00

Abstract

This document discusses the IP VPN convergence aspects and specifies

procedures for IP VPN to signal the attachment circuit failure. The
specified procedures help significantly improve the IP VPN
convergence.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at

https://datatracker.ietf.org/doc/draft-malyushkin-bess-ip-vpn-
abstract-next-hops/.

Discussion of this document takes place on the BGP Enabled ServiceS

Working Group mailing list (mailto:bess@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/bess/. Subscribe at
https://www.ietf.org/mailman/listinfo/bess/.

"CoAP Simple Management Protocol", Paul Duffy, Jasvinder Bhasin, Kit-Mui

Leung, Huimin She, Li Zhao, 2022-08-17, <draft-duffy-csmp-00.txt>

CoAP Simple Management Protocol (CSMP) provides lifecycle management

for resource constrained IoT devices deployed within large-scale,
bandwidth constrained IoT networks. This document describes the
design and operation of CSMP.

"Applying TCP User Timeout Parameter to BGP Sessions", Enke Chen, Robert
Raszuk, 2022-08-17, <draft-chen-idr-tcp-user-timeout-00.txt>

In this document we discuss the TCP "User Timeout" parameter and

recommend using it to handle stuck BGP sessions.

"Automated Certificate Management Environment (ACME) Renewal Information

(ARI) Extension", Aaron Gable, 2022-08-17, <draft-acme-ari-00.txt>

This document specifies how an ACME server may provide suggestions to

ACME clients as to when they should attempt to renew their
certificates. This allows servers to mitigate load spikes, and
ensures clients do not make false assumptions about appropriate
certificate renewal periods.
 Current Implementations

Draft note: this section will be removed by the editor before final
publication.

Let's Encrypt's Staging environment (available at [lestaging], source

at [boulder]) implements this draft specification.

"Service Identification Header of Service Aware Network", Liwei Ma, Fenlin

Zhou, Hesong Li, 2022-08-18,
<draft-service-identification-header-of-san-00.txt>

As the cloud and computing migrates to edges further away from the
traditional centered cloud, the services residing at the distributed
cloud start to be delivered in such a ubiquitous and dynamic way.
That it is challenging to the ongoing routing and interconnecting
scheme under which host address is the global networking
identification. This draft proposes a service identification which
is designed to be treated both as a service routable ID and an
interface to the service requirements as well as service-associated
cloud resources. Service Aware Network header is illustrated and
specified.

"Encapsulation of SAN Header", Liwei Ma, Detao Zhao, Fenlin Zhou,

2022-08-18, <draft-encapsulation-of-san-header-00.txt>

This document proposes the encapsulation of the SAN header in the

IPv6 data plane to carry the SAN related information, which could be
used to associate the networking and computing resources indexed by
SAN ID and route and forward the service traffic accordingly.

"The R5N Distributed Hash Table", Martin Schanzenbach, Christian Grothoff,

Bernd Fix, 2022-08-19, <draft-schanzen-r5n-00.txt>

This document contains the R^5N DHT technical specification.

This document defines the normative wire format of resource records,

resolution processes, cryptographic routines and security
considerations for use by implementers.

This specification was developed outside the IETF and does not have
IETF consensus. It is published here to guide implementation of R^5N
and to ensure interoperability among implementations.

"Special-Use Domain Names Registry", Paul Hoffman, 2022-08-19,

<draft-hoffman-rfc6761bis-00.txt>

This document obsoletes RFC 6761 that created the Special-Use Domain
Names registry at IANA for domain names that are reserved for special
use. The registry has proved to be useful. RFC 6761 also has a
description for when reserving such a name is appropriate, and the
procedure for doing so; those descriptions have turned out to cause
many problems in the IETF. Because of those problems, this document
obsoletes RFC 6761 while retaining the registry and greatly reducing
the rest of the discussion and requirements in RFC 6761. It places
the responsibility for accepting Special-Use Domain Names entries
with the IESG.
 [ A repository for this draft can be found at https://github.com/
paulehoffman/6761bis (https://github.com/paulehoffman/6761bis). ]

"Interoperability Procedures for BGP Routes with Color", Jeffrey Haas,

2022-08-19, <draft-haas-idr-bgp-diffract-00.txt>

"BGP Routes with Color" have become a topic of interest in the IDR
Working Group. The authors of the various proposals have many things
in mind to solve with them, how a color might be used, and the
operational model for their solution. In general, the solutions
share some core properties: Routes for an IP endpoint, that have a
domain-wide semantic element to differentiate forwarding (often
called a color), and appropriate state to enable that differentiated
forwarding.

Examples of the technologies enabling differentiated forwarding

include MPLS and Segment Routing.

This document examines two of the current proposals - BGP Color-Aware

Routing, and BGP Classful Transport - and proposes mechanisms to
permit them to interoperate.

"Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message

Syntax (CMS)", Russ Housley, Scott Fluhrer, Panos Kampanakis, Bas
Westerbaan, 2022-09-03, <draft-housley-lamps-cms-sphincs-plus-01.txt>

SPHINCS+ is a stateless hash-based signature scheme. This document

specifies the conventions for using the SPHINCS+ stateless hash-based
signature algorithm with the Cryptographic Message Syntax (CMS). In
addition, the algorithm identifier and public key syntax are
provided.

"Secure Asset Transfer (SAT) Use Cases", Venkatraman Ramakrishna, Thomas

Hardjono, 2022-08-22, <draft-ramakrishna-sat-use-cases-00.txt>

This document describes prominent scenarios where enterprise systems and

networks maintaining digital assets require the ability to securely
transfer assets or data to each other.

"CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC", Russ
Housley, Hannes Tschofenig, 2022-08-22,
<draft-housley-cose-aes-ctr-and-cbc-00.txt>

The Concise Binary Object Representation (CBOR) data format is

designed for small code size and small message size. CBOR Object
Signing and Encryption (COSE) is specified in RFC 8152 to provide
basic security services using the CBOR data format. This document
specifies the conventions for using AES-CTR and AES-CBC as Content
Encryption algorithms with COSE.

"Kyber Post-Quantum KEM", Peter Schwabe, Bas Westerbaan, 2022-08-22,

<draft-cfrg-schwabe-kyber-00.txt>

This memo specifies Kyber, an IND-CCA2 secure Key Encapsulation

Method.

About This Document

This note is to be removed before publishing as an RFC.

 The latest revision of this draft can be found at
https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-
schwabe-kyber.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/.

Source for this draft and an issue tracker can be found at

https://github.com/bwesterb/draft-schwabe-cfrg-kyber.

"Publicly Verifiable Nominations Committee (NomCom) Random Selection",

Donald Eastlake, 2022-08-23, <draft-eastlake-rfc3797bis-00.txt>

This document describes a method for making random selections in such

a way that the unbiased nature of the choice is publicly verifiable.
For example, the selection of the voting members of the IETF
Nominations Committee (NomCom) from the pool of eligible volunteers.
Similar techniques would be applicable to other cases.

"UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets

for End-Host to End-Host Communication", Michael Tuexen, Randall Stewart,
2022-08-25, <draft-tuexen-tsvwg-rfc6951-bis-02.txt>

This document describes a simple method of encapsulating Stream

Control Transmission Protocol (SCTP) packets into UDP packets and its
limitations. This allows the usage of SCTP in networks with legacy
NATs that do not support SCTP. It can also be used to implement SCTP
on hosts without directly accessing the IP layer, for example,
implementing it as part of the application without requiring special
privileges.

Please note that this document only describes the functionality

needed within an SCTP stack to add on UDP encapsulation, providing
only those mechanisms for two end-hosts to communicate with each
other over UDP ports. In particular, it does not provide mechanisms
to determine whether UDP encapsulation is being used by the peer, nor
the mechanisms for determining which remote UDP port number can be
used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or

ingress) endpoints.

"BGP Extension for 5G Edge Service Metadata", Linda Dunbar, Kausik

Majumdar, Haibo Wang, Gyan Mishra, 2022-08-25,
<draft-dunbar-idr-5g-edge-service-metadata-00.txt>

This draft describes three new sub-TLVs for egress routers to

advertise the Edge Service Metadata of the directly attached
edge services (ES). The Edge Service Metadata can be used by
the ingress routers in the 5G Local Data Network to make path
selection not only based on the routing cost but also the
running environment of the edge services. The goal is to
improve latency and performance for 5G edge services.

The extension enables an edge service at one specific location

to be more preferred than the others with the same IP address
(ANYCAST) to receive data flows from a specific source, like
specific User Equipment (UE).

"SCION Control-Plane PKI", Corine de Kater, Nicola Rustignoli, 2022-08-26,

 <draft-dekater-scion-pki-00.txt>

This document presents the trust concept and design of the SCION
_control-plane PKI_, SCION's public key infrastructure model. SCION
(Scalability, Control, and Isolation On Next-generation networks) is
a path-aware, inter-domain network architecture. The control-plane
PKI, or short CP-PKI, handles cryptographic material and lays the
foundation for the authentication procedures in SCION. It is used by
SCION's control plane to authenticate and verify path information,
and builds the basis for SCION's special trust model based on so-
called Isolation Domains.

The document first describes the trust model behind SCION's control-
plane PKI, and provides a short overview of the certificates, keys,
and roles involved. It then continues with detailed specifications
of the building blocks of SCION's control-plane PKI. The document
concludes with several considerations in regard to deploying the
control-plane PKI.

"Distributed Flow Measurement in IPv6", Haojie Wang, Changwang Lin,

2022-08-30, <draft-wang-ippm-ipv6-distributed-flow-measurement-00.txt>

Flow measurement based on Alternate-Marking method for IPv6 network

requires the controller to collect statistical data, calculate and
present the results. This document proposes a distributed method for
in-situ flow measurement, which is indpendent of the controller.

"An Unreliable Oblivious HTTP Extension", Ralph Giles, Christopher Wood,

2022-08-30, <draft-wood-ohai-unreliable-ohttp-00.txt>

This document describes an extension to Oblivious HTTP (OHTTP) that

supports unreliable application data transfer from Client to Target.
Beyond enabling application uses that do not require explicit
responses from the Target, such as privacy-preserving data
collection, this extension allows the Oblivious Relay Resource to
buffer, batch, and shuffle requests to Oblivious Gateway Resources as
a way of amplifying end-to-end client privacy protections.

"EVPN Next Hop address encoding", Mike Dubrovsky, 2022-09-03,

<draft-dubrovsky-bess-evpn-next-hop-00.txt>

This document clarifies that the EVPN route Next Hop encoding is
unaffected by whether the underlying BGP session is IPv4 or IPv6.

From that perspective, this document updates the EVPN specification

to provide more comprehensive documentation of the encoding.

Network Time Protocols (ntp)

----------------------------

"Control Messages Protocol for Use with Network Time Protocol Version 4",
Brian Haberman, 2022-02-15, <draft-ietf-ntp-mode-6-cmds-11.txt>

This document describes the structure of the control messages that

were historically used with the Network Time Protocol before the
advent of more modern control and management approaches. These
control messages have been used to monitor and control the Network
Time Protocol application running on any IP network attached
computer. The information in this document was originally described
 in Appendix B of RFC 1305. The goal of this document is to provide
an updated description of the control messages described in RFC 1305
in order to conform with the updated Network Time Protocol
specification documented in RFC 5905.

The publication of this document is not meant to encourage the

development and deployment of these control messages. This document
is only providing a current reference for these control messages
given the current status of RFC 1305.

"NTP Interleaved Modes", Miroslav Lichvar, Aanchal Malhotra, 2021-10-18,

<draft-ietf-ntp-interleaved-modes-07.txt>

This document extends the specification of Network Time Protocol

(NTP) version 4 in RFC 5905 with special modes called the NTP
interleaved modes, that enable NTP servers to provide their clients
and peers with more accurate transmit timestamps that are available
only after transmitting NTP packets. More specifically, this
document describes three modes: interleaved client/server,
interleaved symmetric, and interleaved broadcast.

"Roughtime", Aanchal Malhotra, Adam Langley, Watson Ladd, Marcus Dansarie,

2022-06-07, <draft-ietf-ntp-roughtime-06.txt>

This document specifies Roughtime - a protocol that aims to achieve

rough time synchronization while detecting servers that provide
inaccurate time and providing cryptographic proof of their
malfeasance.

"A Secure Selection and Filtering Mechanism for the Network Time Protocol
with Chronos", Neta Schiff, Danny Dolev, Tal Mizrahi, Michael Schapira,
2022-08-24, <draft-ietf-ntp-chronos-07.txt>

The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905,

is the mechanism used by NTP clients to synchronize with NTP servers
across the Internet. This document specifies an extension to the
NTPv4 client, named Chronos, which is used as a "watchdog" alongside
NTPv4, and provides improved security against time shifting attacks.
Chronos involves changes to the NTP client's system process only.
Since it does not affect the wire protocol, the Chronos mechanism is
applicable to any current or future time protocol.

"Updating the NTP Registries", Rich Salz, 2022-08-17,

<draft-ietf-ntp-update-registries-06.txt>

The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of assigned number registries, collectively
called the NTP registries. Some registries have wrong values, some
registries do not follow current common practice, and some are just
right. For the sake of completeness, this document reviews all NTP
and NTS registries.

This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC
7821.

"NTPv5 use cases and requirements", James Gruessing, 2022-07-25,

<draft-ietf-ntp-ntpv5-requirements-00.txt>

This document describes the use cases, requirements, and

 considerations that should be factored in the design of a successor
protocol to supersede version 4 of the NTP protocol [RFC5905]
presently referred to as NTP version 5 ("NTPv5"). This document is
non-exhaustive and does not in its current version represent working
group consensus.

Network Virtualization Overlays (nvo3)

--------------------------------------

"Network Virtualization Overlays (NVO3) Encapsulation Considerations", Sami

Boutros, Donald Eastlake, 2022-04-30, <draft-ietf-nvo3-encap-08.txt>

The IETF Network Virtualization Overlays (NVO3) Working Group Chairs

and Routing Area Director chartered a design team to take forward the
encapsulation discussion and see if there was potential to design a
common encapsulation that addresses the various technical concerns.

There are implications of having different encapsulations in real

environments consisting of both software and hardware implementations
and within and spanning multiple data centers. For example, OAM
functions such as path MTU discovery become challenging with multiple
encapsulations along the data path.

The design team recommended Geneve with a few modifications as the

common encapsulation. This document provides more details,
particularly in Section 7.

"Applicability of EVPN to NVO3 Networks", Jorge Rabadan, Matthew Bocci,

Sami Boutros, Ali Sajassi, 2022-09-01,
<draft-ietf-nvo3-evpn-applicability-05.txt>

In Network Virtualization Over Layer-3 (NVO3) networks, Network

Virtualization Edge devices (NVEs) sit at the edge of the underlay
network and provide Layer-2 and Layer-3 connectivity among Tenant
Systems (TSes) of the same tenant. The NVEs need to build and
maintain mapping tables so that they can deliver encapsulated packets
to their intended destination NVE(s). While there are different
options to create and disseminate the mapping table entries, NVEs may
exchange that information directly among themselves via a control-
plane protocol, such as Ethernet Virtual Private Network (EVPN).
EVPN provides an efficient, flexible and unified control-plane option
that can be used for Layer-2 and Layer-3 Virtual Network (VN) service
connectivity. This document describes the applicability of EVPN to
NVO3 networks and how EVPN solves the challenges in those networks.
This document does not introduce any new procedures in EVPN.

"OAM for use in GENEVE", Greg Mirsky, Sami Boutros, David Black, Santosh
Pallagatti, 2022-06-14, <draft-ietf-nvo3-geneve-oam-05.txt>

This document lists a set of general requirements for active OAM

protocols in the Geneve overlay network. Based on the requirements,
IP encapsulation for active Operations, Administration, and
Maintenance protocols in Geneve protocol is defined. Considerations
for using ICMP and UDP-based protocols are discussed.

"BFD for Geneve", Xiao Min, Greg Mirsky, Santosh Pallagatti, Jeff Tantsura,
Sam Aldrin, 2022-08-11, <draft-ietf-nvo3-bfd-geneve-07.txt>

This document describes the use of the Bidirectional Forwarding

 Detection (BFD) protocol in point-to-point Generic Network
Virtualization Encapsulation (Geneve) tunnels used to make up an
overlay network.

Coding for efficient NetWork Communications Research Group (nwcrg)

------------------------------------------------------------------

"Tetrys, an On-the-Fly Network Coding Protocol", Jonathan Detchart,

Emmanuel Lochin, Jerome Lacan, Vincent Roca, 2022-04-24,
<draft-irtf-nwcrg-tetrys-02.txt>

This document describes Tetrys, an On-The-Fly Network Coding (NC)

protocol that MAY be used to transport delay and loss-sensitive data
over a lossy network. Tetrys MAY recover from erasures within an
RTT-independent delay, thanks to the transmission of Coded Packets.
This document is a record of the experience gained by the authors
while developing and testing in real conditions the Tetrys protocol.

This document is a product of the Coding for Efficient Network

Communications Research Group (NWCRG). It conforms to the NWCRG
taxonomy[RFC8406].

Web Authorization Protocol (oauth)

----------------------------------

"OAuth 2.0 Security Best Current Practice", Torsten Lodderstedt, John

Bradley, Andrey Labunets, Daniel Fett, 2022-07-28,
<draft-ietf-oauth-security-topics-20.txt>

This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader
application of OAuth 2.0.

"JWT Response for OAuth Token Introspection", Torsten Lodderstedt, Vladimir

Dzhuvinov, 2021-09-04, <draft-ietf-oauth-jwt-introspection-response-12.txt>

This specification proposes an additional JSON Web Token (JWT)

secured response for OAuth 2.0 Token Introspection.

"OAuth 2.0 for Browser-Based Apps", Aaron Parecki, David Waite, 2022-03-07,
<draft-ietf-oauth-browser-based-apps-09.txt>

This specification details the security considerations and best

practices that must be taken into account when developing browser-
based applications that use OAuth 2.0.

"OAuth 2.0 Rich Authorization Requests", Torsten Lodderstedt, Justin

Richer, Brian Campbell, 2022-05-05, <draft-ietf-oauth-rar-12.txt>

This document specifies a new parameter authorization_details that is

used to carry fine-grained authorization data in OAuth messages.

"OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer

(DPoP)", Daniel Fett, Brian Campbell, John Bradley, Torsten Lodderstedt,
Michael Jones, David Waite, 2022-08-10, <draft-ietf-oauth-dpop-11.txt>

This document describes a mechanism for sender-constraining OAuth 2.0

 tokens via a proof-of-possession mechanism on the application level.
This mechanism allows for the detection of replay attacks with access
and refresh tokens.

"The OAuth 2.1 Authorization Framework", Dick Hardt, Aaron Parecki, Torsten
Lodderstedt, 2022-07-24, <draft-ietf-oauth-v2-1-06.txt>

The OAuth 2.1 authorization framework enables a third-party

application to obtain limited access to a protected resource, either
on behalf of a resource owner by orchestrating an approval
interaction between the resource owner and an authorization service,
or by allowing the third-party application to obtain access on its
own behalf. This specification replaces and obsoletes the OAuth 2.0
Authorization Framework described in RFC 6749.

"OAuth 2.0 Step-up Authentication Challenge Protocol", Vittorio Bertocci,

Brian Campbell, 2022-07-24,
<draft-ietf-oauth-step-up-authn-challenge-02.txt>

It is not uncommon for resource servers to require different

authentication strengths or freshness according to the
characteristics of a request. This document introduces a mechanism
for a resource server to signal to a client that the authentication
event associated with the access token of the current request doesn't
meet its authentication requirements and specify how to meet them.
This document also codifies a mechanism for a client to request that
an authorization server achieve a specific authentication strength or
freshness when processing an authorization request.

"Selective Disclosure for JWTs (SD-JWT)", Daniel Fett, Kristina Yasuda,

2022-08-25, <draft-ietf-oauth-selective-disclosure-jwt-00.txt>

This document specifies conventions for creating JSON Web Token (JWT)
documents that support selective disclosure of JWT claim values.

Oblivious HTTP Application Intermediation (ohai)

------------------------------------------------

"Oblivious HTTP", Martin Thomson, Christopher Wood, 2022-09-01,

<draft-ietf-ohai-ohttp-04.txt>

This document describes a system for forwarding encrypted HTTP

messages. This allows a client to make multiple requests to an
origin server without that server being able to link those requests
to the client or to identify the requests as having come from the
same client, while placing only limited trust in the nodes used to
forward the messages.

Open Specification for Pretty Good Privacy (openpgp)

----------------------------------------------------

"OpenPGP Message Format", Werner Koch, Paul Wouters, Daniel Huigens, Justus
Winter, Niibe Yutaka, 2022-06-06, <draft-ietf-openpgp-crypto-refresh-06.txt>

This document specifies the message formats used in OpenPGP. OpenPGP

provides encryption with public-key or symmetric cryptographic
algorithms, digital signatures, compression and key management.

This document is maintained in order to publish all necessary

 information needed to develop interoperable applications based on the
OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.

This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in

OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP).

Operations and Management Area Working Group (opsawg)

-----------------------------------------------------

"A YANG Network Data Model for Layer 2 VPNs", Mohamed Boucadair, Oscar de
Dios, Samier Barguil, Luis Munoz, 2022-06-02,
<draft-ietf-opsawg-l2nm-19.txt>

This document defines an L2VPN Network YANG Model (L2NM) which can be
used to manage the provisioning of Layer 2 Virtual Private Network
services within a network (e.g., service provider network). The L2NM
complements the Layer 2 Service Model (L2SM) by providing a network-
centric view of the service that is internal to a service provider.
The L2NM is particularly meant to be used by a network controller to
derive the configuration information that will be sent to relevant
network devices.

Also, this document defines a YANG module to manage Ethernet segments

and the initial versions of two IANA-maintained modules that include
a set of identities of BGP Layer 2 encapsulation types and pseudowire
types.

"Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices",

Tirumaleswar Reddy.K, Dan Wing, Blake Anderson, 2022-08-26,
<draft-ietf-opsawg-mud-tls-07.txt>

This memo extends the Manufacturer Usage Description (MUD)

specification to incorporate (D)TLS profile parameters. This allows
a network security service to identify unexpected (D)TLS usage, which
can indicate the presence of unauthorized software or malware on an
endpoint.

"Discovering and Retrieving Software Transparency and Vulnerability

Information", Eliot Lear, Scott Rose, 2022-09-02,
<draft-ietf-opsawg-sbom-access-07.txt>

To improve cybersecurity posture, automation is necessary to locate

what software is running on a device, whether that software has known
vulnerabilities, and what, if any recommendations suppliers may have.
This memo specifies a model to provide access to this information.
It may optionally be discovered through manufacturer usage
descriptions.

"Authorized update to MUD URLs", Michael Richardson, Wei Pan, Eliot Lear,
2022-07-11, <draft-ietf-opsawg-mud-acceptable-urls-05.txt>

This document provides a way for an RFC8520 Manufacturer Usage

Description (MUD) definitions to declare what are acceptable
replacement MUD URLs for a device.
 RFCEDITOR-please-remove: this document is being worked on at:
https://github.com/mcr/iot-mud-acceptable-urls

"Operational Considerations for use of DNS in IoT devices", Michael

Richardson, Wei Pan, 2022-03-27,
<draft-ietf-opsawg-mud-iot-dns-considerations-04.txt>

This document details concerns about how Internet of Things devices

use IP addresses and DNS names. The issue becomes acute as network
operators begin deploying RFC8520 Manufacturer Usage Description
(MUD) definitions to control device access.

This document makes recommendations on when and how to use DNS names
in MUD files.

"A YANG Model for Network and VPN Service Performance Monitoring", Bo Wu,
Qin WU, Mohamed Boucadair, Oscar de Dios, Bin Wen, 2022-05-17,
<draft-ietf-opsawg-yang-vpn-service-pm-09.txt>

The data model for network topologies defined in RFC 8345 introduces
vertical layering relationships between networks that can be
augmented to cover network and service topologies. This document
defines a YANG module for performance monitoring (PM) of both
networks and VPN services that can be used to monitor and manage
network performance on the topology at higher layer or the service
topology between VPN sites.

"Service Assurance for Intent-based Networking Architecture", Benoit

Claise, Jean Quilbeuf, Diego Lopez, Dan Voyer, Thangam Arumugam,
2022-08-11, <draft-ietf-opsawg-service-assurance-architecture-08.txt>

This document describes an architecture that aims at assuring that

service instances are running as expected. As services rely upon
multiple sub-services provided by a variety of elements including the
underlying network devices and functions, getting the assurance of a
healthy service is only possible with a holistic view of all involved
elements. This architecture not only helps to correlate the service
degradation with symptoms of a specific network component but also to
list the services impacted by the failure or degradation of a
specific network component.

"YANG Modules for Service Assurance", Benoit Claise, Jean Quilbeuf, Paolo
Lucente, Paolo Fasano, Thangam Arumugam, 2022-08-10,
<draft-ietf-opsawg-service-assurance-yang-07.txt>

This document specifies YANG modules for representing assurance

graphs. These graphs represent the assurance of a given service by
decomposing it into atomic assurance elements called subservices. A
companion document, Service Assurance for Intent-based Networking
Architecture, presents an architecture for implementing the assurance
of such services.

The YANG data models in this document conforms to the Network

Management Datastore Architecture (NMDA) defined in RFC 8342.

"Ownership and licensing statements in YANG", Eliot Lear, Carsten Bormann,

2022-04-24, <draft-ietf-opsawg-ol-01.txt>
 This memo provides for an extension to RFC 8520 that allows MUD file
authors to specify ownership and licensing of MUD files themselves.
This memo updates RFC 8520. However, it can also be used for
purposes outside of MUD, and the grouping is structured as such.

"PCAP Capture File Format", Guy Harris, Michael Richardson, 2022-07-29,

<draft-ietf-opsawg-pcap-01.txt>

This document describes the format used by the libpcap library to

record captured packets to a file. Programs using the libpcap
library to read and write those files, and thus reading and writing
files in that format, include tcpdump.

"Updates to the TLS Transport Model for SNMP", Kenneth Vaughn, 2022-05-26,
<draft-ietf-opsawg-tlstm-update-05.txt>

This document updates the TLS Transport Model (TLSTM), as defined in

RFC 6353, to reflect changes necessary to support Transport Layer
Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security
Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".
This document is compatible with (D)TLS 1.2 and is intended to be
compatible with future versions of SNMP and (D)TLS.

This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.

"A YANG Network Model for Service Attachment Points (SAPs)", Mohamed
Boucadair, Oscar de Dios, Samier Barguil, Qin WU, Victor Lopez, 2022-07-28,
<draft-ietf-opsawg-sap-09.txt>

This document defines a YANG data model for representing an abstract

view of the provider network topology that contains the points from
which its services can be attached (e.g., basic connectivity, VPN,
network slices). Also, the model can be used to retrieve the points
where the services are actually being delivered to customers
(including peer networks).

This document augments the 'ietf-network' data model by adding the

concept of Service Attachment Points (SAPs). The SAPs are the
network reference points to which network services, such as Layer 3
Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network
(L2VPN), can be attached. Both User-Network Interface (UNI) and
Network-to-Network Interface (NNI) are supported in the SAP data
model.

"TACACS+ TLS 1.3", Thorsten Dahm, dcmgash@cisco.com, Andrej Ota, John

Heasley, 2022-08-06, <draft-ietf-opsawg-tacacs-tls13-00.txt>

The TACACS+ Protocol [RFC8907] provides device administration for

routers, network access servers and other networked computing devices
via one or more centralized servers. This document, a companion to
the TACACS+ protocol [RFC8907], adds Transport Layer Security
(currently defined by TLS 1.3 [RFC8446]) support and deprecates
former inferior security mechanisms.

Operational Security Capabilities for IP Network Infrastructure (opsec)

-----------------------------------------------------------------------

"Indicators of Compromise (IoCs) and Their Role in Attack Defence", Kirsty

Paine, Ollie Whitehouse, James Sellwood, Andrew S, 2022-07-01,
 <draft-ietf-opsec-indicators-of-compromise-01.txt>

Cyber defenders frequently rely on Indicators of Compromise (IoCs) to

identify, trace, and block malicious activity in networks or on
endpoints. This draft reviews the fundamentals, opportunities,
operational limitations, and best practices of IoC use. It
highlights the need for IoCs to be detectable in implementations of
Internet protocols, tools, and technologies - both for the IoCs'
initial discovery and their use in detection - and provides a
foundation for new approaches to operational challenges in network
security.

"Attribution of Internet Probes", Eric Vyncke, Benoit Donnet, Justin

Iurman, 2022-09-02, <draft-ietf-opsec-probe-attribution-00.txt>

Active measurements at Internet-scale can target either collaborating

parties or non-collaborating ones. This is similar scan and could be
perceived as aggressive. This document proposes a couple of simple
techniques allowing any party or organization to understand what this
unsolicited packet is, what is its purpose, and more importantly who
to contact.

Path Aware Networking RG (panrg)

--------------------------------

"A Vocabulary of Path Properties", Reese Enghardt, Cyrill Kraehenbuehl,

2022-03-07, <draft-irtf-panrg-path-properties-05.txt>

Path properties express information about paths across a network and

the services provided via such paths. In a path-aware network, path
properties may be fully or partially available to entities such as
endpoints. This document defines and categorizes path properties.
Furthermore, the document specifies several path properties which
might be useful to endpoints or other entities, e.g., for selecting
between paths or for invoking some of the provided services.

Path Computation Element (pce)

------------------------------

"Extensions to the Path Computation Element Communication Protocol for

Enhanced Errors and Notifications", Helia Poullyau, Remi Theillaud, Julien
Meuric, Haomian Zheng, Xian Zhang, 2022-03-07,
<draft-ietf-pce-enhanced-errors-11.txt>

This document defines new error and notification TLVs for the PCE
Communication Protocol (PCEP) specified in RFC5440, and will update
it. It identifies the possible PCEP behaviors in case of error or
notification. Thus, this draft defines types of errors and how they
are disclosed to other PCEs in order to support predefined PCEP
behaviors.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Stateful PCE Usage in GMPLS-controlled Networks", Young Lee, Haomian Zheng,
Oscar de Dios, Victor Lopez, Zafar Ali, 2022-06-27,
<draft-ietf-pce-pcep-stateful-pce-gmpls-20.txt>

The PCE communication Protocol (PCEP) has been extended to support

stateful PCE functions where the Stateful PCE maintains information
about paths and resource usage within a network, but these
 extensions do not cover all requirements for GMPLS networks.

This document provides the extensions required for PCEP so as to

enable the usage of a stateful PCE capability in GMPLS-controlled
networks.

"A YANG Data Model for Path Computation Element Communications Protocol
(PCEP)", Dhruv Dhody, Vishnu Beeram, Jonathan Hardwick, Jeff Tantsura,
2022-07-11, <draft-ietf-pce-pcep-yang-19.txt>

This document defines a YANG data model for the management of Path
Computation Element communications Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs. The data model includes
configuration and state data.

"PCEP Extension for Native IP Network", Aijun Wang, Boris Khasanov, Sheng
Fang, Ren Tan, Chun Zhu, 2022-03-20,
<draft-ietf-pce-pcep-extension-native-ip-18.txt>

This document defines the Path Computation Element Communication

Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR)
based application in Native IP network. The scenario and framework
of CCDR in native IP is described in [RFC8735] and [RFC8821]. This
draft describes the key information that is transferred between Path
Computation Element (PCE) and Path Computation Clients (PCC) to
accomplish the End to End (E2E) traffic assurance in Native IP
network under central control mode.

"PCEP Extension for Flexible Grid Networks", Young Lee, Haomian Zheng,
Ramon Casellas, Ricard Vilalta, Daniele Ceccarelli, Francesco Lazzeri,
2022-03-07, <draft-ietf-pce-flexible-grid-07.txt>

This document provides the Path Computation Element Communication

Protocol (PCEP) extensions for the support of Routing and Spectrum
Assignment (RSA) in Flexible Grid networks.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Segment Routing leveraging the IPv6 dataplane", Cheng Li, Mahendra Negi,
Siva Sivabalan, Mike Koldychev, Prejeeth Kaladharan, Yongqing Zhu,
2022-07-10, <draft-ietf-pce-segment-routing-ipv6-14.txt>

The Source Packet Routing in Networking (SPRING) architecture

describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm.
SR enables any head-end node to select any path without relying on a
hop-by-hop signaling technique (e.g., LDP or RSVP-TE).

It depends only on "segments" that are advertised by Link-State IGPs.

A Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or
a PCE.

Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
should be able to compute SR-Path for both MPLS and IPv6 forwarding
plane. This document describes the extensions required for SR
support for IPv6 data plane in Path Computation Element communication
Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS
is described in RFC 8664. This document extends it to support SRv6
 (SR over IPv6).

"Path Computation Element Communication Protocol (PCEP) extensions for

establishing relationships between sets of Label Switched Paths and Virtual
Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, 2022-05-12,
<draft-ietf-pce-vn-association-08.txt>

This document describes how to extend the Path Computation Element

(PCE) Communication Protocol (PCEP) association mechanism introduced
by the PCEP Association Group specification, to further associate
sets of Label Switched Paths (LSPs) with a higher-level structure
such as a Virtual Network (VN) requested by a customer or
application. This extended association mechanism can be used to
facilitate control of virtual network using the PCE architecture.

"Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.",

Siva Sivabalan, Clarence Filsfils, Jeff Tantsura, Stefano Previdi, Cheng
Li, 2022-03-20, <draft-ietf-pce-binding-label-sid-15.txt>

In order to provide greater scalability, network confidentiality, and

service independence, Segment Routing (SR) utilizes a Binding Segment
Identifier (SID) (called BSID) as described in RFC 8402. It is
possible to associate a BSID to an RSVP-TE-signaled Traffic
Engineering Label Switched Path or an SR Traffic Engineering path.
The BSID can be used by an upstream node for steering traffic into
the appropriate TE path to enforce SR policies. This document
specifies the concept of binding value, which can be either an MPLS
label or Segment Identifier. It further specifies an extension to
Path Computation Element (PCE) communication Protocol(PCEP) for
reporting the binding value by a Path Computation Client (PCC) to the
PCE to support PCE-based Traffic Engineering policies.

"Path Computation Element Communication Protocol (PCEP) Extension for Path

Segment in Segment Routing (SR)", Cheng Li, Mach Chen, Weiqiang Cheng,
Rakesh Gandhi, Quan Xiong, 2022-08-19,
<draft-ietf-pce-sr-path-segment-06.txt>

The Path Computation Element (PCE) provides path computation

functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.

The Source Packet Routing in Networking (SPRING) architecture

describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm. A
Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or
a Path Computation Element (PCE).

Path identification is needed for several use cases such as

performance measurement in Segment Routing (SR) network. This
document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) to support requesting, replying,
reporting and updating the Path Segment ID (Path SID) between PCEP
speakers.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Associated Bidirectional Segment Routing (SR) Paths", Cheng Li, Mach Chen,
Weiqiang Cheng, Rakesh Gandhi, Quan Xiong, 2022-08-31,
<draft-ietf-pce-sr-bidir-path-10.txt>
 The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
Segment routing (SR) leverages the source routing and tunneling
paradigms. The Stateful PCEP extensions allow stateful control of
Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP
can be used for computing SR TE paths in the network.

This document defines PCEP extensions for grouping two unidirectional

SR Paths (one in each direction in the network) into a single
associated bidirectional SR Path. The mechanisms defined in this
document can also be applied using a stateful PCE for both PCE-
initiated and PCC-initiated LSPs or when using a stateless PCE.

"PCEP extension to support Segment Routing Policy Candidate Paths", Mike

Koldychev, Siva Sivabalan, Colby Barth, Shuping Peng, Hooman Bidgoli,
2022-04-21, <draft-ietf-pce-segment-routing-policy-cp-07.txt>

This document introduces a mechanism to specify a Segment Routing

(SR) policy, as a collection of SR candidate paths. An SR policy is
identified by <headend, color, endpoint> tuple. An SR policy can
contain one or more candidate paths where each candidate path is
identified in PCEP by its uniquely assigned PLSP-ID. This document
proposes extension to PCEP to support association among candidate
paths of a given SR policy. The mechanism proposed in this document
is applicable to both MPLS and IPv6 data planes of SR.

"Local Protection Enforcement in PCEP", Andrew Stone, Mustapha Aissaoui,

Samuel Sidor, Siva Sivabalan, 2022-08-08,
<draft-ietf-pce-local-protection-enforcement-07.txt>

This document extends the base specification to clarify usage of the

local protection desired bit signalled in the Path Computation
Element Protocol (PCEP). This document also introduces a new flag
for signalling protection strictness in PCEP.

"Path Computation Element Communication Protocol (PCEP) Extensions for

Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS
Segment Identifier (SID) Allocation and Distribution.", Zhenbin Li, Shuping
Peng, Mahendra Negi, Quintin Zhao, Chao Zhou, 2022-07-10,
<draft-ietf-pce-pcep-extension-pce-controller-sr-05.txt>

The Path Computation Element (PCE) is a core component of Software-

Defined Networking (SDN) systems.

A PCE-based Central Controller (PCECC) can simplify the processing of

a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the LSP can be
calculated/set up/initiated and the label forwarding entries can also
be downloaded through a centralized PCE server to each network device
along the path while leveraging the existing PCE technologies as much
as possible.

This document specifies the procedures and Path Computation Element

Communication Protocol (PCEP) extensions when a PCE-based controller
is also responsible for configuring the forwarding actions on the
routers, in addition to computing the paths for packet flows in a
segment routing (SR) network and telling the edge routers what
 instructions to attach to packets as they enter the network. PCECC
as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment
Identifier) allocation and distribution.

"PCEP Extension for Stateful Inter-Domain Tunnels", Olivier Dugeon, Julien

Meuric, Young Lee, Daniele Ceccarelli, 2022-03-04,
<draft-ietf-pce-stateful-interdomain-03.txt>

This document specifies how to use a Backward Recursive or

Hierarchical method to derive inter-domain paths in the context of
stateful Path Computation Element (PCE). The mechanism relies on the
PCInitiate message to set up independent paths per domain. Combining
these different paths together enables them to be operated as end-to-
end inter-domain paths, without the need for a signaling session
between inter-domain border routers. For this purpose, this document
defines a new Stitching Label, new Association Type, and a new PCEP
communication Protocol (PCEP) Capability.

"Label Switched Path (LSP) Object Flag Extension of Stateful PCE", Quan
Xiong, 2022-06-07, <draft-ietf-pce-lsp-extended-flags-03.txt>

RFC 8231 describes a set of extensions to Path Computation Element

Communication Protocol (PCEP) to enable stateful control of MPLS-TE
and GMPLS Label Switched Paths (LSPs) via PCEP. One of the
extensions is the LSP object which includes a Flag field of the
length of 12 bits. However, all bits of the Flag field have already
been assigned in RFC 8231, RFC 8281, RFC 8623 and I-D.ietf-pce-
binding-label-sid.

[Note to RFC Editor - Replace I-D.ietf-pce-binding-label-sid to RFC

XXXX, once the RFC number is assigned.]

This document proposes to define a new LSP-EXTENDED-FLAG TLV for the

LSP object for an extended flag field.

"PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva

Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav,
Shuping Peng, Gyan Mishra, 2022-05-17, <draft-ietf-pce-multipath-06.txt>

Path computation algorithms are not limited to return a single

optimal path. Multiple paths may exist that satisfy the given
objectives and constraints. This document defines a mechanism to
encode multiple paths for a single set of objectives and constraints.
This is a generic PCEP mechanism, not specific to any path setup type
or dataplane. The mechanism is applicable to both stateless and
stateful PCEP.

"Inter Stateful Path Computation Element (PCE) Communication Procedures.",

Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng, 2022-07-10,
<draft-ietf-pce-state-sync-03.txt>

The Path Computation Element (PCE) Communication Protocol (PCEP)

provides mechanisms for PCEs to perform path computation in response
to a Path Computation Client (PCC) request. The Stateful PCE
extensions allow stateful control of Multi-Protocol Label Switching
(MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using
PCEP.

A Path Computation Client (PCC) can synchronize an LSP state

 information to a Stateful Path Computation Element (PCE). A PCC can
have multiple PCEP sessions towards multiple PCEs. There are some
use cases, where an inter-PCE stateful communication can bring
additional resiliency in the design, for instance when some PCC-PCE
session fails.

This document describes the procedures to allow a stateful

communication between PCEs for various use-cases and also the
procedures to prevent computations loops.

"Extension for Stateful PCE to allow Optional Processing of PCE

Communication Protocol (PCEP) Objects", Cheng Li, Haomian Zheng, Stephane
Litkowski, 2022-07-10, <draft-ietf-pce-stateful-pce-optional-04.txt>

This document introduces a mechanism to mark some of the Path

Computation Element (PCE) Communication Protocol (PCEP) objects as
optional during PCEP messages exchange for the Stateful PCE model to
allow relaxing some constraints during path computation and setup.
This document introduces this relaxation to stateful PCE and updates
RFC 8231.

"PCEP extensions for p2mp sr policy", Hooman Bidgoli, Dan Voyer, Saranya
Rajarathinam, Ehsan Hemmati, Tarek Saad, Siva Sivabalan, 2022-07-07,
<draft-ietf-pce-sr-p2mp-policy-01.txt>

SR P2MP policies are set of policies that enable architecture for

P2MP service delivery. This document specifies extensions to the
Path Computation Element Communication Protocol (PCEP) that allow a
stateful PCE to compute and initiate P2MP paths from a Root to a set
of Leaves.

"PCEP Extension for L2 Flow Specification", Dhruv Dhody, Adrian Farrel,

Zhenbin Li, 2022-07-09, <draft-ietf-pce-pcep-l2-flowspec-02.txt>

The Path Computation Element (PCE) is a functional component capable

of selecting paths through a traffic engineering (TE) network. These
paths may be supplied in response to requests for computation or may
be unsolicited requests issued by the PCE to network elements. Both
approaches use the PCE Communication Protocol (PCEP) to convey the
details of the computed path.

Traffic flows may be categorized and described using "Flow

Specifications". RFC 8955 defines the Flow Specification and
describes how Flow Specification components are used to describe
traffic flows. RFC 8955 also defines how Flow Specifications may be
distributed in BGP to allow specific traffic flows to be associated
with routes.

RFC 9168 specifies a set of extensions to PCEP to support the

dissemination of Flow Specifications. This allows a PCE to indicate
what traffic should be placed on each path that it is aware of.

The extensions defined in this document extend the support for

Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN)
traffic filtering rules either by themselves or in conjunction with
L3 flowspecs.

"Support for Path MTU (PMTU) in the Path Computation Element (PCE)
communication Protocol (PCEP)", Shuping Peng, Cheng Li, Liuyan Han,
 Luc-Fabrice Ndifor, 2022-07-06, <draft-ietf-pce-pcep-pmtu-02.txt>

The Path Computation Element (PCE) provides path computation

functions in support of traffic engineering in Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) networks.

The Source Packet Routing in Networking (SPRING) architecture

describes how Segment Routing (SR) can be used to steer packets
through an IPv6 or MPLS network using the source routing paradigm. A
Segment Routed Path can be derived from a variety of mechanisms,
including an IGP Shortest Path Tree (SPT), explicit configuration, or
a Path Computation Element (PCE).

Since the SR does not require signaling, the path maximum

transmission unit (MTU) information for SR path is not available at
the headend. This document specify the extension to PCE
communication protocol (PCEP) to carry path (MTU) in the PCEP
messages for SR and other scenarios.

"Path Computation Element Communication Protocol (PCEP) Extensions to

Enable IFIT", Hang Yuan, wangxuerong, Pingan Yang, Weidong Li, Giuseppe
Fioccola, 2022-08-03, <draft-ietf-pce-pcep-ifit-01.txt>

In-situ Flow Information Telemetry (IFIT) refers to network OAM data

plane on-path telemetry techniques, in particular In-situ OAM (IOAM)
and Alternate Marking. This document defines PCEP extensions to
allow a Path Computation Client (PCC) to indicate which IFIT features
it supports, and a Path Computation Element (PCE) to configure IFIT
behavior at a PCC for a specific path in the stateful PCE model. The
PCEP extensions described in this document are defined for use with
Segment Routing (SR). They could be generalized for all path types,
but that is out of scope of this document.

Privacy Enhancements and Assessments Research Group (pearg)

-----------------------------------------------------------

"Guidelines for Performing Safe Measurement on the Internet", Iain

Learmonth, Gurshabad Grover, Mallory Knodel, 2022-08-19,
<draft-irtf-pearg-safe-internet-measurement-06.txt>

Researchers from industry and academia often use Internet

measurements as part of their work. While these measurements can
give insight into the functioning and usage of the Internet, they can
come at the cost of user privacy. This document describes guidelines
for ensuring that such measurements can be carried out safely.

Note

Comments are solicited and should be addressed to the research

group's mailing list at pearg@irtf.org and/or the author(s).

The sources for this draft are at:

https://github.com/irl/draft-safe-internet-measurement

"Unfortunate History of Transient Numeric Identifiers", Fernando Gont, Ivan

Arce, 2022-07-11, <draft-irtf-pearg-numeric-ids-history-10.txt>

This document analyzes the timeline of the specification and

 implementation of different types of "transient numeric identifiers"
used in IETF protocols, and how the security and privacy properties
of such protocols have been affected as a result of it. It provides
empirical evidence that advice in this area is warranted. This
document is a product of the Privacy Enhancement and Assessment
Research Group (PEARG) in the IRTF.

"On the Generation of Transient Numeric Identifiers", Fernando Gont, Ivan

Arce, 2022-07-11, <draft-irtf-pearg-numeric-ids-generation-11.txt>

This document performs an analysis of the security and privacy

implications of different types of "transient numeric identifiers"
used in IETF protocols, and tries to categorize them based on their
interoperability requirements and their associated failure severity
when such requirements are not met. Subsequently, it provides advice
on possible algorithms that could be employed to satisfy the
interoperability requirements of each identifier category, while
minimizing the negative security and privacy implications, thus
providing guidance to protocol designers and protocol implementers.
Finally, it describes a number of algorithms that have been employed
in real implementations to generate transient numeric identifiers,
and analyzes their security and privacy properties. This document is
a product of the Privacy Enhancement and Assessment Research Group
(PEARG) in the IRTF.

"A Survey of Worldwide Censorship Techniques", Joseph Hall, Michael Aaron,

Amelia Andersdotter, Ben Jones, Nick Feamster, Mallory Knodel, 2022-05-25,
<draft-irtf-pearg-censorship-06.txt>

This document describes technical mechanisms employed in network

censorship that regimes around the world use for blocking or
impairing Internet traffic. It aims to make designers, implementers,
and users of Internet protocols aware of the properties exploited and
mechanisms used for censoring end-user access to information. This
document makes no suggestions on individual protocol considerations,
and is purely informational, intended as a reference.

Protocols for IP Multicast (pim)

--------------------------------

"A YANG Data Model for Protocol Independent Multicast (PIM)", Xufeng Liu,
Pete McAllister, Anish Peter, Mahesh Sivakumar, Yisong Liu, fangwei hu,
2018-05-19, <draft-ietf-pim-yang-17.txt>

This document defines a YANG data model that can be used to configure
and manage devices supporting Protocol Independent Multicast (PIM).
The model covers the PIM protocol configuration, operational state,
and event notifications data.

"Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router

(DR) Improvement", Zheng Zhang, fangwei hu, BenChong Xu, Mankamana Mishra,
2022-03-07, <draft-ietf-pim-dr-improvement-13.txt>

Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely

deployed multicast protocol. As deployment for the PIM protocol is
growing day by day, a user expects lower packet loss and faster
convergence regardless of the cause of the network failure. This
document defines an extension to the existing protocol, which
improves the PIM's stability with respect to packet loss and
 convergence time when the PIM Designated Router (DR) role changes.

"PIM Null-Register packing", Vikas Kamath, Ramakrishnan Sundaram, Raunak

Banthia, Ananya Gopal, 2021-11-07,
<draft-ietf-pim-null-register-packing-11.txt>

In PIM-SM networks PIM Null-Register messages are sent by the

Designated Router (DR) to the Rendezvous Point (RP) to signal the
presence of Multicast sources in the network. There are periodic PIM
Null-Registers sent from the DR to the RP to keep the state alive at
the RP as long as the source is active. The PIM Null-Register
message carries information about a single Multicast source and
group.

This document defines a standard to send multiple Multicast source

and group information in a single PIM Packed Null-Register message.
We will refer to the new packed formats as the PIM Packed Null-
Register format and PIM Packed Register-Stop format throughout the
document. This document also discusses interoperability between the
PIM routers which do not understand the PIM Packed Null-Register
format and routers which do understand it.

"A Yang Data Model for IGMP/MLD Proxy", Hongji Zhao, Xufeng Liu, Yisong
Liu, Mani Panchanathan, Mahesh Sivakumar, 2021-08-30,
<draft-ietf-pim-igmp-mld-proxy-yang-06.txt>

This document defines a YANG data model that can be used to

configure and manage Internet Group Management Protocol (IGMP) or
Multicast Listener Discovery (MLD) proxy devices. The YANG module in
this document conforms to Network Management Datastore Architecture
(NMDA).

"PIM Assert Message Packing", Yisong Liu, Mike McBride, Toerless Eckert,
Zheng Zhang, 2021-11-22, <draft-ietf-pim-assert-packing-05.txt>

In PIM-SM shared LAN networks, there is typically more than one

upstream router. When duplicate data packets appear on the LAN from
different routers, assert packets are sent from these routers to
elect a single forwarder. The PIM assert packets are sent
periodically to keep the assert state. The PIM assert packet carries
information about a single multicast source and group, along with
the metric-preference and metric of the route towards the source or
RP. This document defines a standard to send and receive information
for multiple multicast sources and groups in a single PIM assert
message. This can be particularly helpful when there is traffic
for a large number of multicast groups.

"Segment Routing Point-to-Multipoint Policy", Dan Voyer, Clarence Filsfils,

Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2022-07-02,
<draft-ietf-pim-sr-p2mp-policy-05.txt>

This document describes an architecture to construct a Point-to-

Multipoint (P2MP) tree to deliver Multi-point services in a Segment
Routing domain. A SR P2MP tree is constructed by stitching a set of
Replication segments together. A SR Point-to-Multipoint (SR P2MP)
Policy is used to define and instantiate a P2MP tree which is
computed by a PCE.

"PIM Backup Designated Router Procedure", Mankamana Mishra, Sridhar

Santhanam, Aravind Paramasivam, Imed Romdhani, Gyan Mishra, 2022-03-07,
<draft-ietf-pim-bdr-01.txt>

On a multi-access network, one of the PIM routers is elected as a

Designated Router (DR). On the last hop LAN, the PIM DR is
responsible for tracking local multicast listeners and forwarding
traffic to these listeners if the group is operating in PIM-SM. In
this document, we propose a mechanism to elect backup DR on a shared
LAN. A backup DR on LAN would be useful for faster convergence.
This draft introduces the concept of a Backup Designated Router (BDR)
and the procedure to implement it.

"Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Brian Haberman,

2022-07-08, <draft-ietf-pim-3810bis-03.txt>

This document updates RFC 2710, and it specifies Version 2 of the

Multicast Listener Discovery Protocol (MLDv2). MLD is used by an
IPv6 router to discover the presence of multicast listeners on
directly attached links, and to discover which multicast addresses
are of interest to those neighboring nodes. MLDv2 is designed to be
interoperable with MLDv1. MLDv2 adds the ability for a node to
report interest in listening to packets with a particular multicast
address only from specific source addresses or from all sources
except for specific source addresses.

This document obsoletes RFC 3810.

"Internet Group Management Protocol, Version 3", Brian Haberman,

2022-07-08, <draft-ietf-pim-3376bis-03.txt>

This document specifies a revised Version 3 of the Internet Group

Management Protocol, IGMPv3. IGMP is the protocol used by IPv4
systems to report their IP multicast group memberships to neighboring
multicast routers. Version 3 of IGMP adds support for source
filtering, that is, the ability for a system to report interest in
receiving packets only from specific source addresses, or from all
but specific source addresses, sent to a particular multicast
address. That information may be used by multicast routing protocols
to avoid delivering multicast packets from specific sources to
networks where there are no interested receivers.

This document obsoletes RFC 3376.

"PIM Join/ Prune Attributes for LISP Environments using Underlay

Multicast", Vengada Govindan, Stig Venaas, 2022-04-19,
<draft-ietf-pim-jp-extensions-lisp-01.txt>

This document specifies an extension to PIM Receiver RLOC Join/ Prune

attribute that supports the construction of multicast distribution
trees where the root and receivers are located in different Locator/
ID Separation Protocol (LISP) sites and are connected using underlay
IP Multicast. This attribute allows the receiver site to signal the
underlay multicast group to the control plane of the root ITR
(Ingress Tunnel Router).

"IGMP and MLD Snooping Yang Module Extension for L2VPN", Hongji Zhao,
Xufeng Liu, Yisong Liu, Mahesh Sivakumar, Anish Peter, 2022-05-25,
<draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-00.txt>
 Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping could be used in both BRIGDE service and L2VPN
service. The old ietf-igmp-mld-snooping yang module just describes the
BRIGDE service. In this document we extend the existing ietf-igmp-mld-
snooping yang module and make it could be used in L2VPN service.

"Multicast-only Fast Reroute Based on Topology Independent Loop-free

Alternate Fast Reroute", Yisong Liu, Mike McBride, Zheng Zhang, Jingrong
Xie, Changwang Lin, 2022-07-23, <draft-ietf-pim-mofrr-tilfa-00.txt>

Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431],

but the selection of the secondary multicast next hop only according
to the loop-free alternate fast reroute, which has restrictions in
multicast deployments. This document describes a mechanism for
Multicast-only Fast Reroute by using Topology Independent Loop-free
Alternate fast reroute, which is independent of network topology and
can achieve covering more network environments.

Privacy Preserving Measurement (ppm)

------------------------------------

"Distributed Aggregation Protocol for Privacy Preserving Measurement", Tim

Geoghegan, Christopher Patton, Eric Rescorla, Christopher Wood, 2022-07-11,
<draft-ietf-ppm-dap-01.txt>

There are many situations in which it is desirable to take

measurements of data which people consider sensitive. In these
cases, the entity taking the measurement is usually not interested in
people's individual responses but rather in aggregated data.
Conventional methods require collecting individual responses and then
aggregating them, thus representing a threat to user privacy and
rendering many such measurements difficult and impractical. This
document describes a multi-party distributed aggregation protocol
(DAP) for privacy preserving measurement (PPM) which can be used to
collect aggregate data without revealing any individual user's data.

Privacy Pass (privacypass)

--------------------------

"Privacy Pass Issuance Protocol", Sofia Celi, Alex Davidson, Armando

Faz-Hernandez, Steven Valdez, Christopher Wood, 2022-07-06,
<draft-ietf-privacypass-protocol-06.txt>

This document specifies two variants of the the two-message issuance

protocol for Privacy Pass tokens: one that produces tokens that are
privately verifiable, and another that produces tokens that are
publicly verifiable. The privately verifiable issuance protocol
optionally supports public metadata during the issuance flow.

"Privacy Pass Architectural Framework", Alex Davidson, Jana Iyengar,

Christopher Wood, 2022-08-05, <draft-ietf-privacypass-architecture-06.txt>

This document specifies the architectural framework for constructing

secure and anonymity-preserving instantiations of the Privacy Pass
protocol. It provides recommendations on how the protocol ecosystem
should be constructed to ensure the privacy of clients, and the
security of all participating entities.

"The Privacy Pass HTTP Authentication Scheme", Tommy Pauly, Steven Valdez,
 Christopher Wood, 2022-08-05, <draft-ietf-privacypass-auth-scheme-05.txt>

This document defines an HTTP authentication scheme that can be used

by clients to redeem Privacy Pass tokens with an origin. It can also
be used by origins to challenge clients to present an acceptable
Privacy Pass token.

"Rate-Limited Token Issuance Protocol", Scott Hendrickson, Jana Iyengar,

Tommy Pauly, Steven Valdez, Christopher Wood, 2022-09-01,
<draft-ietf-privacypass-rate-limit-tokens-00.txt>

This document specifies a variant of the Privacy Pass issuance

protocol that allows for tokens to be rate-limited on a per-origin
basis. This enables origins to use tokens for use cases that need to
restrict access from anonymous clients.

Quantum Internet Research Group (qirg)

--------------------------------------

"Architectural Principles for a Quantum Internet", Wojciech Kozlowski,

Stephanie Wehner, Rodney Van Meter, Bruno Rijsman, Angela Cacciapuoti,
Marcello Caleffi, Shota Nagayama, 2022-08-28,
<draft-irtf-qirg-principles-11.txt>

The vision of a quantum internet is to enhance existing Internet

technology by enabling quantum communication between any two points
on Earth. To achieve this goal, a quantum network stack should be
built from the ground up to account for the fundamentally new
properties of quantum entanglement. The first quantum entanglement
networks have been realised [Pompili21.1], but there is no practical
proposal for how to organise, utilise, and manage such networks. In
this draft, we attempt to lay down the framework and introduce some
basic architectural principles for a quantum internet. This is
intended for general guidance and general interest, but also to
provide a foundation for discussion between physicists and network
specialists. This document is a product of the Quantum Internet
Research Group (QIRG).

"Application Scenarios for the Quantum Internet", Chonggang Wang, Akbar

Rahman, Ruidong Li, Melchior Aelmans, Kaushik Chakraborty, 2022-06-10,
<draft-irtf-qirg-quantum-internet-use-cases-13.txt>

The Quantum Internet has the potential to improve application

functionality by incorporating quantum information technology into
the infrastructure of the overall Internet. This document provides
an overview of some applications expected to be used on the Quantum
Internet and categorizes them. Some general requirements for the
Quantum Internet are also discussed. The intent of this document is
to describe a framework for applications, and describe a few selected
application scenarios for the Quantum Internet.

QUIC (quic)
-----------

"Applicability of the QUIC Transport Protocol", Mirja Kuehlewind, Brian

Trammell, 2022-07-15, <draft-ietf-quic-applicability-18.txt>

This document discusses the applicability of the QUIC transport

protocol, focusing on caveats impacting application protocol
 development and deployment over QUIC. Its intended audience is
designers of application protocol mappings to QUIC, and implementors
of these application protocols.

"Manageability of the QUIC Transport Protocol", Mirja Kuehlewind, Brian

Trammell, 2022-07-15, <draft-ietf-quic-manageability-18.txt>

This document discusses manageability of the QUIC transport protocol,

focusing on the implications of QUIC's design and wire image on
network operations involving QUIC traffic. It is intended as a
"user's manual" for the wire image, providing guidance for network
operators and equipment vendors who rely on the use of transport-
aware network functions.

"QUIC-LB: Generating Routable QUIC Connection IDs", Martin Duke, Nick

Banks, Christian Huitema, 2022-07-11,
<draft-ietf-quic-load-balancers-14.txt>

QUIC address migration allows clients to change their IP address

while maintaining connection state. To reduce the ability of an
observer to link two IP addresses, clients and servers use new
connection IDs when they communicate via different client addresses.
This poses a problem for traditional "layer-4" load balancers that
route packets via the IP address and port 4-tuple. This
specification provides a standardized means of securely encoding
routing information in the server's connection IDs so that a properly
configured load balancer can route packets with migrated addresses
correctly. As it proposes a structured connection ID format, it also
provides a means of connection IDs self-encoding their length to aid
some hardware offloads.

"Compatible Version Negotiation for QUIC", David Schinazi, Eric Rescorla,

2022-07-11, <draft-ietf-quic-version-negotiation-09.txt>

QUIC does not provide a complete version negotiation mechanism but

instead only provides a way for the server to indicate that the
version the client chose is unacceptable. This document describes a
version negotiation mechanism that allows a client and server to
select a mutually supported version. Optionally, if the client's
chosen version and the negotiated version share a compatible first
flight format, the negotiation can take place without incurring an
extra round trip.

"Main logging schema for qlog", Robin Marx, Luca Niccolini, Marten Seemann,
2022-08-31, <draft-ietf-quic-qlog-main-schema-03.txt>

This document describes a high-level schema for a standardized

logging format called qlog. This format allows easy sharing of data
and the creation of reusable visualization and debugging tools. The
high-level schema in this document is intended to be protocol-
agnostic. Separate documents specify how the format should be used
for specific protocol data. The schema is also format-agnostic, and
can be represented in for example JSON, csv or protobuf.

"QUIC event definitions for qlog", Robin Marx, Luca Niccolini, Marten
Seemann, 2022-08-31, <draft-ietf-quic-qlog-quic-events-02.txt>

This document describes concrete qlog event definitions and their

metadata for QUIC events. These events can then be embedded in the
 higher level schema defined in [QLOG-MAIN].

"HTTP/3 and QPACK qlog event definitions", Robin Marx, Luca Niccolini,
Marten Seemann, 2022-08-31, <draft-ietf-quic-qlog-h3-events-02.txt>

This document describes concrete qlog event definitions and their

metadata for HTTP/3 and QPACK-related events. These events can then
be embedded in the higher level schema defined in [QLOG-MAIN].

"QUIC Acknowledgement Frequency", Jana Iyengar, Ian Swett, 2022-07-11,

<draft-ietf-quic-ack-frequency-02.txt>

This document describes a QUIC extension for an endpoint to control

its peer's delaying of acknowledgements.

Note to Readers

Discussion of this draft takes place on the QUIC working group

mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic. Source
code and issues list for this draft can be found at
https://github.com/quicwg/ack-frequency.

Working Group information can be found at https://github.com/quicwg.

"QUIC Version 2", Martin Duke, 2022-08-29, <draft-ietf-quic-v2-05.txt>

This document specifies QUIC version 2, which is identical to QUIC

version 1 except for some trivial details. Its purpose is to combat
various ossification vectors and exercise the version negotiation
framework. It also serves as a template for the minimum changes in
any future version of QUIC.

Note that "version 2" is an informal name for this proposal that
indicates it is the second standards-track QUIC version. The
protocol specified here uses a version number other than 2 in the
wire image.

"Multipath Extension for QUIC", Yanmei Liu, Yunfei Ma, Quentin De Coninck,
Olivier Bonaventure, Christian Huitema, Mirja Kuehlewind, 2022-07-11,
<draft-ietf-quic-multipath-02.txt>

This document specifies a multipath extension for the QUIC protocol

to enable the simultaneous usage of multiple paths for a single
connection.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the QUIC Working Group

mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/quic/.

Source for this draft and an issue tracker can be found at

https://github.com/mirjak/draft-lmbdhk-quic-multipath.

"QUIC Retry Offload", Martin Duke, Nick Banks, 2022-05-25,

<draft-ietf-quic-retry-offload-00.txt>
 QUIC uses Retry packets to reduce load on stressed servers, by
forcing the client to prove ownership of its address before the
server commits state. QUIC also has an anti-tampering mechanism to
prevent the unauthorized injection of Retry packets into a
connection. However, a server operator may want to offload
production of Retry packets to an anti-Denial-of-Service agent or
hardware accelerator. "Retry Offload" is a mechanism for
coordination between a server and an external generator of Retry
packets that can succeed despite the anti-tampering mechanism.

Remote ATtestation ProcedureS (rats)

------------------------------------

"The Entity Attestation Token (EAT)", Laurence Lundblade, Giridhar Mandyam,

Jeremy O'Donoghue, 2022-07-10, <draft-ietf-rats-eat-14.txt,.pdf>

An Entity Attestation Token (EAT) provides an attested claims set

that describes state and characteristics of an entity, a device like
a phone, IoT device, network equipment or such. This claims set is
used by a relying party, server or service to determine how much it
wishes to trust the entity.

An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
attestation-oriented claims. To a large degree, all this document
does is extend CWT and JWT.

"Remote Attestation Procedures Architecture", Henk Birkholz, Dave Thaler,

Michael Richardson, Ned Smith, Wei Pan, 2022-08-16,
<draft-ietf-rats-architecture-21.txt>

In network protocol exchanges it is often useful for one end of a

communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.

"A YANG Data Model for Challenge-Response-based Remote Attestation

Procedures using TPMs", Henk Birkholz, Michael Eckel, Shwetha Bhandari,
Eric Voit, Bill Sulzen, Liang Xia, Tom Laffey, Guy Fedorkow, 2022-05-18,
<draft-ietf-rats-yang-tpm-charra-21.txt>

This document defines YANG RPCs and a few configuration nodes

required to retrieve attestation evidence about integrity
measurements from a device, following the operational context defined
in TPM-based Network Device Remote Integrity Verification.
Complementary measurement logs are also provided by the YANG RPCs,
originating from one or more roots of trust for measurement (RTMs).
The module defined requires at least one TPM 1.2 or TPM 2.0 as well
as a corresponding TPM Software Stack (TSS), or equivalent hardware
implementations that include the protected capabilities as provided
by TPMs as well as a corresponding software stack, included in the
device components of the composite device the YANG server is running
on.

"TPM-based Network Device Remote Integrity Verification", Guy Fedorkow,

Eric Voit, Jessica Fitzgerald-McKay, 2022-03-22,
<draft-ietf-rats-tpm-based-network-device-attest-14.txt>

This document describes a workflow for remote attestation of the

integrity of firmware and software installed on network devices that
contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
the Trusted Computing Group (TCG)), or equivalent hardware
implementations that include the protected capabilities, as provided
by TPMs.

"A CBOR Tag for Unprotected CWT Claims Sets", Henk Birkholz, Jeremy
O'Donoghue, Nancy Cam-Winget, Carsten Bormann, 2022-07-11,
<draft-ietf-rats-uccs-03.txt>

CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the
protection afforded by wrapping them into COSE, as is required for a
true CWT. This specification defines a CBOR tag for such unprotected
CWT Claims Sets (UCCS) and discusses conditions for its proper use.

"Attestation Event Stream Subscription", Henk Birkholz, Eric Voit, Wei Pan,
2022-03-07, <draft-ietf-rats-network-device-subscription-01.txt>

This memo defines how to subscribe to YANG Event Streams for Remote
Attestation Procedures (RATS). In RATS, Conceptional Messages, are
defined. Analogously, the YANG module defined in this memo augments
the YANG module for TPM-based Challenge-Response based Remote
Attestation (CHARRA) to allow for subscription to remote attestation
Evidence. Additionally, this memo provides the methods and means to
define additional Event Streams for other Conceptual Message as
illustrated in the RATS Architecture, e.g. Attestation Results,
Endorsements, or Event Logs.

"Direct Anonymous Attestation for the Remote Attestation Procedures

Architecture", Henk Birkholz, Christopher Newton, Liqun Chen, Dave Thaler,
2022-07-10, <draft-ietf-rats-daa-01.txt>

This document maps the concept of Direct Anonymous Attestation (DAA)

to the Remote Attestation Procedures (RATS) Architecture. The role
DAA Issuer is introduced and its interactions with existing RATS
roles is specified.

"Attestation Results for Secure Interactions", Eric Voit, Henk Birkholz,

Thomas Hardjono, Thomas Fossati, Vincent Scarlata, 2022-03-07,
<draft-ietf-rats-ar4si-02.txt>

This document defines reusable Attestation Result information

elements. When these elements are offered to Relying Parties as
Evidence, different aspects of Attester trustworthiness can be
evaluated. Additionally, where the Relying Party is interfacing with
a heterogeneous mix of Attesting Environment and Verifier types,
consistent policies can be applied to subsequent information exchange
between each Attester and the Relying Party.

"EAT Media Types", Laurence Lundblade, Henk Birkholz, Thomas Fossati,

2022-09-02, <draft-ietf-rats-eat-media-type-00.txt>

Payloads used in Remote Attestation Procedures may require an

associated media type for their conveyance, for example when used in
RESTful APIs.
 This memo defines media types to be used for Entity Attestation
Tokens (EAT).

Reliable and Available Wireless (raw)

-------------------------------------

"L-band Digital Aeronautical Communications System (LDACS)", Nils Maeurer,

Thomas Graeupl, Corinna Schmitt, 2022-07-27, <draft-ietf-raw-ldacs-12.txt>

This document gives an overview of the architecture of the L-band

Digital Aeronautical Communications System (LDACS), which provides a
secure, scalable and spectrum efficient terrestrial data link for
civil aviation. LDACS is a scheduled, reliable multi-application
cellular broadband system with support for IPv6. It is part of a
larger shift of flight guidance communication moving to IP-based
communication. High reliability and availability of IP connectivity
over LDACS, as well as security, are therefore essential. The intent
of this document is to introduce LDACS to the IETF community, raise
awareness on related activities inside and outside of the IETF, and
to seek expertise in shaping the shift of aeronautics to IP.

"RAW use-cases", Carlos Bernardos, Georgios Papadopoulos, Pascal Thubert,

Fabrice Theoleyre, 2022-02-23, <draft-ietf-raw-use-cases-05.txt>

The wireless medium presents significant specific challenges to

achieve properties similar to those of wired deterministic networks.
At the same time, a number of use-cases cannot be solved with wires
and justify the extra effort of going wireless. This document
presents wireless use-cases (such as aeronautical communications,
amusement parks, industrial applications, pro audio and video,
gaming, UAV and V2V control, edge robotics and emergency vehicles)
demanding reliable and available behavior.

"Operations, Administration and Maintenance (OAM) features for RAW",

Fabrice Theoleyre, Georgios Papadopoulos, Greg Mirsky, Carlos Bernardos,
2022-09-02, <draft-ietf-raw-oam-support-05.txt>

Some critical applications may use a wireless infrastructure.

However, wireless networks exhibit a bandwidth of several orders of
magnitude lower than wired networks. Besides, wireless transmissions
are lossy by nature; the probability that a packet cannot be decoded
correctly by the receiver may be quite high. In these conditions,
providing high reliability and a low delay is challenging. This
document lists the requirements of the Operation, Administration, and
Maintenance (OAM) features are recommended to construct a predictable
communication infrastructure on top of a collection of wireless
segments. This document describes the benefits, problems, and trade-
offs for using OAM in wireless networks to achieve Service Level
Objectives (SLO).

"Reliable and Available Wireless Architecture", Pascal Thubert, Georgios

Papadopoulos, 2022-07-04, <draft-ietf-raw-architecture-05.txt>

Reliable and Available Wireless (RAW) provides for high reliability

and availability for IP connectivity across any combination of wired
and wireless network segments. The RAW Architecture extends the
DetNet Architecture and other standard IETF concepts and mechanisms
to adapt to the specific challenges of the wireless medium. This
document defines an architecture element for the RAW data plane, in
 the form of an OODA loop, that optimizes the use of constrained
spectrum and energy while maintaining the expected connectivity
properties. The loop involves OAM, PCE, and PREOF extensions, and a
new component called the Path Selection Engine (PSE).

"Reliable and Available Wireless Framework", Pascal Thubert, Lou Berger,

2022-06-08, <draft-ietf-raw-framework-01.txt>

Reliable and Available Wireless (RAW) provides for high reliability

and availability for IP connectivity over a wireless medium. The
wireless medium presents significant challenges to achieve
deterministic properties such as low packet error rate, bounded
consecutive losses, and bounded latency. This document defines the
RAW Architecture following an OODA loop that involves OAM, PCE, PSE
and PAREO functions. It builds on the DetNet Architecture and
discusses specific challenges and technology considerations needed to
deliver DetNet service utilizing scheduled wireless segments and
other media, e.g., frequency/time-sharing physical media resources
with stochastic traffic.

Registration Protocols Extensions (regext)

------------------------------------------

"Federated Authentication for the Registration Data Access Protocol (RDAP)

using OpenID Connect", Scott Hollenbeck, 2022-08-18,
<draft-ietf-regext-rdap-openid-17.txt>

The Registration Data Access Protocol (RDAP) provides "RESTful" web

services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext
Transfer Protocol (HTTP). Identification methods that require
clients to obtain and manage credentials from every RDAP server
operator present management challenges for both clients and servers,
whereas a federated authentication system would make it easier to
operate and use RDAP without the need to maintain server-specific
client credentials. This document describes a federated
authentication system for RDAP based on OpenID Connect.

"Registration Data Access Protocol (RDAP) Reverse search capabilities",

Mario Loffredo, Maurizio Martinelli, 2022-08-18,
<draft-ietf-regext-rdap-reverse-search-12.txt>

The Registration Data Access Protocol (RDAP) does not include query
capabilities for finding the list of domains related to a set of
entities matching a given search pattern. In the RDAP context, an
entity can be associated with any defined object class. Moreover,
other relationships between object classes exist and might be used
for providing a reverse search capability. Therefore, a reverse
search can be applied to other use cases than the classic domain-
entity scenario. This document describes an RDAP extension that
allow servers to provide a reverse search feature based on the
relationship defined in RDAP between an object class for search and
any related object class. The reverse search based on the domain-
entity relationship is treated as a particular case.

"Simple Registration Reporting", Joseph Yee, James Galvin, 2022-06-08,

<draft-ietf-regext-simple-registration-reporting-07.txt>
 Domain name registries (the producer) and registrars (the consumer)
report to each other by sharing bulk information through files. This
document creates two IANA registries to establish a standard
reporting mechanism between domain name registries and registrars.
The first IANA registry lists standard data elements and their syntax
for inclusion in the files. The second IANA registry lists standard
reports based on the standard data elements. Each report is a file
formatted as a CSV file. The advantage of this reporting mechanism
is that a report, each file, can be imported by recipients without
any prior knowledge of their contents, although reporting is enhanced
with a minimum of knowledge about the files. The mechanism for the
distribution of and access of the files is a matter of local policy.

"Using JSContact in Registration Data Access Protocol (RDAP) JSON

Responses", Mario Loffredo, Gavin Brown, 2022-08-18,
<draft-ietf-regext-rdap-jscontact-13.txt>

This document describes an RDAP extension which represents entity

contact information in JSON responses using JSContact.

"Use of Internationalized Email Addresses in the Extensible Provisioning

Protocol (EPP)", Dmitry Belyavsky, James Gould, 2022-08-31,
<draft-ietf-regext-epp-eai-16.txt>

This document describes an EPP command-response extension that

permits usage of Internationalized Email Addresses in the EPP
protocol and specifies the terms when it can be used by EPP clients
and servers. The Extensible Provisioning Protocol (EPP), being
developed before the standards for SMTPUTF8 compliant addresses, does
not support such email addresses.

TO BE REMOVED on turning to RFC: The document is edited in the

dedicated github repo (https://github.com/beldmit/eppeai). Please
send your submissions via GitHub.

"Redacted Fields in the Registration Data Access Protocol (RDAP) Response",

James Gould, David Smith, Jody Kolker, Roger Carney, 2022-08-16,
<draft-ietf-regext-rdap-redacted-09.txt>

This document describes an RDAP extension for explicitly identifying

redacted RDAP response fields, using JSONPath as the default
expression language.

"Registration Data Dictionary", Heather Flanagan, Steve Crocker,

2022-07-05, <draft-ietf-regext-datadictionary-02.txt>

Multiple applications related to the registration of names and other

identifiers are built around a list of data elements. There is
currently no unified public list of these data elements, nor is there
an organized and independent change control process. This document
codifies the multiple similar but not quite identical lists of data
elements into a neutral Data Dictionary to be maintained as an
independent IANA Registry. The Data Dictionary defines data elements
but does not specify which ones are to be used in any particular
application; the Data Dictionary is policy-neutral.

Routing In Fat Trees (rift)

---------------------------
 "RIFT: Routing in Fat Trees", Alankar Sharma, Pascal Thubert, Bruno
Rijsman, Dmitry Afanasiev, Tony Przygienda, 2022-01-03,
<draft-ietf-rift-rift-15.txt,.pdf>

This document defines a specialized, dynamic routing protocol for

Clos and fat-tree network topologies optimized towards minimization
of control plane state as well as configuration and operational
complexity.

"A YANG Data Model for Routing in Fat Trees (RIFT)", Zheng Zhang, Yuehua
Wei, Shaowen Ma, Xufeng Liu, Bruno Rijsman, 2022-04-11,
<draft-ietf-rift-yang-06.txt>

This document defines a YANG data model for the configuration and
management of Routing in Fat Trees (RIFT) Protocol.

"RIFT Applicability", Yuehua Wei, Zheng Zhang, Dmitry Afanasiev, Pascal

Thubert, Tony Przygienda, 2021-12-16, <draft-ietf-rift-applicability-10.txt>

This document discusses the properties, applicability and operational

considerations of RIFT in different network scenarios. It intends to
provide a rough guide how RIFT can be deployed to simplify routing
operations in Clos topologies and their variations.

"RIFT Auto-EVPN", Jordan Head, Tony Przygienda, Wen Lin, 2022-06-27,

<draft-ietf-rift-auto-evpn-03.txt>

This document specifies procedures that allow an EVPN overlay to be

fully and automatically provisioned when using RIFT as underlay by
leveraging RIFT's no-touch ZTP architecture.

"RIFT Key/Value Structure and Registry", Jordan Head, Tony Przygienda,

2022-08-25, <draft-ietf-rift-kv-registry-02.txt>

The RIFT (Routing in Fat-Trees) protocol allows for key/value pairs

to be advertised within Key-Value Topology Information Elements (KV-
TIEs). The data contained within these KV-TIEs can be used for any
imaginable purpose. This document defines the various Key-Types
(i.e. Well-Known, OUI, and Experimental) and a method to structure
corresponding values.

"SRIFT: Segment Routing in Fat Trees", Zhaohui Zhang, Jeff Tantsura, Jordan
Head, 2022-07-11, <draft-ietf-rift-sr-00.txt>

This document specifies signaling procedures for Segment Routing in

RIFT. Each node's loopback address, Segment Routing Global Block
(SRGB) and Node Segment Identifier (Node-SID), which are typically
assigned by a configuration management system and distibuted by
routing protocols, are distributed southbound from the Top Of Fabric
(TOF) nodes via RIFT's Key-Value distribution mechanism, so that each
node can compute how to reach a segment represented by the active SID
in a packet. An SR controller signals SR policies to ingress nodes
so that they can send packets with a desired segment list to steer
traffic.

RTP Media Congestion Avoidance Techniques (rmcat)

-------------------------------------------------
 "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in
Interactive Multimedia Conferences", Colin Perkins, 2022-07-11,
<draft-ietf-rmcat-rtp-cc-feedback-10.txt>

This memo discusses the types of congestion control feedback that it

is possible to send using the RTP Control Protocol (RTCP), and their
suitability of use in implementing congestion control for unicast
multimedia applications.

Routing Over Low power and Lossy networks (roll)

------------------------------------------------

"Root initiated routing state in RPL", Pascal Thubert, Rahul Jadhav,

Michael Richardson, 2022-07-25, <draft-ietf-roll-dao-projection-27.txt>

This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a
RPL Root to install and maintain Projected Routes within its DODAG,
along a selected set of nodes that may or may not include itself, for
a chosen duration. This potentially enables routes that are more
optimized or resilient than those obtained with the classical
distributed operation of RPL, either in terms of the size of a
Routing Header or in terms of path length, which impacts both the
latency and the packet delivery ratio.

"Supporting Asymmetric Links in Low Power Networks: AODV-RPL", Charles

Perkins, S.V.R Anand, Satish Anamalamudi, Bing Liu, 2022-06-25,
<draft-ietf-roll-aodv-rpl-14.txt>

Route discovery for symmetric and asymmetric Peer-to-Peer (P2P)

traffic flows is a desirable feature in Low power and Lossy Networks
(LLNs). For that purpose, this document specifies a reactive P2P
route discovery mechanism for both hop-by-hop routes and source
routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
protocol (AODV-RPL). Paired Instances are used to construct
directional paths, for cases where there are asymmetric links between
source and target nodes.

"Common Ancestor Objective Function and Parent Set DAG Metric Container
Extension", Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas
Montavont, Pascal Thubert, 2020-10-29,
<draft-ietf-roll-nsa-extension-10.txt>

Packet Replication and Elimination is a method in which several

copies of a data packet are sent in the network in order to achieve
high reliability and low jitter. This document details how to apply
Packet Replication and Elimination in RPL, especially how to exchange
information within RPL control packets to let a node better select
the different parents that will be used to forward the multiple
copies of a packet. This document also describes the Objective
Function which takes advantage of this information to implement
multi-path routing.

"Controlling Secure Network Enrollment in RPL networks", Michael

Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, 2022-09-01,
<draft-ietf-roll-enrollment-priority-07.txt>

[RFC9032] defines a method by which a potential [RFC9031] enrollment

proxy can announce itself as a available for new Pledges to enroll on
a network. The announcement includes a priority for enrollment.
 This document provides a mechanism by which a RPL DODAG root can
disable enrollment announcements, or adjust the base priority for
enrollment operation.

Real-Time Communication in WEB-browsers (rtcweb)

------------------------------------------------

"JavaScript Session Establishment Protocol (JSEP)", Justin Uberti, Cullen

Jennings, Eric Rescorla, 2022-03-03, <draft-uberti-rtcweb-rfc8829bis-02.txt>

This document describes the mechanisms for allowing a JavaScript

application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API and
discusses how this relates to existing signaling protocols.

This specification obsoletes RFC 8829.

Routing Area (rtg)

------------------

"Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Charles

Perkins, Stan Ratliff, John Dowdell, Lotte Steenbrink, Victoria Pritchard,
2019-02-28, <draft-perkins-manet-aodvv2-03.txt>

The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing

protocol is intended for use by mobile routers in wireless, multihop
networks. AODVv2 determines unicast routes among AODVv2 routers
within the network in an on-demand fashion.

Routing Area Working Group (rtgwg)

----------------------------------

"BGP Prefix Independent Convergence", Ahmed Bashandy, Clarence Filsfils,

Prodosh Mohapatra, 2022-04-09, <draft-ietf-rtgwg-bgp-pic-18.txt>

In a network comprising thousands of BGP peers exchanging millions of

routes, many routes are reachable via more than one next-hop. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed an architecture by which
traffic can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding data
structures in a hierarchical manner and sharing forwarding elements
among the maximum possible number of routes. The proposed technique
achieves prefix independent convergence while ensuring incremental
deployment, complete automation, and zero management and provisioning
effort. It is noteworthy to mention that the benefits of BGP Prefix
Independent Convergence (BGP-PIC) are hinged on the existence of more
than one path whether as ECMP or primary-backup.

"A Simple BGP-based Mobile Routing System for the Aeronautical

Telecommunications Network", Fred Templin, Greg Saccone, Gaurav Dawra, Acee
Lindem, Victor Moreno, 2022-06-14, <draft-ietf-rtgwg-atn-bgp-18.txt>

The International Civil Aviation Organization (ICAO) is investigating

mobile routing solutions for a worldwide Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS).
The ATN/IPS will eventually replace existing communication services
 with an IP-based service supporting pervasive Air Traffic Management
(ATM) for Air Traffic Controllers (ATC), Airline Operations
Controllers (AOC), and all commercial aircraft worldwide. This
informational document describes a simple and extensible mobile
routing service based on industry-standard BGP to address the ATN/IPS
requirements.

"Dynamic Networks to Hybrid Cloud DCs Problem Statement", Linda Dunbar,

Andrew Malis, Christian Jacquenet, Mehmet Toy, Kausik Majumdar, 2022-07-25,
<draft-ietf-rtgwg-net2cloud-problem-statement-15.txt>

This document describes the network-related problems enterprises

face today when interconnecting their branch offices with dynamic
workloads in third-party data centers (a.k.a. Cloud DCs). There can
be many problems associated with connecting to or among Clouds; the
Net2Cloud problem statements are mainly for enterprises who already
have traditional MPLS services and are interested in leveraging
those networks (instead of completely abandoning them). This
document aims to describe the problems of continuing using the MPLS
networks when connecting workloads in the Cloud, and to clarify
additional work in the IETF Routing area. Other problems are out of
the scope of this document.

Current operational problems are examined to determine whether there

is a need to improve existing protocols or whether a new protocol is
necessary to solve them.

"Networks Connecting to Hybrid Cloud DCs: Gap Analysis", Linda Dunbar,

Andrew Malis, Christian Jacquenet, 2022-06-15,
<draft-ietf-rtgwg-net2cloud-gap-analysis-09.txt>

This document analyzes the IETF routing area technical gaps that may
affect the dynamic connection to workloads and applications hosted
in hybrid Cloud Data Centers from enterprise premises.

"RIB Extension YANG Data Model", Acee Lindem, Yingzhen Qu, 2022-05-09,
<draft-ietf-rtgwg-yang-rib-extend-11.txt>

A Routing Information Base (RIB) is a list of routes and their

corresponding administrative data and operational state.

RFC 8349 defines the basic building blocks for RIB, and this model
augments it to support multiple next-hops (aka, paths) for each route
as well as additional attributes.

"YANG Models for Quality of Service (QoS)", Aseem Choudhary, Mahesh

Jethanandani, Ebben Aries, Ing-Wher Chen, 2022-07-07,
<draft-ietf-rtgwg-qos-model-08.txt>

This document describes a YANG model for configuration of Quality of

Service (QoS) configuration in network devices. This document
doesn't describe QoS statistics counters.

"SRv6 Path Egress Protection", Zhibo Hu, China Telecom, Huaimo Chen, Peng
Wu, Mehmet Toy, Chang Cao, Lei Liu, Xufeng Liu, 2022-04-18,
<draft-ietf-rtgwg-srv6-egress-protection-05.txt>

This document describes protocol extensions for protecting the egress

node of a Segment Routing for IPv6 (SRv6) path or tunnel.
 "Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point
Networks in Virtual Router Redundancy Protocol (VRRP)", Greg Mirsky, Jeff
Tantsura, Gyan Mishra, 2022-03-31, <draft-ietf-rtgwg-vrrp-p2mp-bfd-02.txt>

This document discusses the applicability of Bidirectional Forwarding

Detection (BFD) for multipoint networks to provide Virtual Router
Redundancy Protocol (VRRP) with sub-second convergence of the Active
router and defines the extension to bootstrap point-to-multipoint BFD
session.

This draft updates RFC 5798.

"Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6",
Acee Lindem, Aditya Dogra, 2022-07-24,
<draft-ietf-rtgwg-vrrp-rfc5798bis-00.txt>

This document defines the Virtual Router Redundancy Protocol (VRRP)

for IPv4 and IPv6. It is version three (3) of the protocol, and it
is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and
in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an
election protocol that dynamically assigns responsibility for a
virtual router to one of the VRRP routers on a LAN. The VRRP router
controlling the IPv4 or IPv6 address(es) associated with a virtual
router is called the VRRP Active Router, and it forwards packets sent
to these IPv4 or IPv6 addresses. VRRP Active Routers are configured
with virtual IPv4 or IPv6 addresses, and VRRP Backup Routers infer
the address family of the virtual addresses being advertised based on
the IP protocol version. Within a VRRP router, the virtual routers
in each of the IPv4 and IPv6 address families are a domain unto
themselves and do not overlap. The election process provides dynamic
failover in the forwarding responsibility should the Active Router
become unavailable. For IPv4, the advantage gained from using VRRP
is a higher-availability default path without requiring configuration
of dynamic routing or router discovery protocols on every end-host.
For IPv6, the advantage gained from using VRRP for IPv6 is a quicker
switchover to Backup Routers than can be obtained with standard IPv6
Neighbor Discovery mechanisms.

The VRRP terminology has been updated conform to inclusive language

guidelines for IETF technologies. The IETF has designated National
Institute of Standards and Technology (NIST) "Guidance for NIST Staff
on Using Inclusive Language in Documentary Standards" for its
inclusive language guidelines. This document obsoletes VRRP Version
3 [RFC5798].

Security Automation and Continuous Monitoring (sacm)

----------------------------------------------------

"Concise Software Identification Tags", Henk Birkholz, Jessica

Fitzgerald-McKay, Charles Schmidt, David Waltermire, 2022-07-20,
<draft-ietf-sacm-coswid-22.txt>

ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an

extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
 semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.

System for Cross-domain Identity Management (scim)

--------------------------------------------------

"SCIM Profile for Security Event Tokens", Phillip Hunt, Nancy Cam-Winget,
2022-07-11, <draft-ietf-scim-events-00.txt>

This specification profiles the Security Event Token specification

RFC8417, to define a set of events for SCIM Protocol servers that can
be used for asynchronous transaction confirmations, replication,
cross-domain provisioning co-ordination, and security signals.

Security Area (sec)

-------------------

"Domain-based signing and encryption using S/MIME", William Ottaway, Alexey

Melnikov, 2014-03-05, <draft-melnikov-smime-msa-to-mda-04.txt>

The S/MIME protocols Message Specification (RFC 5751), Cryptographic

Message Syntax (RFC 5652), S/MIME Certificate Handling (RFC 5750) and
Enhanced Security Services for S/MIME (RFC 2634) specify a consistent
way to securely send and receive MIME messages providing end to end
integrity, authentication, non-repudiation and confidentiality. This
document identifies a number of interoperability, technical,
procedural and policy related issues that may result in end-to-end
security services not being achievable. To resolve such issues, this
document profiles domain-based signing and encryption using S/MIME,
such as specifying how S/MIME signing and encryption can be applied
between a Message Submission Agent (MSA) and a Message Delivery Agent
(MDA) or between 2 Message Transfer Agents (MTA).

This document is also registering 2 URI scheme: "smtp" and "submit"

which are used for designating SMTP/SMTP Submission servers
(respectively), as well as SMTP/Submission client accounts.

"Security Considerations for Transient Numeric Identifiers Employed in

Network Protocols", Fernando Gont, Ivan Arce, 2022-02-01,
<draft-gont-numeric-ids-sec-considerations-07.txt>

Poor selection of transient numerical identifiers in protocols such

as the TCP/IP suite has historically led to a number of attacks on
implementations, ranging from Denial of Service (DoS) to data
injection and information leakage that can be exploited by pervasive
monitoring. To prevent such flaws in future protocols and
implementations, this document updates RFC 3552, requiring future
RFCs to contain a vulnerability assessment of their transient numeric
identifiers.

"Update to the IANA SSH Protocol Paremeters Registry Requirements", Peter

Yee, 2022-01-10, <draft-yee-ssh-iana-requirements-00.txt>

This specification updates the requirements for adding new entries to

the IANA Secure Shell (SSH) Protocol Parameters registry. Currently,
the requirement is generally for "IETF Review", as defined in RFC
8126, although a few portions of the registry require "Standards
Action". This specification will change that former requirement to
 "Expert Review".

Security Events (secevent)

--------------------------

"Subject Identifiers for Security Event Tokens", Annabelle Backman, Marius

Scurtescu, Prachi Jain, 2022-07-24,
<draft-ietf-secevent-subject-identifiers-12.txt>

Security events communicated within Security Event Tokens may support

a variety of identifiers to identify subjects related to the event.
This specification formalizes the notion of subject identifiers as
structured information that describe a subject, and named formats
that define the syntax and semantics for encoding subject identifiers
as JSON objects. It also defines a registry for defining and
allocating names for such formats, as well as the sub_id JSON Web
Token (JWT) claim.

Serialising Extended Data About Times and Events (sedate)

---------------------------------------------------------

"Date and Time on the Internet: Timestamps with additional information",

Ujjwal Sharma, Carsten Bormann, 2022-07-11,
<draft-ietf-sedate-datetime-extended-05.txt>

This document defines an extension to the timestamp format defined in

RFC3339 for representing additional information including a time
zone.

// The present version (-05) includes a few changes that are intended
// for discussion at IETF 114. In particular, the introduction of
// the critical-flag exposes the fact that some RFC 3339
// implementations assign different semantics to the time zone
// offsets Z and +00:00; we may want to consider ways to cope with
// this apparently common deviation. Also, the name of the format is
// still up for suggestions that improve upon the current choice.

Service Function Chaining (sfc)

-------------------------------

"Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data",
Frank Brockners, Shwetha Bhandari, 2022-05-18,
<draft-ietf-sfc-ioam-nsh-10.txt>

In-situ Operations, Administration, and Maintenance (IOAM) is used

for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
This document outlines how IOAM data fields are encapsulated with the
Network Service Header (NSH).

"Active OAM for Service Function Chaining (SFC)", Greg Mirsky, Wei Meng,
Ting Ao, Bhumip Khasnabish, Kent Leung, Gyan Mishra, 2022-07-25,
<draft-ietf-sfc-multi-layer-oam-22.txt>

A set of requirements for active Operation, Administration, and

Maintenance (OAM) of Service Function Chains (SFCs) in a network is
presented in this document. Based on these requirements, an
encapsulation of active OAM messages in SFC and a mechanism to detect
 and localize defects are described.

"Explicit Congestion Notification (ECN) and Congestion Feedback Using the

Network Service Header (NSH) and IPFIX", Donald Eastlake, Bob Briscoe,
Yizhou Li, Andrew Malis, Xinpeng Wei, 2022-04-18,
<draft-ietf-sfc-nsh-ecn-support-09.txt>

Explicit congestion notification (ECN) allows a forwarding element to

notify downstream devices of the onset of congestion without having
to drop packets. Coupled with a means to feed information about
congestion back to upstream nodes, this can improve network
efficiency through better congestion control, frequently without
packet drops. This document specifies ECN and congestion feedback
support within a Service Function Chaining (SFC) enabled domain
through use of the Network Service Header (NSH, RFC 8300) and IP Flow
Information Export (IPFIX, RFC 7011).

"OAM Packet and Behavior in the Network Service Header (NSH)", Mohamed
Boucadair, 2022-04-25, <draft-ietf-sfc-oam-packet-01.txt>

This document clarifies an ambiguity in the Network Service Header

(NSH) specification related to the handling of O bit. In particular,
this document clarifies the meaning of "OAM packet".

This document updates RFC 8300.

Secure Media Frames (sframe)

----------------------------

"Secure Frame (SFrame)", Emad Omara, Justin Uberti, Sergio Murillo, Richard
Barnes, Youenn Fablet, 2022-07-29, <draft-ietf-sframe-enc-00.txt>

This document describes the Secure Frame (SFrame) end-to-end

encryption and authentication mechanism for media frames in a
multiparty conference call, in which central media servers (SFUs) can
access the media metadata needed to make forwarding decisions without
having access to the actual media. The proposed mechanism differs
from other approaches through its use of media frames as the
encryptable unit, instead of individual RTP packets, which makes it
more bandwidth efficient and also allows use with non-RTP transports.

Stay Home Meet Occasionally Online (shmoo)

------------------------------------------

"Open Participation Principle regarding Remote Registration Fee", Mirja

Kuehlewind, Jonathan Reed, Rich Salz, 2022-06-03,
<draft-ietf-shmoo-remote-fee-03.txt>

This document outlines a principle for open participation that

extends the open process principle defined in RFC3935 by stating that
there must always be a free option for online participation to IETF
meetings and, if possible, related IETF-hosted events over the
Internet.

"Running an IETF Hackathon", Charles Eckel, 2022-07-26,

<draft-ietf-shmoo-hackathon-08.txt>

IETF Hackathons encourage the IETF community to collaborate on

running code related to existing and evolving Internet standards.
 This document provides a set of practices that have been used for
running IETF Hackathons. These practices apply to Hackathons in
which both in-person and remote participation are possible with
adaptations for Hackathons that are online only.

"Guidelines for the Organization of Fully Online Meetings", Mirja

Kuehlewind, Martin Duke, 2022-07-11,
<draft-ietf-shmoo-online-meeting-00.txt>

This document provides guidelines for the planning and organization

of fully online meetings, regarding the number, length, and
composition of sessions on the meeting agenda. These guidelines are
based on the experience during the COVID-19 pandemic.

SIDR Operations (sidrops)

-------------------------

"Use Cases for Localized Versions of the RPKI", Randy Bush, 2019-04-30,
<draft-ietf-sidrops-lta-use-cases-06.txt>

There are a number of critical circumstances where a localized

routing domain needs to augment or modify its view of the Global
RPKI. This document attempts to outline a few of them.

"RPKI Signed Object for Trust Anchor Key", Carlos Martinez, George
Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein, 2022-07-11,
<draft-ietf-sidrops-signed-tal-10.txt>

A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the

Resource Public Key Infrastructure (RPKI) to locate and validate a
Trust Anchor (TA) Certification Authority (CA) certificate used in
RPKI validation. This document defines an RPKI signed object for a
Trust Anchor Key (TAK), that can be used by a TA to signal the
location(s) of the accompanying CA certificate for the current key to
RPs, as well as the successor key and the location(s) of its CA
certificate. This object helps to support planned key rolls without
impacting RPKI validation.

"The Use of maxLength in the RPKI", Yossi Gilad, Sharon Goldberg,

Kotikalapudi Sriram, Job Snijders, Ben Maddison, 2022-08-14,
<draft-ietf-sidrops-rpkimaxlen-15.txt>

This document recommends ways to reduce the forged-origin hijack

attack surface by prudently limiting the set of IP prefixes that are
included in a Route Origin Authorization (ROA). One recommendation
is to avoid using the maxLength attribute in ROAs except in some
specific cases. The recommendations complement and extend those in
RFC 7115. The document also discusses the creation of ROAs for
facilitating the use of Distributed Denial of Service (DDoS)
mitigation services. Considerations related to ROAs and origin
validation in the context of destination-based Remotely Triggered
Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered
Black Hole") filtering are also highlighted.

"BGP AS_PATH Verification Based on Resource Public Key Infrastructure

(RPKI) Autonomous System Provider Authorization (ASPA) Objects", Alexander
Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Job Snijders,
2022-07-11, <draft-ietf-sidrops-aspa-verification-09.txt>
 This document defines the semantics of an Autonomous System Provider
Authorization object in the Resource Public Key Infrastructure to
verify the AS_PATH attribute of routes advertised in the Border
Gateway Protocol. This AS_PATH verification is primarily intended
for detection and mitigation of route leaks. It also provides
protection against forged-origin prefix hijacks.

"A Profile for Autonomous System Provider Authorization", Alexander Azimov,

Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison,
2022-08-12, <draft-ietf-sidrops-aspa-profile-10.txt>

This document defines a standard profile for Autonomous System

Provider Authorization in the Resource Public Key Infrastructure. An
Autonomous System Provider Authorization is a digitally signed object
that provides a means of validating that a Customer Autonomous System
holder has authorized members of Provider set to be its upstream
providers or provide route server service at internet exchange point.
For the Providers it means that they are legal to send prefixes
received from the Customer Autonomous System in all directions
including providers and peers.

"The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version

2", Randy Bush, Rob Austein, 2022-06-16, <draft-ietf-sidrops-8210bis-10.txt>

In order to verifiably validate the origin Autonomous Systems and

Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver them.

This document describes version 2 of the RPKI-Router protocol. RFC

6810 describes version 0, and RFC 8210 describes version 1. This
document is compatible with both.

"A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists
(RSC)", Job Snijders, Tom Harrison, Ben Maddison, 2022-08-15,
<draft-ietf-sidrops-rpki-rsc-10.txt>

This document defines a Cryptographic Message Syntax (CMS) protected

content type for use with the Resource Public Key Infrastructure
(RPKI) to carry a general purpose listing of checksums (a
'checklist'). The objective is to allow an attestation, termed an
RPKI Signed Checklist (RSC), which contains one or more checksums of
arbitrary digital objects (files) that are signed "with resources",
and which, when validated, confirms that the respective Internet
Resource Holder produced the RSC.

"Avoidance for ROA Containing Multiple IP Prefixes", Zhiwei Yan, Randy

Bush, Guanggang Geng, Ties de Kock, 2022-08-09,
<draft-ietf-sidrops-roa-considerations-03.txt>

In RPKI, the address space holder needs to issue an ROA object when
authorizing one or more ASes to originate routes to IP prefix(es).
During ROA issurance process, the address space holder may need to
specify an origin AS for a list of IP prefixes. Additionally, the
address space holder is free to choose to put multiple prefixes into
a single ROA or issue separate ROAs for each prefix according to the
current specification. This memo analyzes some operational problems
which may arise from ROAs containing multiple IP prefixes and
 recommends avoiding placing multiple IP prefixes in one ROA.

"RPKI-Based Policy Without Route Refresh", Randy Bush, Keyur Patel, Philip
Smith, Mark Tinka, 2022-08-26, <draft-ietf-sidrops-rov-no-rr-07.txt>

A BGP Speaker performing RPKI-based policy should not issue Route

Refresh to its neighbors because it has received new RPKI data. This
document updates [RFC8481] by describing how to avoid doing so by
either keeping a full Adj-RIB-In or saving paths dropped due to ROV
(Route Origin Validation) so they may be reevaluated with respect to
new RPKI data.

Session Initiation Protocol Core (sipcore)

------------------------------------------

"SIP Call-Info Parameters for Labeling Calls", Henning Schulzrinne,

2019-08-30, <draft-ietf-sipcore-callinfo-spam-04.txt>

Called parties often wish to decide whether to accept, reject or

redirect calls based on the likely nature of the call. For example,
they may want to reject unwanted telemarketing or fraudulent calls,
but accept emergency alerts from numbers not in their address book.
This document describes SIP Call-Info parameters and a feature tag
that allow originating, intermediate and terminating SIP entities to
label calls as to their type, confidence and references to additional
information.

"SIP Call-Info Parameters for Rich Call Data", Chris Wendt, Jon Peterson,
2022-03-07, <draft-ietf-sipcore-callinfo-rcd-04.txt>

This document describes a SIP Call-Info header field usage defined to

include rich data associated with the identity of the calling party
that can be rendered to a called party for providing more useful
information about the caller or the specific reason for the call.
This includes extended comprehensive information about the caller
such as what a jCard object can represent for describing the calling
party or other call specific information such as describing the
reason or intent of the call. The elements defined for this purpose
are intended to be extensible to accommodate related information
about calls that helps people decide whether to pick up the phone and
additionally, with the use of jCard and other elements, to be
compatible with the STIR/PASSporT Rich Call Data framework.

"Multiple SIP Reason Header Field Values", Robert Sparks, 2022-08-23,

<draft-ietf-sipcore-multiple-reasons-01.txt>

The SIP Reason Header Field as defined in RFC 3326 allows only one
Reason value per protocol value. Experience with more recently
defined protocols shows it is useful to allow multiple values with
the same protocol value. This update to RFC 3326 allows multiple
values for an indicated registered protocol when that protocol
defines what the presence of multiple values means.

Source Packet Routing in Networking (spring)

--------------------------------------------

"Path Segment in MPLS Based Segment Routing Network", Weiqiang Cheng, Han
Li, Mach Chen, Rakesh Gandhi, Royi Zigler, 2021-12-20,
<draft-ietf-spring-mpls-path-segment-07.txt>
 A Segment Routing (SR) path is identified by an SR segment list.
Only the complete segment list can identify the end-to-end SR path,
and a sub-set of segments from the segment list cannot distinguish
one SR path from another as they may be partially congruent. SR path
identification is a pre-requisite for various use-cases such as
Performance Measurement (PM), bidirectional paths correlation, and
end-to-end 1+1 path protection.

In SR for MPLS data plane (SR-MPLS), the segment identifiers are

stripped from the packet through label popping as the packet transits
the network. This means that when a packet reaches the egress of the
SR path, it is not possible to determine on which SR path it
traversed the network.

This document defines a new type of segment that is referred to as

Path Segment, which is used to identify an SR path in an SR-MPLS
network. When used, it is inserted by the ingress node of the SR
path and immediately follows the last segment identifier in the
segment list of the SR path. The Path Segment is preserved until it
reaches the egress node for SR path identification and correlation.

"Integration of Network Service Header (NSH) and Segment Routing for

Service Function Chaining (SFC)", Jim Guichard, Jeff Tantsura, 2022-04-20,
<draft-ietf-spring-nsh-sr-11.txt>

This document describes the integration of the Network Service Header

(NSH) and Segment Routing (SR), as well as encapsulation details, to
support Service Function Chaining (SFC) in an efficient manner while
maintaining separation of the service and transport planes as
originally intended by the SFC architecture.

Combining these technologies allows SR to be used for steering

packets between Service Function Forwarders (SFF) along a given
Service Function Path (SFP) while NSH has the responsibility for
maintaining the integrity of the service plane, the SFC instance
context, and any associated metadata.

This integration demonstrates that NSH and SR can work cooperatively

and provide a network operator with the flexibility to use whichever
transport technology makes sense in specific areas of their network
infrastructure while still maintaining an end-to-end service plane
using NSH.

"Service Programming with Segment Routing", Francois Clad, Xiaohu Xu,

Clarence Filsfils, Daniel Bernier, Cheng Li, Bruno Decraene, Shaowen Ma,
Chaitanya Yadlapalli, Wim Henderickx, Stefano Salsano, 2022-06-09,
<draft-ietf-spring-sr-service-programming-06.txt>

This document defines data plane functionality required to implement

service segments and achieve service programming in SR-enabled MPLS
and IPv6 networks, as described in the Segment Routing architecture.

"SR Replication Segment for Multi-point Service Delivery", Dan Voyer,

Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang,
2022-07-01, <draft-ietf-spring-sr-replication-segment-08.txt>

This document describes the SR Replication segment for Multi-point

service delivery. A SR Replication segment allows a packet to be
 replicated from a Replication Node to Downstream nodes.

"Introducing Resource Awareness to SR Segments", Jie Dong, Stewart Bryant,

Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, Francois Clad,
2022-03-05, <draft-ietf-spring-resource-aware-segments-04.txt>

This document describes the mechanism to associate network resource

attributes to Segment Routing Identifiers (SIDs). Such SIDs are
referred to as resource-aware SIDs in this document. The resource-
aware SIDs retain their original forwarding semantics, but with the
additional semantics to identify the set of network resources
available for the packet processing and forwarding action. The
resource-aware SIDs can therefore be used to build SR paths or
virtual networks with a set of reserved network resources. The
proposed mechanism is applicable to both segment routing with MPLS
data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).

"Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using

MPLS Dataplane", Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen,
Jiang Wenying, 2022-04-26, <draft-ietf-spring-bfd-04.txt>

Segment Routing (SR) architecture leverages the paradigm of source

routing. It can be realized in the Multiprotocol Label Switching
(MPLS) network without any change to the data plane. A segment is
encoded as an MPLS label, and an ordered list of segments is encoded
as a stack of labels. Bidirectional Forwarding Detection (BFD) is
expected to monitor any existing path between systems. This document
defines how to use Label Switched Path Ping to bootstrap a BFD
session, control an SR Policy in the reverse direction of the SR-MPLS
tunnel, and applicability of BFD Demand mode in the SR-MPLS domain.
Also, the document describes the use of BFD Echo with BFD Control
packet payload.

"Segment Protection for SR-TE Paths", Shraddha Hegde, Chris Bowers,

Stephane Litkowski, Xiaohu Xu, Feng Xu, 2022-03-07,
<draft-ietf-spring-segment-protection-sr-te-paths-03.txt>

Segment routing supports the creation of explicit paths using Adj-

Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide
fast reroute (FRR) mechanisms to respond to failures of links and
nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point
of local repair (PLR) can provide FRR protection against the failure
of a link in an SR-TE path by examining only the first (top) label in
the SR label stack. In order to protect against the failure of a
node, a PLR may need to examine the second label in the stack as
well, in order to determine SR-TE path beyond the failed node. This
document specifies how a PLR can use the first and second label in
the SR-MPLS label stack describing an SR-TE path to provide
protection against node failures.

"Path Segment for SRv6 (Segment Routing in IPv6)", Cheng Li, Weiqiang
Cheng, Mach Chen, Dhruv Dhody, Yongqing Zhu, 2022-08-13,
<draft-ietf-spring-srv6-path-segment-04.txt>

Segment Routing (SR) allows for a flexible definition of end-to-end

paths by encoding an ordered list of instructions, called "segments".
The SR architecture can be implemented over an MPLS data plane as
well as an IPv6 data plane.
 Currently, Path Segment has been defined to identify an SR path in
SR-MPLS networks, and is used for various use-cases such as end-to-
end SR Path Protection and Performance Measurement (PM) of an SR
path. This document defines the Path Segment to identify an SRv6
path in an IPv6 network.

"Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN",
Jie Dong, Stewart Bryant, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin,
Zhenqiang Li, Francois Clad, 2022-03-05,
<draft-ietf-spring-sr-for-enhanced-vpn-02.txt>

Segment Routing (SR) leverages the source routing paradigm. A node

steers a packet through an ordered list of instructions, called
"segments". A segment can represent topological or service based
instructions. A segment can further be associated with a set of
network resources used for executing the instruction. Such a segment
is called resource-aware segment.

Resource-aware Segment Identifiers (SIDs) may be used to build SR

paths with a set of reserved network resources. In addition, a group
of resource-aware SIDs may be used to build SR based virtual underlay
networks, which have customized network topology and resource
attributes required by one or a group of customers and/or services.
Such virtual networks are the SR instantiations of Virtual Transport
Networks (VTNs).

This document describes a suggested use of resource-aware SIDs to

build SR based VTNs.

"Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing

Networks", Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart
Janssens, Richard Foote, 2022-08-25, <draft-ietf-spring-stamp-srpm-05.txt>

Segment Routing (SR) leverages the source routing paradigm. SR is

applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) data planes. This document describes procedures for
Performance Measurement in SR networks using the mechanisms defined
in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and
its optional extensions defined in RFC 8972 and further augmented in
draft-ietf-ippm-stamp-srpm. The procedure described is applicable to
SR-MPLS and SRv6 data planes and is used for both links and end-to-
end SR paths including SR Policies.

"Compressed SRv6 SID List Requirements", Weiqiang Cheng, Chongfeng Xie, Ron
Bonica, Darren Dukes, Cheng Li, Shaofu Peng, Wim Henderickx, 2022-03-28,
<draft-ietf-spring-compression-requirement-01.txt>

This document specifies requirements for solutions to compress SRv6

SID lists.

"Compressed SRv6 SID List Analysis", Ron Bonica, Weiqiang Cheng, Darren
Dukes, Wim Henderickx, Cheng Li, Shaofu Peng, Chongfeng Xie, 2022-03-28,
<draft-ietf-spring-compression-analysis-01.txt>

Several mechanisms have been proposed to compress the SRv6 SID list.
This document analyzes each mechanism with regard to the requirements
stated in the companion requirements document.

"Compressed SRv6 Segment List Encoding in SRH", Weiqiang Cheng, Clarence

 Filsfils, Zhenbin Li, Bruno Decraene, Dezhong Cai, Dan Voyer, Francois
Clad, Shay Zadok, Jim Guichard, Aihua Liu, Robert Raszuk, Cheng Li,
2022-07-11, <draft-ietf-spring-srv6-srh-compression-02.txt>

This document specifies new flavors for the SR endpoint behaviors

defined in RFC 8986, which enable a compressed SRv6 Segment-List
encoding in the Segment Routing Header (SRH).

Secure Telephone Identity Revisited (stir)

------------------------------------------

"OCSP Usage for Secure Telephone Identity Certificates", Jon Peterson, Sean
Turner, 2022-07-11, <draft-ietf-stir-certificates-ocsp-02.txt>

When certificates are used as credentials to attest the assignment or

ownership of telephone numbers, some mechanism is required to convey
certificate freshness to relying parties. Certififcate Revocation
Lists (CRLs) are commonly used for this purpose, but for certain
classes of certificates, including delegate certificates conveying
their scope of authority by-reference in Secure Telephone Identity
Revisited (STIR) systems, they may not be aligned with the needs of
relying parties. This document specifies the use of the Online
Certificate Status Protocol (OCSP) as a means of retrieving real-time
status information about such certificates, defining new extensions
to compensate for the dynamism of telephone number assignments.

"PASSporT Extension for Rich Call Data", Chris Wendt, Jon Peterson,
2022-07-25, <draft-ietf-stir-passport-rcd-19.txt>

This document extends PASSporT, a token for conveying

cryptographically-signed call information about personal
communications, to include rich meta-data about a call and caller
that can be signed and integrity protected, transmitted, and
subsequently rendered to the called party. This framework is
intended to include and extend caller and call specific information
beyond human-readable display name comparable to the "Caller ID"
function common on the telephone network and is also enhanced with a
integrity mechanism that is designed to protect the authoring and
transport of this information for different authoritative use-cases.

"Out-of-Band STIR for Service Providers", Jon Peterson, 2022-04-21,

<draft-ietf-stir-servprovider-oob-02.txt>

The Secure Telephone Identity Revisited (STIR) framework defines

means of carrying its Persona Assertion Tokens (PASSporTs) either in-
band, within the headers of a SIP request, or out-of-band, through a
service that stores PASSporTs for retrieval by relying parties. This
specification defines a way that the out-of-band conveyance of
PASSporTs can be used to support large service providers, for cases
in which in-band STIR conveyance is not universally available.

"Messaging Use Cases and Extensions for STIR", Jon Peterson, Chris Wendt,
2022-07-25, <draft-ietf-stir-messaging-04.txt>

Secure Telephone Identity Revisited (STIR) provides a means of

attesting the identity of a telephone caller via a signed token in
order to prevent impersonation of a calling party number, which is a
key enabler for illegal robocalling. Similar impersonation is
sometimes leveraged by bad actors in the text and multimedia
 messaging space. This document explores the applicability of STIR's
Personal Assertion Token (PASSporT) and certificate issuance
framework to text and multimedia messaging use cases, including
support both for messages carried as a payload in SIP requests and
for messages sent in sessions negotiated by SIP.

"Identity Header Errors Handling", Chris Wendt, 2022-08-19,

<draft-ietf-stir-identity-header-errors-handling-03.txt>

This document extends STIR and the Authenticated Identity Management

in the Session Initiation Protocol (SIP) error handling procedures to
include the mapping of verification failure reasons to STIR defined
4xx codes so the failure reason of an Identity header field can be
conveyed to the upstream authentication service when local policy
dictates that the call should continue in the presence of a
verification failure. This document also defines procedures that
enable enable a failure reason to be mapped to a specific Identity
header for scenarios that use multiple Identity header fields where
some may have errors and others may not and the handling of those
situations is defined.

"Connected Identity for STIR", Jon Peterson, Chris Wendt, 2022-04-21,

<draft-ietf-stir-rfc4916-update-00.txt>

The SIP Identity header conveys cryptographic identity information

about the originators of SIP requests. The Secure Telephone Identity
Revisited (STIR) framework however provides no means for determining
the identity of the called party in a traditional telephone calling
scenario. This document updates prior guidance on the "connected
identity" problem to reflect the changes to SIP Identity that
accompanied STIR, and considers a revised problem space for connected
identity as a means of detecting calls that have been retargeted to a
party impersonating the intended destination, as well as the spoofing
of mid-dialog or dialog-terminating events by intermediaries or third
parties.

Software Updates for Internet of Things (suit)

----------------------------------------------

"A Concise Binary Object Representation (CBOR)-based Serialization Format

for the Software Updates for Internet of Things (SUIT) Manifest", Brendan
Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, 2022-08-09,
<draft-ietf-suit-manifest-19.txt>

This specification describes the format of a manifest. A manifest is

a bundle of metadata about code/data obtained by a recipient (chiefly
the firmware for an IoT device), where to find the that code/data,
the devices to which it applies, and cryptographic information
protecting the manifest. Software updates and Trusted Invocation
both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the
metadata.

"Firmware Encryption with SUIT Manifests", Hannes Tschofenig, Russ Housley,

Brendan Moran, 2022-07-11, <draft-ietf-suit-firmware-encryption-06.txt>

This document specifies a firmware update mechanism where the

firmware image is encrypted. Firmware encryption uses the IETF SUIT
manifest with key establishment provided by hybrid public-key
 encryption (HPKE) and AES Key Wrap (AES-KW). HPKE uses public key
cryptography while AES-KW uses a pre-shared key-encryption key.
Encryption of the firmware image is accomplished with convential
symmetric key cryptography.

"Secure Reporting of Update Status", Brendan Moran, Henk Birkholz,

2022-07-11, <draft-ietf-suit-report-02.txt>

The Software Update for the Internet of Things (SUIT) manifest

provides a way for many different update and boot workflows to be
described by a common format. However, this does not provide a
feedback mechanism for developers in the event that an update or boot
fails.

This specification describes a lightweight feedback mechanism that

allows a developer in possession of a manifest to reconstruct the
decisions made and actions performed by a manifest processor.

"Update Management Extensions for Software Updates for Internet of Things

(SUIT) Manifests", Brendan Moran, 2022-03-07,
<draft-ietf-suit-update-management-00.txt>

This specification describes extensions to the SUIT manifest format

defined in [I-D.ietf-suit-manifest]. These extensions allow an
update author, update distributor or device operator to more
precisely control the distribution and installation of updates to IoT
devices. These extensions also provide a mechanism to inform a
management system of Software Identifier and Software Bill Of
Materials information about an updated device.

"SUIT Manifest Extensions for Multiple Trust Domains", Brendan Moran,

2022-03-07, <draft-ietf-suit-trust-domains-00.txt>

This specification describes extensions to the SUIT manifest format

(as defined in [I-D.ietf-suit-manifest]) for use in deployments with
multiple trust domains. A device has more than one trust domain when
it uses different trust anchors for different purposes or components
in the context of firmware update.

"Strong Assertions of IoT Network Access Requirements", Brendan Moran,

Hannes Tschofenig, 2022-03-23, <draft-ietf-suit-mud-00.txt>

The Manufacturer Usage Description (MUD) specification describes the

access and network functionality required a device to properly
function. The MUD description has to reflect the software running on
the device and its configuration. Because of this, the most
appropriate entity for describing device network access requirements
is the same as the entity developing the software and its
configuration.

A network presented with a MUD file by a device allows detection of

misbehavior by the device software and configuration of access
control.

This document defines a way to link a SUIT manifest to a MUD file

offering a stronger binding between the two.

Thing-to-Thing (t2trg)
----------------------
 "Guidance on RESTful Design for Internet of Things Systems", Ari Keranen,
Matthias Kovatsch, Klaus Hartke, 2022-07-11,
<draft-irtf-t2trg-rest-iot-10.txt>

This document gives guidance for designing Internet of Things (IoT)

systems that follow the principles of the Representational State
Transfer (REST) architectural style. This document is a product of
the IRTF Thing-to-Thing Research Group (T2TRG).

"IoT Edge Challenges and Functions", Jungha Hong, Yong-Geun Hong, Xavier de
Foy, Matthias Kovatsch, Eve Schooler, Dirk Kutscher, 2022-06-23,
<draft-irtf-t2trg-iot-edge-07.txt>

Many IoT applications have requirements that cannot be met by the

traditional Cloud (aka cloud computing). These include time
sensitivity, data volume, connectivity cost, operation in the face of
intermittent services, privacy, and security. As a result, the IoT
is driving the Internet toward Edge computing. This document
outlines the requirements of the emerging IoT Edge and its
challenges. It presents a general model, and major components of the
IoT Edge, to provide a common base for future discussions in T2TRG
and other IRTF and IETF groups. This document is a product of the
IRTF Thing-to-Thing Research Group (T2TRG).

"Terminology and processes for initial security setup of IoT devices",

Mohit Sethi, Behcet Sarikaya, Dan Garcia-Carrillo, 2022-04-25,
<draft-irtf-t2trg-secure-bootstrapping-02.txt>

This document provides an overview of terms that are commonly used

when discussing the initial security setup of Internet of Things
(IoT) devices. This document also presents a brief but illustrative
survey of protocols and standards available for initial security
setup of IoT devices. For each protocol, we identify the terminology
used, the entities involved, the initial assumptions, the processes
necessary for completetion, and the knowledge imparted to the IoT
devices after the setup is complete.

Transport Services (taps)

-------------------------

"An Architecture for Transport Services", Tommy Pauly, Brian Trammell, Anna
Brunstrom, Gorry Fairhurst, Colin Perkins, 2022-06-27,
<draft-ietf-taps-arch-13.txt>

This document describes an architecture for exposing transport

protocol features to applications for network communication, a
Transport Services system. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams. This document further defines
common terminology and concepts to be used in definitions of a
Transport Service API and a Transport Services implementation.

"An Abstract Application Layer Interface to Transport Services", Brian

Trammell, Michael Welzl, Reese Enghardt, Gorry Fairhurst, Mirja Kuehlewind,
Colin Perkins, Philipp Tiesel, Tommy Pauly, 2022-08-31,
 <draft-ietf-taps-interface-16.txt>

This document describes an abstract application programming

interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime. This
API enables faster deployment of new protocols and protocol features
without requiring changes to the applications. The specified API
follows the Transport Services architecture by providing
asynchronous, atomic transmission of messages. It is intended to
replace the BSD sockets API as the common interface to the transport
layer, in an environment where endpoints could select from multiple
interfaces and potential transport protocols.

"Implementing Interfaces to Transport Services", Anna Brunstrom, Tommy

Pauly, Reese Enghardt, Philipp Tiesel, Michael Welzl, 2022-08-31,
<draft-ietf-taps-impl-13.txt>

The Transport Services system enables applications to use transport

protocols flexibly for network communication and defines a protocol-
independent Transport Services Application Programming Interface
(API) that is based on an asynchronous, event-driven interaction
pattern. This document serves as a guide to implementation on how to
build such a system.

TCP Maintenance and Minor Extensions (tcpm)

-------------------------------------------

"TCP Extended Data Offset Option", Joseph Touch, Wesley Eddy, 2022-04-15,
<draft-ietf-tcpm-tcp-edo-12.txt>

TCP segments include a Data Offset field to indicate space for TCP
options but the size of the field can limit the space available for
complex options such as SACK and Multipath TCP and can limit the
combination of such options supported in a single connection. This
document updates RFC 793 with an optional TCP extension to that
space to support the use of multiple large options. It also explains
why the initial SYN of a connection cannot be extending a single
segment.

"More Accurate ECN Feedback in TCP", Bob Briscoe, Mirja Kuehlewind, Richard
Scheffenegger, 2022-07-25, <draft-ietf-tcpm-accurate-ecn-20.txt>

Explicit Congestion Notification (ECN) is a mechanism where network

nodes can mark IP packets instead of dropping them to indicate
incipient congestion to the end-points. Receivers with an ECN-
capable transport protocol feed back this information to the sender.
ECN was originally specified for TCP in such a way that only one
feedback signal can be transmitted per Round-Trip Time (RTT). Recent
new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
(DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
accurate ECN feedback information whenever more than one marking is
received in one RTT. This document updates the original ECN
specification to specify a scheme to provide more than one feedback
signal per RTT in the TCP header. Given TCP header space is scarce,
it allocates a reserved header bit previously assigned to the ECN-
Nonce. It also overloads the two existing ECN flags in the TCP
header. The resulting extra space is exploited to feed back the IP-
ECN field received during the 3-way handshake as well. Supplementary
feedback information can optionally be provided in a new TCP option,
 which is never used on the TCP SYN. The document also specifies the
treatment of this updated TCP wire protocol by middleboxes.

"ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control

Packets", Marcelo Bagnulo, Bob Briscoe, 2022-07-27,
<draft-ietf-tcpm-generalized-ecn-10.txt>

This document describes an experimental modification to ECN when used

with TCP. It allows the use of ECN on the following TCP packets:
SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.

"HyStart++: Modified Slow Start for TCP", Praveen Balasubramanian, Yi

Huang, Matt Olson, 2022-08-27, <draft-ietf-tcpm-hystartplusplus-09.txt>

This document describes HyStart++, a simple modification to the slow

start phase of congestion control algorithms. Traditional slow start
can overshoot the ideal send rate in many cases, causing high packet
loss and poor performance. HyStart++ uses a delay increase heuristic
to find an exit point before possible overshoot. It also adds a
mitigation to prevent jitter from causing premature slow start exit.

"A YANG Model for Transmission Control Protocol (TCP) Configuration and
State", Michael Scharf, Mahesh Jethanandani, Vishal Murgai, 2022-08-31,
<draft-ietf-tcpm-yang-tcp-08.txt>

This document specifies a minimal YANG model for TCP on devices that
are configured and managed by network management protocols. The YANG
model defines a container for all TCP connections, and groupings of
authentication parameters that can be imported and used in TCP
implementations or by other models that need to configure TCP
parameters. The model also includes basic TCP statistics. The model
is compliant with Network Management Datastore Architecture (NMDA)
(RFC 8342).

"Proportional Rate Reduction for TCP", Matt Mathis, Nandita Dukkipati,

Yuchung Cheng, 2022-06-03, <draft-ietf-tcpm-prr-rfc6937bis-02.txt>

This document updates the experimental Proportional Rate Reduction

(PRR) algorithm, described RFC 6937, to standards track. PRR
potentially replaces the Fast Recovery to regulate the amount of data
sent by TCP or other transport protocol during loss recovery. PRR
accurately regulates the actual flight size through recovery such
that at the end of recovery it will be as close as possible to the
slow start threshold (ssthresh), as determined by the congestion
control algorithm.

"CUBIC for Fast and Long-Distance Networks", Lisong Xu, Sangtae Ha, Injong
Rhee, Vidhi Goel, Lars Eggert, 2022-08-31,
<draft-ietf-tcpm-rfc8312bis-09.txt>

CUBIC is a standard TCP congestion control algorithm that uses a

cubic function instead of a linear congestion window increase
function to improve scalability and stability over fast and long-
distance networks. CUBIC has been adopted as the default TCP
congestion control algorithm by the Linux, Windows, and Apple stacks.

This document updates the specification of CUBIC to include

algorithmic improvements based on these implementations and recent
academic work. Based on the extensive deployment experience with
 CUBIC, it also moves the specification to the Standards Track,
obsoleting RFC 8312. This also requires updating RFC 5681, to allow
for CUBIC's occasionally more aggressive sending behavior.

Traffic Engineering Architecture and Signaling (teas)

-----------------------------------------------------

"A YANG Data Model for Resource Reservation Protocol (RSVP)", Vishnu
Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin, 2022-07-11,
<draft-ietf-teas-yang-rsvp-18.txt>

This document defines a YANG data model for the configuration and
management of the RSVP protocol. The YANG data model covers the
building blocks that may be augmented by other RSVP extension data
models such as RSVP Traffic-Engineering (RSVP-TE). It is divided
into two modules that cover the basic and extended RSVP features.

"A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths
and Interfaces", Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor
Bryskin, Oscar de Dios, 2022-07-11, <draft-ietf-teas-yang-te-30.txt>

This document defines a YANG data model for the provisioning and
management of Traffic Engineering (TE) tunnels, Label Switched Paths
(LSPs), and interfaces. The model covers data that is independent of
any technology or dataplane encapsulation and is divided into two
YANG modules that cover device-specific, and device independent data.

This model covers data for configuration, operational state, remote

procedural calls, and event notifications.

"The Use Cases for Path Computation Element (PCE) as a Central Controller
(PCECC).", Zhenbin Li, Dhruv Dhody, Quintin Zhao, Zekung Ke, Boris
Khasanov, 2022-07-11, <draft-ietf-teas-pcecc-use-cases-11.txt>

The Path Computation Element (PCE) is a core component of a Software-

Defined Networking (SDN) system. It can compute optimal paths for
traffic across a network and can also update the paths to reflect
changes in the network or traffic demands. PCE was developed to
derive paths for MPLS Label Switched Paths (LSPs), which are supplied
to the head end of the LSP using the Path Computation Element
Communication Protocol (PCEP).

SDN has a broader applicability than signaled MPLS traffic-engineered

(TE) networks, and the PCE may be used to determine paths in a range
of use cases including static LSPs, segment routing (SR), Service
Function Chaining (SFC), and most forms of a routed or switched
network. It is, therefore, reasonable to consider PCEP as a control
protocol for use in these environments to allow the PCE to be fully
enabled as a central controller.

A PCE as a Central Controller (PCECC) can simplify the processing of

a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. This document describes
general considerations for PCECC deployment and examines its
applicability and benefits, as well as its challenges and
limitations, through a number of use cases. PCEP extensions required
for stateful PCE usage are covered in separate documents.

"Applicability of YANG models for Abstraction and Control of Traffic

Engineered Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli,
Bin-Yeong Yoon, Sergio Belotti, 2022-03-07,
<draft-ietf-teas-actn-yang-09.txt>

Abstraction and Control of TE Networks (ACTN) refers to the set of

virtual network operations needed to orchestrate, control and manage
large-scale multi-domain TE networks, so as to facilitate network
programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function
virtualization services.

This document explains how the different types of YANG models

defined in the Operations and Management Area and in the Routing
Area are applicable to the ACTN framework. This document also shows
how the ACTN architecture can be satisfied using classes of data
model that have already been defined, and discusses the
applicability of specific data models that are under development. It
also highlights where new data models may need to be developed.

"A YANG Data Model for requesting path computation", Italo Busi, Sergio
Belotti, Oscar de Dios, Anurag Sharma, Daniele Ceccarelli, 2022-03-22,
<draft-ietf-teas-yang-path-computation-18.txt>

There are scenarios, typically in a hierarchical Software-Defined

Networking (SDN) context, where the topology information provided by
a Traffic Engineering (TE) network provider may be insufficient for
its client to perform multi-domain path computation. In these cases
the client would need to request the TE network provider to compute
some intra-domain paths.

This document defines a YANG data model which contains Remote

Procedure Calls (RPCs) to request path computation. This model
complements the solution, defined in RFC YYYY, to configure a TE
tunnel path in "compute-only" mode.

[RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of
draft-ietf-teas-yang-te once it has been published.

Moreover, this document describes some use cases where the path
computation request, via YANG-based protocols (e.g., NETCONF or
RESTCONF), can be needed.

"YANG Data Model for SR and SR TE Topologies on MPLS Data Plane", Xufeng
Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Himanshu Shah, Stephane
Litkowski, 2022-07-04, <draft-ietf-teas-yang-sr-te-topo-15.txt>

This document defines a YANG data model for Segment Routing (SR)
topology and Segment Routing (SR) traffic engineering (TE) topology,
using MPLS data plane.

"YANG Data Model for Layer 3 TE Topologies", Xufeng Liu, Igor Bryskin,
Vishnu Beeram, Tarek Saad, Himanshu Shah, Oscar de Dios, 2022-07-10,
<draft-ietf-teas-yang-l3-te-topo-13.txt>

This document defines a YANG data model for layer 3 traffic

engineering topologies.

"A YANG Data Model for Virtual Network (VN) Operations", Young Lee, Dhruv
Dhody, Daniele Ceccarelli, Igor Bryskin, Bin-Yeong Yoon, 2022-07-11,
<draft-ietf-teas-actn-vn-yang-15.txt>

This document provides a YANG data model generally applicable to any

mode of Virtual Network (VN) operations.

"A Framework for Enhanced Virtual Private Network (VPN+) Services", Jie
Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka, Young Lee, 2022-03-06,
<draft-ietf-teas-enhanced-vpn-10.txt>

This document describes the framework for Enhanced Virtual Private

Network (VPN+) services. The purpose of enhanced VPNs is to support
the needs of new applications, particularly applications that are
associated with 5G services, by utilizing an approach that is based
on the VPN and Traffic Engineering (TE) technologies and adds
characteristics that specific services require over those provided by
traditional VPNs.

Typically, VPN+ will be used to underpin network slicing, but could

also be of use in its own right providing enhanced connectivity
services between customer sites.

It is envisaged that enhanced VPNs will be delivered using a

combination of existing, modified, and new networking technologies.
This document provides an overview of relevant technologies and
identifies some areas for potential new work.

"Traffic Engineering (TE) and Service Mapping YANG Data Model", Young Lee,
Dhruv Dhody, Giuseppe Fioccola, Qin WU, Daniele Ceccarelli, Jeff Tantsura,
2022-07-11, <draft-ietf-teas-te-service-mapping-yang-11.txt>

This document provides a YANG data model to map customer service

models (e.g., L3VPN Service Delivery model) to Traffic Engineering
(TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
These models are referred to as TE Service Mapping Model and are
applicable generically to the operator's need for seamless control
and management of their VPN services with underlying TE support.

The models are principally used for monitoring and diagnostics of the
management systems to show how the service requests are mapped onto
underlying network resource and TE models.

"Interworking of GMPLS Control and Centralized Controller System", Haomian

Zheng, Xianlong Luo, Yi Lin, Yang Zhao, Yunbin Xu, Sergio Belotti, Dieter
Beller, 2022-03-07, <draft-ietf-teas-gmpls-controller-inter-work-08.txt>

Generalized Multi-Protocol Label Switching (GMPLS) control allows

each network element (NE) to perform local resource discovery,
routing and signaling in a distributed manner.

On the other hand, with the development of software-defined

transport networking technology, a set of NEs can be controlled via
centralized controller hierarchies to address the issue from multi-
domain, multi-vendor and multi-technology. An example of such
centralized architecture is ACTN controller hierarchy described in
RFC 8453.

Instead of competing with each other, both the distributed and the
centralized control plane have their own advantages, and should be
complementary in the system. This document describes how the GMPLS
 distributed control plane can interwork with a centralized
controller system in a transport network.

"YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry

and Scaling Intent Autonomics", Young Lee, Dhruv Dhody, Ricard Vilalta,
Daniel King, Daniele Ceccarelli, 2022-07-11,
<draft-ietf-teas-actn-pm-telemetry-autonomics-09.txt>

This document provides YANG data models that describe performance

monitoring parameters and scaling intent mechanisms for TE-tunnels
and Virtual Networks (VNs). There performance monitoring parameters
are exposed as the key telemetry data for tunnels and VN.

The models presented in this document allow customers to subscribe to

and monitor the key performance data of the TE-tunnel or the VN. The
models also provide customers with the ability to program autonomic
scaling intent mechanisms on the level of TE-tunnel as well as VN.

"Overview and Principles of Internet Traffic Engineering", Adrian Farrel,

2022-07-11, <draft-ietf-teas-rfc3272bis-20.txt>

This document describes the principles of traffic engineering (TE) in

the Internet. The document is intended to promote better
understanding of the issues surrounding traffic engineering in IP
networks and the networks that support IP networking, and to provide
a common basis for the development of traffic engineering
capabilities for the Internet. The principles, architectures, and
methodologies for performance evaluation and performance optimization
of operational networks are also discussed.

This work was first published as RFC 3272 in May 2002. This document
obsoletes RFC 3272 by making a complete update to bring the text in
line with best current practices for Internet traffic engineering and
to include references to the latest relevant work in the IETF.

"Applicability of Abstraction and Control of Traffic Engineered Networks

(ACTN) to Packet Optical Integration (POI)", Fabio Peruzzini, Jean-Francois
Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli, 2022-07-10,
<draft-ietf-teas-actn-poi-applicability-07.txt>

This document considers the applicability of Abstraction and Control

of TE Networks (ACTN) architecture to Packet Optical Integration
(POI)in the context of IP/MPLS and optical internetworking. It
identifies the YANG data models being defined by the IETF to support
this deployment architecture and specific scenarios relevant for
Service Providers.

Existing IETF protocols and data models are identified for each
multi-layer (packet over optical) scenario with a specific focus on
the MPI (Multi-Domain Service Coordinator to Provisioning Network
Controllers Interface)in the ACTN architecture.

"Framework for IETF Network Slices", Adrian Farrel, John Drake, Reza Rokui,
Shunsuke Homma, Kiran Makhijani, Luis Contreras, Jeff Tantsura, 2022-08-03,
<draft-ietf-teas-ietf-network-slices-14.txt>

This document describes network slicing in the context of networks

built from IETF technologies. It defines the term "IETF Network
Slice" and establishes the general principles of network slicing in
 the IETF context.

The document discusses the general framework for requesting and

operating IETF Network Slices, the characteristics of an IETF Network
Slice, the necessary system components and interfaces, and how
abstract requests can be mapped to more specific technologies. The
document also discusses related considerations with monitoring and
security.

This document also provides definitions of related terms to enable

consistent usage in other IETF documents that describe or use aspects
of IETF Network Slices.

"Applicability of Abstraction and Control of Traffic Engineered Networks

(ACTN) to Network Slicing", Daniel King, John Drake, Haomian Zheng, Adrian
Farrel, 2022-03-07, <draft-ietf-teas-applicability-actn-slicing-01.txt>

Network abstraction is a technique that can be applied to a network

domain to obtain a view of potential connectivity across the network
by utilizing a set of policies to select network resources.

Network slicing is an approach to network operations that builds on

the concept of network abstraction to provide programmability,
flexibility, and modularity. It may use techniques such as Software
Defined Networking (SDN) and Network Function Virtualization (NFV) to
create multiple logical or virtual networks, each tailored for a set
of services that share the same set of requirements.

Abstraction and Control of Traffic Engineered Networks (ACTN) is

described in RFC 8453. It defines an SDN-based architecture that
relies on the concept of network and service abstraction to detach
network and service control from the underlying data plane.

This document outlines the applicability of ACTN to network slicing

in a Traffic Engineering (TE) network that utilizes IETF technology.
It also identifies the features of network slicing not currently
within the scope of ACTN, and indicates where ACTN might be extended.

"IETF Network Slice Service YANG Model", Bo Wu, Dhruv Dhody, Reza Rokui,
Tarek Saad, Liuyan Han, 2022-07-11,
<draft-ietf-teas-ietf-network-slice-nbi-yang-02.txt>

This document defines a YANG model for the IETF Network Slice
service. The model can be used by an IETF Network Slice customer to
manage IETF Network Slices.

"Realizing Network Slices in IP/MPLS Networks", Tarek Saad, Vishnu Beeram,

Jie Dong, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen,
Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil, 2022-06-16,
<draft-ietf-teas-ns-ip-mpls-00.txt>

Realizing network slices may require the Service Provider to have the
ability to partition a physical network into multiple logical
networks of varying sizes, structures, and functions so that each
slice can be dedicated to specific services or customers. Multiple
network slices can be realized on the same network while ensuring
slice elasticity in terms of network resource allocation. This
document describes a scalable solution to realize network slicing in
IP/MPLS networks by supporting multiple services on top of a single
 physical network by relying on compliant domains and nodes to provide
forwarding treatment (scheduling, drop policy, resource usage) on to
packets that carry identifiers that indicate the slicing service that
is to be applied to the packets.

"Updated Common YANG Data Types for Traffic Engineering", Italo Busi, Aihua
Guo, Xufeng Liu, Tarek Saad, Rakesh Gandhi, Vishnu Beeram, Igor Bryskin,
2022-07-11, <draft-ietf-teas-rfc8776-update-00.txt>

This document defines few additional common data types and groupings
in YANG data modeling language to be imported by modules that model
Traffic Engineering (TE) configuration and state capabilities.

This document updates RFC 8776 with a new revision of the module
ietf-te-types.

"Scalability Considerations for Network Resource Partition", Jie Dong,

Zhenbin Li, Liyan Gong, Guangming Yang, Jim Guichard, Gyan Mishra, Fengwei
Qin, Tarek Saad, Vishnu Beeram, 2022-07-11,
<draft-ietf-teas-nrp-scalability-00.txt>

The IETF Network Slice service aims to meet the connectivity demands
of a network slice customer with specific Service Level Objectives
(SLOs) and Service Level Expectations (SLEs) over a common underlay
network. A Network Resource Partition (NRP) is a set of network
resources that are allocated from the underlay network to carry a
specific set of network traffic and meet the required SLOs and SLEs.
One or multiple IETF Network Slice services can be mapped to one NRP.

As the demand for IETF Network Slice services increases, scalability

would become an important factor for the large scale deployment of
IETF Network Slices. Although the scalability of IETF Network Slices
can be improved by mapping a group of IETF Network Slices to one NRP,
there are concerns about the scalability of NRPs. This document
describes the scalability considerations about NRPs in the network
control plane and data plane, and some optimization mechanisms are
proposed.

"IETF Network Slice Use Cases and Attributes for Northbound Interface of
IETF Network Slice Controllers", Luis Contreras, Shunsuke Homma, Jose
Ordonez-Lucena, Jeff Tantsura, Hidetaka Nishihara, 2022-07-24,
<draft-ietf-teas-ietf-network-slice-use-cases-00.txt>

This document analyses the needs of potential customers of network

slices realized with IETF techniques in several use cases, identifies
the functionalities for the North Bound Interface (NBI) of an IETF
Network Slice Controller to satisfy such requests.

Trusted Execution Environment Provisioning (teep)

-------------------------------------------------

"Trusted Execution Environment Provisioning (TEEP) Architecture", Mingliang

Pei, Hannes Tschofenig, Dave Thaler, David Wheeler, 2022-07-11,
<draft-ietf-teep-architecture-18.txt>

A Trusted Execution Environment (TEE) is an environment that enforces

that any code within that environment cannot be tampered with, and
that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document
 motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE.

"HTTP Transport for Trusted Execution Environment Provisioning: Agent

Initiated Communication", Dave Thaler, 2022-02-28,
<draft-ietf-teep-otrp-over-http-13.txt>

The Trusted Execution Environment Provisioning (TEEP) Protocol is

used to manage code and configuration data in a Trusted Execution
Environment (TEE). This document specifies the HTTP transport for
TEEP communication where a Trusted Application Manager (TAM) service
is used to manage code and data in TEEs on devices that can initiate
communication to the TAM. An implementation of this document can (if
desired) run outside of any TEE, but interacts with a TEEP
implementation that runs inside a TEE.

"Trusted Execution Environment Provisioning (TEEP) Protocol", Hannes

Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto,
2022-07-28, <draft-ietf-teep-protocol-10.txt>

This document specifies a protocol that installs, updates, and

deletes Trusted Components in a device with a Trusted Execution
Environment (TEE). This specification defines an interoperable
protocol for managing the lifecycle of Trusted Components.

"TEEP Usecase for Confidential Computing in Network", Penglin Yang,

chenmeiling, Li Su, Ting Pang, 2022-08-28,
<draft-ietf-teep-usecase-for-cc-in-network-00.txt>

Confidential computing is the protection of data in use by performing

computation in a hardware-based Trusted Execution Environment.
Confidential computing could provide integrity and confidentiality
for users who want to run application and process data in that
environment. When confidential computing is used in network like MEC
and CAN which provide computing resource to network users, TEEP
protocol could be used to provision network user's data and
application in TEE environment in confidential computing resource.
This document focuses on using TEEP to provision network user's data
and application in confidential computing in such network. This
document is a use case and extension of TEEP and could provide
guidance for MEC, CAN and other scenarios to use confidential
computing.

Timing over IP Connection and Transfer of Clock (tictoc)

--------------------------------------------------------

"Enterprise Profile for the Precision Time Protocol With Mixed Multicast
and Unicast Messages", Doug Arnold, Heiko Gerstung, 2022-04-06,
<draft-ietf-tictoc-ptp-enterprise-profile-22.txt>

This document describes a profile for the use of the Precision Time
Protocol in an IPV4 or IPv6 Enterprise information system
environment. The profile uses the End to End Delay Measurement
Mechanism, allows both multicast and unicast Delay Request and Delay
Response Messages.

Transport Layer Security (tls)

------------------------------
"Delegated Credentials for (D)TLS", Richard Barnes, Subodh Iyengar, Nick
Sullivan, Eric Rescorla, 2022-06-30, <draft-ietf-tls-subcerts-15.txt>

The organizational separation between operators of TLS and DTLS

endpoints and the certification authority can create limitations.
For example, the lifetime of certificates, how they may be used, and
the algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism to to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in TLS and DTLS without breaking
compatibility with peers that do not support this specification.

"A Flags Extension for TLS 1.3", Yoav Nir, 2022-07-26,

<draft-ietf-tls-tlsflags-10.txt>

A number of extensions are proposed in the TLS working group that

carry no interesting information except the 1-bit indication that a
certain optional feature is supported. Such extensions take 4 octets
each. This document defines a flags extension that can provide such
indications at an average marginal cost of 1 bit each. More
precisely, it provides as many flag extensions as needed at 4 + the
order of the last set bit divided by 8.

"Hybrid key exchange in TLS 1.3", Douglas Stebila, Scott Fluhrer, Shay
Gueron, 2022-08-28, <draft-ietf-tls-hybrid-design-05.txt>

Hybrid key exchange refers to using multiple key exchange algorithms

simultaneously and combining the result with the goal of providing
security even if all but one of the component algorithms is broken.
It is motivated by transition to post-quantum cryptography. This
document provides a construction for hybrid key exchange in the
Transport Layer Security (TLS) protocol version 1.3.

Discussion of this work is encouraged to happen on the TLS IETF

mailing list tls@ietf.org or on the GitHub repository which contains
the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.

"Compact TLS 1.3", Eric Rescorla, Richard Barnes, Hannes Tschofenig,

Benjamin Schwartz, 2022-07-09, <draft-ietf-tls-ctls-06.txt>

This document specifies a "compact" version of TLS and DTLS. It is

logically isomorphic to ordinary TLS, but saves space by trimming
obsolete material, tighter encoding, a template-based specialization
technique, and alternative cryptographic techniques. cTLS is not
directly interoperable with TLS or DTLS, but it should eventually be
possible for a single server port to offer cTLS alongside TLS or
DTLS.

"The Transport Layer Security (TLS) Protocol Version 1.3", Eric Rescorla,
2022-03-07, <draft-ietf-tls-rfc8446bis-04.txt>

This document specifies version 1.3 of the Transport Layer Security

(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.

This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
RFCs 5077, 5246, 6961, and 8446. This document also specifies new
requirements for TLS 1.2 implementations.
"Return Routability Check for DTLS 1.2 and DTLS 1.3", Hannes Tschofenig,
Achim Kraus, Thomas Fossati, 2022-07-06, <draft-ietf-tls-dtls-rrc-06.txt>

This document specifies a return routability check for use in context

of the Connection ID (CID) construct for the Datagram Transport Layer
Security (DTLS) protocol versions 1.2 and 1.3.

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Transport Layer

Security Working Group mailing list (tls@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/tls/.

Source for this draft and an issue tracker can be found at

https://github.com/tlswg/dtls-rrc.

"Secure Negotiation of Incompatible Protocols in TLS", Martin Thomson,

2022-06-30, <draft-ietf-tls-snip-02.txt>

An extension is defined for TLS that allows a client and server to

detect an attempt to force the use of less-preferred application
protocol even where protocol options are incompatible. This
supplements application-layer protocol negotiation (ALPN), which
allows choices between compatible protocols to be authenticated.

"IANA Registry Updates for TLS and DTLS", Joseph Salowey, Sean Turner,
2022-07-07, <draft-ietf-tls-rfc8447bis-01.txt>

This document describes a number of changes to TLS and DTLS IANA

registries that range from adding notes to the registry all the way
to changing the registration policy. These changes were mostly
motivated by WG review of the TLS- and DTLS-related registries
undertaken as part of the TLS 1.3 development process.

This document obsoletes RFC 8447 and updates the following RFCs:
3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

"Deprecating Obsolete Key Exchange Methods in TLS", Carrick Bartle, Nimrod

Aviram, 2022-06-15, <draft-ietf-tls-deprecate-obsolete-kex-00.txt>

This document makes several prescriptions regarding the following key

exchange methods in TLS, most of which have been superseded by better
options:

1. This document deprecates the use of RSA key exchange in TLS.

2. It limits the use of Diffie Hellman key exchange over a finite field
to avoid
known vulnerabilities and improper security properties.

3. It discourages the use of static elliptic curve Diffie Hellman cipher

suites.

"A well-known URI for publishing ECHConfigList values.", Stephen Farrell,

2022-07-24, <draft-ietf-tls-wkech-00.txt>
 We propose use of a well-known URI at which web servers can publish
ECHConfigList values as a way to help get those published in the DNS.

Transparent Interconnection of Lots of Links (trill)

----------------------------------------------------

"TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit

Congestion Notification) Support", Donald Eastlake, Bob Briscoe,
2018-02-25, <draft-ietf-trill-ecn-support-07.txt>

Explicit congestion notification (ECN) allows a forwarding element to

notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This can improve network
efficiency through better congestion control without packet drops.
This document extends ECN to TRILL (TRansparent Interconnection of
Lots of Links) switches, including integration with IP ECN, and
provides for ECN marking in the TRILL Header Extension Flags Word
(see RFC 7179).

Transport Area Working Group (tsvwg)

------------------------------------

"Guidelines for Adding Congestion Notification to Protocols that

Encapsulate IP", Bob Briscoe, John Kaippallimalil, 2022-07-11,
<draft-ietf-tsvwg-ecn-encap-guidelines-17.txt>

The purpose of this document is to guide the design of congestion

notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure
interworking among IP layer and lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
This document updates the advice to subnetwork designers about ECN in
RFC 3819.

"Propagating Explicit Congestion Notification Across IP Tunnel Headers

Separated by a Shim", Bob Briscoe, 2022-07-11,
<draft-ietf-tsvwg-rfc6040update-shim-15.txt>

RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the

rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification updates RFC 6040 to clarify that its
scope includes tunnels where two IP headers are separated by at least
one shim header that is not sufficient on its own for wide area
packet forwarding. It surveys widely deployed IP tunnelling
protocols that use such shim header(s) and updates the specifications
of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE,
Teredo and AMT). This specification also updates RFC 6040 with
configuration requirements needed to make any legacy tunnel ingress
safe.

"Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:

Architecture", Bob Briscoe, Koen De Schepper, Marcelo Bagnulo, Greg White,
2022-08-29, <draft-ietf-tsvwg-l4s-arch-20.txt>

This document describes the L4S architecture, which enables Internet

 applications to achieve Low queuing Latency, Low Loss, and Scalable
throughput (L4S). L4S is based on the insight that the root cause of
queuing delay is in the capacity-seeking congestion controllers of
senders, not in the queue itself. With the L4S architecture all
Internet applications could (but do not have to) transition away from
congestion control algorithms that cause substantial queuing delay,
to a new class of congestion controls that can seek capacity with
very little queuing. These are aided by a modified form of explicit
congestion notification (ECN) from the network. With this new
architecture, applications can have both low latency and high
throughput.

The architecture primarily concerns incremental deployment. It

defines mechanisms that allow the new class of L4S congestion
controls to coexist with 'Classic' congestion controls in a shared
network. The aim is for L4S latency and throughput to be usually
much better (and rarely worse), while typically not impacting Classic
performance.

"Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay
(L4S)", Koen De Schepper, Bob Briscoe, 2022-08-29,
<draft-ietf-tsvwg-ecn-l4s-id-29.txt>

This specification defines the protocol to be used for a new network

service called low latency, low loss and scalable throughput (L4S).
L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
layer that is similar to the original (or 'Classic') ECN approach,
except as specified within. L4S uses 'scalable' congestion control,
which induces much more frequent control signals from the network and
it responds to them with much more fine-grained adjustments, so that
very low (typically sub-millisecond on average) and consistently low
queuing delay becomes possible for L4S traffic without compromising
link utilization. Thus even capacity-seeking (TCP-like) traffic can
have high bandwidth and very low delay at the same time, even during
periods of high traffic load.

The L4S identifier defined in this document distinguishes L4S from

'Classic' (e.g. TCP-Reno-friendly) traffic. Then, network
bottlenecks can be incrementally modified to distinguish and isolate
existing traffic that still follows the Classic behaviour, to prevent
it degrading the low queuing delay and low loss of L4S traffic. This
experimental track specification defines the rules that L4S
transports and network elements need to follow, with the intention
that L4S flows neither harm each other's performance nor that of
Classic traffic. It also suggests open questions to be investigated
during experimentation. Examples of new active queue management
(AQM) marking algorithms and examples of new transports (whether TCP-
like or real-time) are specified separately.

"DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput
(L4S)", Koen De Schepper, Bob Briscoe, Greg White, 2022-08-29,
<draft-ietf-tsvwg-aqm-dualq-coupled-25.txt>

This specification defines a framework for coupling the Active Queue

Management (AQM) algorithms in two queues intended for flows with
different responses to congestion. This provides a way for the
Internet to transition from the scaling problems of standard TCP
Reno-friendly ('Classic') congestion controls to the family of
'Scalable' congestion controls. These are designed for consistently
 very Low queuing Latency, very Low congestion Loss and Scaling of
per-flow throughput (L4S) by using Explicit Congestion Notification
(ECN) in a modified way. Until the Coupled DualQ, these scalable L4S
congestion controls could only be deployed where a clean-slate
environment could be arranged, such as in private data centres.

The specification first explains how a Coupled DualQ works. It then

gives the normative requirements that are necessary for it to work
well. All this is independent of which two AQMs are used, but
pseudocode examples of specific AQMs are given in appendices.

"Transport Options for UDP", Joseph Touch, 2022-03-26,

<draft-ietf-tsvwg-udp-options-18.txt>

Transport protocols are extended through the use of transport header

options. This document extends UDP by indicating the location,
syntax, and semantics for UDP transport layer options.

"A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated

Services", Greg White, Thomas Fossati, 2022-03-04,
<draft-ietf-tsvwg-nqb-10.txt>

This document specifies properties and characteristics of a Non-

Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB
PHB is to provide a separate queue that enables smooth, low-data-
rate, application-limited traffic flows, which would ordinarily share
a queue with bursty and capacity-seeking traffic, to avoid the
latency, latency variation and loss caused by such traffic. This PHB
is implemented without prioritization and without rate policing,
making it suitable for environments where the use of either these
features may be restricted. The NQB PHB has been developed primarily
for use by access network segments, where queuing delays and queuing
loss caused by Queue-Building protocols are manifested, but its use
is not limited to such segments. In particular, applications to
cable broadband links, Wi-Fi links, and mobile network radio and core
segments are discussed. This document recommends a specific
Differentiated Services Code Point (DSCP) to identify Non-Queue-
Building flows.

"Operational Guidance for Deployment of L4S in the Internet", Greg White,

2022-04-28, <draft-ietf-tsvwg-l4sops-03.txt>

This document is intended to provide guidance in order to ensure

successful deployment of Low Latency Low Loss Scalable throughput
(L4S) in the Internet. Other L4S documents provide guidance for
running an L4S experiment, but this document is focused solely on
potential interactions between L4S flows and flows using the original
('Classic') ECN over a Classic ECN bottleneck link. The document
discusses the potential outcomes of these interactions, describes
mechanisms to detect the presence of Classic ECN bottlenecks, and
identifies opportunities to prevent and/or detect and resolve
fairness problems in such networks. This guidance is aimed at
operators of end-systems, operators of networks, and researchers.

"Datagram Transport Layer Security (DTLS) over Stream Control Transmission

Protocol (SCTP)", Magnus Westerlund, John Mattsson, Claudio Porfiri,
2022-06-23, <draft-ietf-tsvwg-dtls-over-sctp-bis-04.txt>

This document describes the usage of the Datagram Transport Layer

 Security (DTLS) protocol to protect user messages sent over the
Stream Control Transmission Protocol (SCTP). It is an improved
alternative to the existing rfc6083.

DTLS over SCTP provides mutual authentication, confidentiality,

integrity protection, and replay protection for applications that use
SCTP as their transport protocol and allows client/server
applications to communicate in a way that is designed to give
communications privacy and to prevent eavesdropping and detect
tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport
features provided by SCTP and its extensions. This document is an
improved alternative to RFC 6083 and removes the 16 kB limitation on
protected user message size by defining a secure user message
fragmentation so that multiple DTLS records can be used to protect a
single user message. It further updates the DTLS versions to use, as
well as the HMAC algorithms for SCTP-AUTH, and simplifies secure
implementation by some stricter requirements on the establishment
procedures.

"Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)",

Ana Custura, Gorry Fairhurst, Raffaello Secchi, 2022-08-10,
<draft-ietf-tsvwg-dscp-considerations-05.txt>

This document discusses considerations for assigning a new

recommended DiffServ Code Point (DSCP) for a new standard Per Hop
Behaviour (PHB). It considers the common observed remarking
behaviours that the DiffServ field might be subjected to along an
Internet path. It also notes some implications of using a specific
DSCP.

"DCCP Extensions for Multipath Operation with Multiple Addresses", Markus

Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson,
2022-07-08, <draft-ietf-tsvwg-multipath-dccp-05.txt>

DCCP communication as defined in [RFC4340] is restricted to a single

path per connection, yet multiple paths often exist between peers.
The simultaneous use of these multiple paths for a DCCP session could
improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to
network failures. Use cases for a Multipath DCCP (MP-DCCP) are
mobile devices (handsets, vehicles) and residential home gateways
simultaneously connected to distinct paths as, e.g., a cellular link
and a WiFi link or to a mobile radio station and a fixed access
network. Compared to existing multipath protocols such as MPTCP, MP-
DCCP provides specific support for non-TCP user traffic as UDP or
plain IP. More details on potential use cases are provided in
[website], [slide], and [paper]. All these use cases profit from an
Open Source Linux reference implementation provided under [website].

This document presents a set of extensions to traditional DCCP to

support multipath operation. Multipath DCCP provides the ability to
simultaneously use multiple paths between peers. The protocol offers
the same type of service to applications as DCCP and it provides the
components necessary to establish and use multiple DCCP subflows
across potentially disjoint paths.

Using TLS in Applications (uta)

-------------------------------

"TLS/DTLS 1.3 Profiles for the Internet of Things", Hannes Tschofenig,

Thomas Fossati, 2022-07-06, <draft-ietf-uta-tls13-iot-profile-05.txt>

This document is a companion to RFC 7925 and defines TLS/DTLS 1.3

profiles for Internet of Things devices. It also updates RFC 7925
with regards to the X.509 certificate profile.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at

https://github.com/thomas-fossati/draft-tls13-iot.

"Recommendations for Secure Use of Transport Layer Security (TLS) and

Datagram Transport Layer Security (DTLS)", Yaron Sheffer, Peter
Saint-Andre, Thomas Fossati, 2022-08-16, <draft-ietf-uta-rfc7525bis-11.txt>

Transport Layer Security (TLS) and Datagram Transport Layer Security

(DTLS) are used to protect data exchanged over a wide range of
application protocols, and can also form the basis for secure
transport protocols. Over the years, the industry has witnessed
several serious attacks on TLS and DTLS, including attacks on the
most commonly used cipher suites and their modes of operation. This
document provides the latest recommendations for ensuring the
security of deployed services that use TLS and DTLS. These
recommendations are applicable to the majority of use cases.

An earlier version of this document was published as RFC 7525 when

the industry was in the midst of its transition to TLS 1.2. Years
later this transition is largely complete and TLS 1.3 is widely
available. This document updates the guidance given the new
environment and obsoletes RFC 7525. In addition, the document
updates RFC 5288 and RFC 6066 in view of recent attacks.

"Service Identity in TLS", Peter Saint-Andre, Rich Salz, 2022-07-05,

<draft-ietf-uta-rfc6125bis-07.txt>

Many application technologies enable secure communication between two

entities by means of Transport Layer Security (TLS) with Internet
Public Key Infrastructure Using X.509 (PKIX) certificates. This
document specifies procedures for representing and verifying the
identity of application services in such interactions.

This document obsoletes RFC 6125.

"Updates to the Cipher Suites in Secure Syslog", Chris Lonvick, Sean

Turner, Joseph Salowey, 2022-07-24,
<draft-ietf-uta-ciphersuites-in-sec-syslog-01.txt>

This document updates the cipher suites in RFC 5425, Transport Layer
Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram
Transport Layer Security (DTLS) Transport Mapping for Syslog. It
also updates the transport protocol in RFC 6012.

IPv6 Operations (v6ops)

-----------------------
 "IPv6 Deployment Status", Giuseppe Fioccola, Paolo Volpato, Nalini Elkins,
Jordi Martinez, Gyan Mishra, Chongfeng Xie, 2022-07-29,
<draft-ietf-v6ops-ipv6-deployment-07.txt>

This document provides an overview of IPv6 deployment status in early

2022. Specifically, it looks at the degree of adoption of IPv6 in
the industry, analyzes the remaining challenges and proposes further
investigations in areas where the industry has not yet taken a clear
and unified approach in the transition to IPv6. It obsoletes RFC
6036.

"Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse,
Jordi Martinez, Lee Howard, Richard Patterson, Ian Farrer, 2022-05-23,
<draft-ietf-v6ops-transition-comparison-04.txt>

Several IPv6 transition technologies have been developed to provide

customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines the five most prominent IPv4aaS technologies

considering a number of different aspects to provide network
operators with an easy-to-use reference to assist in selecting the
technology that best suits their needs.

"Operational Issues with Processing of the Hop-by-Hop Options Header",

Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra,
2022-04-18, <draft-ietf-v6ops-hbh-01.txt>

This document describes the processing of the Hop-by-Hop Options

Header (HBH) in today's routers in the aspects of standards
specification, common implementations, and default operations. This
document outlines the reasons why the Hop-by-Hop Options Header is
rarely utilized in current networks. In addition, this document
describes how the HBH could be used as a powerful mechanism allowing
deployment and operations of new services requiring a more optimized
way to leverage network resources of an infrastructure. The Hop-by-
Hop Options Header is taken into consideration by several network
operators as a valuable container for carrying the information
facilitating the introduction of new services. The purpose of this
draft is to document the reasons why the HBH is rarely used within
networks and to define a proper list of requirements aiming to allow
a better leverage of the HBH capability.

"Unintended Operational Issues With ULA", Nick Buraglio, Chris Cummings,

Russ White, 2022-08-01, <draft-ietf-v6ops-ula-00.txt>

The behavior of ULA addressing as defined by [RFC6724] is preferred

below legacy IPv4 addressing, thus rendering ULA IPv6 deployment
functionally unusable in IPv4 / IPv6 dual-stacked environments. This
behavior is counter to the operational behavior of GUA IPv6
addressing on nearly all modern operating systems that leverage a
preference model based on [RFC6724] .

WebTransport (webtrans)
-----------------------
 "The WebTransport Protocol Framework", Victor Vasiliev, 2022-07-11,
<draft-ietf-webtrans-overview-04.txt>

The WebTransport Protocol Framework enables clients constrained by

the Web security model to communicate with a remote server using a
secure multiplexed transport. It consists of a set of individual
protocols that are safe to expose to untrusted applications, combined
with a model that allows them to be used interchangeably.

This document defines the overall requirements on the protocols used

in WebTransport, as well as the common features of the protocols,
support for some of which may be optional.

"WebTransport over HTTP/3", Alan Frindell, Eric Kinnear, Victor Vasiliev,

2022-07-06, <draft-ietf-webtrans-http3-03.txt>

WebTransport [OVERVIEW] is a protocol framework that enables clients

constrained by the Web security model to communicate with a remote
server using a secure multiplexed transport. This document describes
a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides
support for unidirectional streams, bidirectional streams and
datagrams, all multiplexed within the same HTTP/3 connection.

"WebTransport using HTTP/2", Alan Frindell, Eric Kinnear, Tommy Pauly,

Martin Thomson, Victor Vasiliev, Guowu Xie, 2022-03-07,
<draft-ietf-webtrans-http2-03.txt>

WebTransport defines a set of low-level communications features

designed for client-server interactions that are initiated by Web
clients. This document describes a protocol that can provide many of
the capabilities of WebTransport over HTTP/2. This protocol enables
the use of WebTransport when a UDP-based protocol is not available.

WebRTC Ingest Signaling over HTTPS (wish)

-----------------------------------------

"WebRTC-HTTP ingestion protocol (WHIP)", Sergio Murillo, Alex Gouaillard,

2022-07-25, <draft-ietf-wish-whip-04.txt>

This document describes a simple HTTP-based protocol that will allow

WebRTC-based ingestion of content into streaming services and/or
CDNs.