IETF Daily Digest

Defines the special-use top-level domain "internal" and reserves it for private, site-local applications. The intent is to give operators a dedicated name space for internal-only resources that will never be delegated in the global DNS, avoiding the name collisions and leakage that arise when organizations invent their own private TLDs. The document records the registration and the handling expected of DNS software and resolvers for names under ".internal".

This WG draft could not be read from its fast source on this run, so the description below is inferred from its name and group and is approximate. By its name it appears to extend a YANG data model for IGMP and MLD snooping to cover Layer 2 VPN (L2VPN) scenarios, within the PIM working group. It would most likely add YANG configuration and operational-state objects for managing multicast snooping behavior in L2VPN bridging/broadcast-domain contexts. The official Abstract will be grounded on the next run.

Presents a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The first tier covers discovery inside a single administrative domain using multicast DNS/DNS-SD or infrastructure-assisted methods. The second tier covers cross-domain discovery, with DNS as the baseline: gateways enforce export rules, publish approved information in zones each organization runs itself, and fetch, validate, and cache remote information on demand. The framework also outlines non-DNS options and mixed deployments adding proactive distribution, targeted sharing, and directory lookups.

Specifies a framework for gateway capability directories in Internet-of-Agents deployments that keep persistent capability views and share selected information across gateways. It sets requirements for Agent Capability Specifications, derived Capability Digests, lifecycle state, provenance, validation, and synchronization — including authority-scoped revisions, remaining-lifetime preservation, withdrawal handling, partial views, and recovery. It separates source descriptions from gateway-accepted objects, and directory visibility from semantic compatibility, authorization, and execution admission. Discovery query protocols, ranking, storage, distributed lookup, wire formats, and session protocols are explicitly out of scope.

Specifies an ontology-based semantic profile for expressing capabilities, intents, tasks, and domain context among interacting agents. It defines a core vocabulary, a JSON-LD serialization profile, and rules for judging semantic compatibility, and it separates descriptive metadata and candidate mappings from the semantic values actually used in decisions. The profile does not define an authorization, transport, session, or directory-synchronization protocol, and its deterministic processing explicitly does not extend to arbitrary natural-language content.

Describes a centralized control-plane design for Computing-Aware Traffic Steering (CATS). A logically centralized CATS Path Selector (C-PS) works with ingress and egress CATS-Forwarders: the C-PS receives a service request from an ingress forwarder, selects a suitable service instance using computing and network information, then asks a path-computation function for a path to that already-resolved destination. The C-PS returns a steering binding to the ingress forwarder, which rewrites the destination and encapsulates the first packet; the egress forwarder decapsulates and delivers it. Subsequent packets follow the installed binding, and return traffic uses a matching reverse binding.

Specifies DKIM2, a mechanism letting a person, role, or organization that controls a signing domain demonstrate that it handled an email. A signer publishes a hash of the message's current contents and signs that hash together with transmission details; verifiers fetch the public key from the signing domain's DNS to check it. As a message passes through intermediaries that alter it, each records its changes and adds new hashes and signatures, forming a chain recipients can validate to see what each system changed and judge it accordingly. The protocol also helps recipients detect unexpected replays and ensures delivery-status notifications reach only entities involved in the message's transmission.

A guide for multicast network operators across various replication technologies, weighing the options and trade-offs for redundant ingress-router failover. It recalls that Section 5 of RFC 9026 defines the hot root standby solution for MVPN networks and extends that discussion to other multicast deployments. The document compares cold, warm, and hot standby modes by their advantages, limitations, and deployment considerations so operators can choose an approach suited to their replication technology and resilience goals.

Defines a BIER proxy function that lets a single BIER sub-domain span multiple underlay routing regions (Autonomous Systems or IGP areas). It introduces a new BIER proxy range sub-TLV used to redistribute BIER BFR-id information across those routing regions, so bit-indexed explicit replication can operate coherently even when the forwarding topology is partitioned into separate routing domains.

Updates DMARC (RFC 9989) to support DKIM2. Because DKIM2 verification holds when messages pass through multiple relay forwarders that modify them, this draft extends DMARC to those cases. It separates enforcement policy from constraint-validation policy — DMARC today ties enforcement to From-header alignment failures, and this change generalizes that — and it lets MTAs declare DKIM2 support in their DMARC DNS policy record, helping protect DKIM2 against downgrade attacks.