Skip to main content

Discovering Provisioning Domain Names and Data

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,, Erik Kline <>,,,
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:

Ballot Text

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

    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.


    The Document Shepherd is Erik Kline <>.

    The Responsible Area Director is Suresh Krishnan <>.

RFC Editor Note