Discovering Provisioning Domain Names and Data
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Erik Kline <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Protocol Action: 'Discovering Provisioning Domain Names and Data' to Proposed Standard (draft-ietf-intarea-provisioning-domains-11.txt) The IESG has approved the following document: - 'Discovering Provisioning Domain Names and Data' (draft-ietf-intarea-provisioning-domains-11.txt) as Proposed Standard This document is the product of the Internet Area Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/
Technical Summary A provisioning domain (PVD) is defined as the consistent set of network configuration information allowing a node to make use of a network (RFC 7556 Section 2). This document defines a mechanism for explicitly identifying PVDs through a Router Advertisement (RA) option. This RA option announces a PVD identifier, which hosts can compare to differentiate between PVDs. The option can directly carry some information about a PVD and can optionally point to additional PVD information that can be retrieved using HTTP over TLS. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality There were two key discussions about the PVD Option that informed the design. First: all necessary (non-optional) data for making consistent use of a network (PVD information) must be transmitted atomically. Use of existing RA header and options support this (i.e. PIO, RIO, RDNSS). The atomicity of receiving the minimum required set of information helped establish that there would be no dependency loop on the (supposed to be) optional data. Second: there should be support for PVD Option-aware and non-aware clients on the same network. This is the origin of the RA option encapsulating format. Personnel The Document Shepherd is Erik Kline <email@example.com>. The Responsible Area Director is Suresh Krishnan <firstname.lastname@example.org>.