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. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
