[Int-area] Proposed updates for draft-ietf-intarea-provisioning-domains

[Tommy Pauly <[e-mail]>]

Hello INTAREA,

Thanks to everyone for their feedback yesterday on the various proposals for the -06 version of draft-ietf-intarea-provisioning-domains.

I've made several updates to the Pull Request (https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/11) based on the feedback we received.

Please take a look at the changes, detailed here, and let us know if this works for you!

Best,
Tommy

Here is a summary of the changes made since yesterday:

Clarify DNS Resolution (Paul Hoffman's comments)
=======================================

Added the following paragraph:

   PvD-aware applications will be able to select which PvD(s) to use for
   DNS resolution and connections, which allows them to effectively use
   multiple Explicit PvDs.  In order to support non-PvD-aware
   applications, however, PvD-aware hosts SHOULD ensure that non-PvD-
   aware name resolution APIs like "getaddrinfo" only use resolvers from
   a single PvD for each query.  More discussion is provided in
   Section 5.2.1 of [RFC7556].

Normative language around backoff timers (Gorry's comments)
================================================

Changed text to say:

   o  When a host performs a JSON object update after it detected a
      change in the PvD Option Sequence Number, it MUST add a delay
      before sending the query.  The target time for the delay is
      calculated as a random time between zero and 2**(Delay * 2)
      milliseconds, where 'Delay' corresponds to the 4-bit unsigned
      integer in the last received PvD Option.

   o  When a host last retrieved a JSON object at time A that includes a
      expiry time B using the "expires" key, and the host is configured
      to keep the PvD information up to date, it MUST add some
      randomness into its calculation of the time to fetch the update.
      The target time for fetching the updated object is calculated as a
      uniformly random time in the interval [(B-A)/2,B].

JSON, I-JSON, CBOR (Dave Thaler, Erik Kline, Erik Nygren's comments)
========================================================

Specified that we expect the reduced profile of JSON (I-JSON):

   This JSON object is restricted to the restricted profile of I-JSON,
   as defined in [RFC7493].

Explained the intended use of the JSON in the scope of this document,
And why we're not doing CBOR here:

   The additional information related to a PvD is specifically intended
   to be optional, and is targeted at optimizing or informing the
   behavior of user-facing hosts.  This information can be extended to
   provide hints for host system behavior (such as captive portal or
   walled-garden PvD detection) or application behavior (describing
   application-specific services offered on a given PvD).  This content
   may not be appropriate for light-weight Internet of Things (IoT)
   devices.  IoT devices might need only a subset of the information,
   and would in some cases prefer a smaller representation like CBOR
   ([RFC7049]).  Delivering a reduced version of the PvD Additional
   Information designed for such devices is not defined in this
   document.


DHCPv6 Association (Discussion from Suresh, Lorenzo, Ted, Erik Kline)
=======================================================

After the meeting, we had a hallway conversation, and brought up the possibility of limiting the scope of associating DHCPv6 information
to the set of RA information that is currently presented to legacy (non-PvD-aware) hosts. This provides the greatest amount of
backwards-compatibility, without introducing unnecessary logic for comparing prefixes and addresses between the two sources, etc.

This change involves adding a clarifying definition for a concept that was already present, but not defined:

   Legacy-Visible Explicit PvD:  An Explicit PvD that contains
      information that non-PvD-aware hosts detect and use.  These PvDs
      are usable by both legacy and PvD-aware hosts, although PvD-aware
      hosts can be aware of the identifier and additional information
      associated with the PvD.

   Any RA that contains a PvD Option defines an Explicit PvD, which will
   be visible and usable by PvD-aware hosts.  If an RA contains only a
   PvD Option at its top-level, with all other RA options contained
   within the PvD Option (with the R-flag set), the Explicit PvD will be
   visible only to PvD-aware hosts.  If, on the other hand, an RA
   contains other options at the top-level, and the PvD Option does not
   have the R-flag set, the Explicit PvD will be visible to both PvD-
   aware and legacy hosts.  Such PvDs are referred to as Legacy-Visible
   Explicit PvDs.

The text for DHCPv6 association can then be reduced to the following:

3.4.1.  DHCPv6 configuration association

   When a PvD-aware host receives DHCPv6 [RFC8415] configuration
   elements, it SHOULD associate the received information with all
   Implicit PvDs and Legacy-Visible Explicit PvDs.  This is intended to
   maintain behavior of how data is associated for non-PvD-aware hosts.