Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-11

[Ballot discuss]
Section 4.4.  Per “When a host retrieves the PvD Additional Information, it MUST verify that the TLS server certificate is valid for the performed request (e.g., that the Subject Alternative Name is equal to the PvD ID expressed as an FQDN).  This authentication creates a secure binding between the information provided by the trusted Router Advertisement, and the HTTPS server.”, what is the trust anchor the client is supposed to use to valid the server certificate is valid?  How is that trust anchor provisioned?

[Ballot comment]
I support Ben Kaduk and Adam Roach’s DISCUSS positions.

Section 4.1.  Per “If the HTTP status of the answer is between 200 and 299, inclusive, the host MAY get a file containing a single JSON object”, what should be the behavior of a host that gets 200 status code  but no JSON object – should it try again, conclude (like in a 4xx status code) that there is not further information, etc.?

[Ballot discuss]
Thanks to the authors and working group for their work on this document.  I
have one major concern about the ability for this mechanism to be abused to
form DDoS attacks, described below. Unfortunately, while I have identified the
attack, I don't have an easy solution to propose that mitigates it satisfactorily.

I also have a handful of mostly editorial comments on the document.

---------------------------------------------------------------------------

§6:

I was expecting to see a discussion of the DDoS attack that may result from a
large network (or a rogue host on such a network) sending out a PvD ID
containing the hostname of a victim machine, and setting the "H" flag.

Since the messages used to trigger these HTTP connections are extremely
lightweight, unauthenticated UDP messages, and the resulting HTTP connections
require the exchange of a significant number of packets in addition to a
number of cryptographic operations, this is a very high ratio amplification
attack, both in terms of network and CPU resources.

Given that the delay setting comes from the network instead of being
independently computed by the host, such an attack could be honed to be
particularly devastating.  Although it isn't a complete mitigation, one
approach to consider would be moving computation of the delay upper bound to
the host, or specifying a minimum upper bound of several minutes (where a
smaller value will cause the host to use this minimum upper bound).

Regardless of how this is ultimately handled, I think this is a pretty severe
risk that needs addressing in the document prior to publication.

[Ballot comment]
>  This document also introduces a mechanism for hosts to retrieve
>  optional additional information related to a specific PvD by means of
>  an HTTP over TLS query using an URI derived from the PvD ID.

Nit: "...a URI..."

---------------------------------------------------------------------------

§3.4.1:

>  This is intended to
>  resolve backward compatibility issues with rare deployments choosing
>  to assign addresses with DHCPv6 while not sending any matching PIO.

It seems that this set of circumstances could also arise due to a
misconfiguration of DHCPv6. If this is expected to be only rarely
intended, perhaps some oprationational/implementation guidance to log
a warning or otherwise alert the operator would be helpful.

---------------------------------------------------------------------------

§4.1:

>  HTTP requests and responses for PvD additional information use the
>  "application/pvd+json" media type (see Section 8).  Clients SHOULD
>  include this media type as an Accept header in their GET requests,

Nit: "...Accept header field..."

---------------------------------------------------------------------------

§4.1:

>  If the HTTP
>  status of the answer is between 200 and 299, inclusive, the host MAY
>  get a file containing a single JSON object.

This is very confusing phrasing. The sentence -- and the use of a normative
"MAY" in particular -- indicates that the host is given permission to take
some additional action that "gets" a JSON object from somewhere. I think it's
intending to say that a 200-class HTTP response will contain such an object.

Consider rephrasing.

---------------------------------------------------------------------------

§4.3:

>  Private-use or experimental keys MAY be used in the JSON dictionary.
>  In order to avoid such keys colliding with IANA registry keys,
>  implementers or vendors defining private-use or experimental keys
>  MUST create sub-dictionaries, where the sub-dictionary is added into
>  the top-level JSON dictionary with a key of the format "vendor-*"
>  where the "*" is replaced by the implementer's or vendor's
>  identifier.  For example, keys specific to the FooBar organization
>  could use "vendor-foobar".  Upon receiving such a sub-dictionary,
>  host MUST ignore this sub-dictionary if it is unknown.  When the
>  vendor or implementer is part of an IANA URN namespace [URN], the URN
>  namespace SHOULD be used rather than the "vendor-*" format.

This is kind of a minor nit, but this paragraph is a bit confusing.  It
starts off with a less-preferred convention ("vendor-*") and discusses
it as if it were the only way to do things; and then it throws in a
SHOULD-strength different encoding at the end as a surprise twist.
I would suggest reworking the paragraph so that the preferred encoding
(URNs) are mentioned first, as a SHOULD-strength statement, followed by
the less-preferred "vendor-*" as a fallback.

---------------------------------------------------------------------------

§4.3:

>  +------------+-----------------+-----------+------------------------+
>  | JSON key  | Description    | Type      | Example                |
>  +------------+-----------------+-----------+------------------------+
>  | identifier | PvD ID FQDN    | String    | "pvd.example.com."    |

...

>  {
>    "identifier": "cafe.example.com",
>    "expires": "2017-07-23T06:00:00Z",
>    "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
>  }

I'm concerned about the variation in the identifier field alternately
containing and not containing the terminal dot of the FQDN. If the
intention that these are to be equivalent, it would probably head off
some implementation incompatibilities if the document were to say so
explicitly.

---------------------------------------------------------------------------

§7:

>  without leaking identity information, SHOULD make use of an IPv6
>  Privacy Address and SHOULD NOT include any privacy sensitive data,
>  such as User Agent header or HTTP cookie, while performing the HTTP

Nit: "...User-Agent header field..."
            ^            ^^^^^

[Ballot discuss]
Alexey basically already noted this in his Comment, but I'll elevate it
to a Discuss: the usage of TLS for retrieving PvD Additional Information
is not really completely specified -- generally in this sort of case
where there's a (provisioning) domain name to authenticate we'd expect
to require that the server present a certificate with DNS-ID [RFC6125]
that matches the expected name.  We could also cite RFC 7525 for TLS
best practices and/or make a TLS version recommendation (i.e., 1.3).

There seems to be a missing step in the binding of the PvD ID to the
actual usage, or rather, we are making stronger statements about
authenticity than the technology seems to justify.  While we can verify
that the TLS certificate used to access the additional information
matches with the PvD ID provided, there doesn't seem to be a step to
validate that the PvD ID in question is applicable for the current
network environment.  The prefix match helps some, but (to first order)
only for globally-routable prefixes in the absence of NAT.  Malicious
routers (e.g., coffeeshop wifi) can fairly easily implement NAT66 and
circumvent host-side countermeasures; tunneling traffic through to a
compromised host actually in the target PvD would allow circumvention of
the TLS-server-side countermeasures.  I have some suggested rewordings
in the Comment section that should bring the claims in line with what is
actually provided.

(As something of a side note, it seems that the JOSE/signature scheme
discussed in the secdir review thread, that does have a tighter binding
to the local network with the PvD, could defeat the caching attack
discussed there by having the host supply a nonce in the RS and
including that in the signed response, but that requires a lot of
expensive signatures and has some challenging key-management problems.
So it doesn't seem worth pursuing, even though it's attractive to make
more use of the network locality.)

The IANA Considerations for PvD Option Flags indicates that bits 0 to 15
are managed by IANA, but I think there are only 12 bits available due to
the 4-bit Delay field.

[Ballot comment]
Section 3.1

Do we want to give any guidance about what to put for the Sequence
Number (and/or Delay) when the H-bit is not set?  IIUC they are only
relevant for the fetching of additional data.

  R-flag:  (1 bit) 'Router Advertisement' flag stating whether the PvD
      Option is followed (right after padding to the next 64 bits
      boundary) by a Router Advertisement message header (see section
      4.2 of [RFC4861]).  The usage of the inner message header is
      described in Section 3.4.

nit(?): I'd be wary of saying "PvD option is followed", since IIUC the
inner RA header and subsequent options are still part of "the PvD
option".

Section 3.2

  In order to provide multiple different PvDs, a router MUST send
  multiple RAs.  If more than one different Implicit PvD is advertised,
  the RAs MUST be sent from different link-local source addresses.

This seems to imply that implicit PvDs can be advertised via the PvD RA,
but the only contents specified for the "PvD ID FQDN" field thereof is a
DNS-format FQDN, and we don't say how to construct one of those for an
implicit PvD.  I think the intent is just to say that "RAs sent from
different link-local source addresses establish distinct implicit PvDs,
in the absence of a PvD Option".

Section 3.4

  received RA otherwise.  If an RA message header is present both
  within the PvD Option and outside it, as indicated by the R-flag, the
  header within the PvD Option takes precedence.

Why is the R-flag relevant?

  Similarly, hosts MUST associate all network configuration objects
  (e.g., default routers, addresses, more specific routes, DNS
  Recursive Resolvers) with the PvD associated with the RA which last
  updated the object.  For example, addresses that are generated using
  a received Prefix Information option (PIO) are associated with the
  PvD of the last received RA which included the given PIO.

I'm not sure I'm parsing the first sentence as intended.  For any given
configuration object, there will be an RA which has most-recently
updated that object ("last updated the object"); that RA has some
associated PvD, whether via explicit PvD ID option or assignment of
implicit PvD.  It sounds like this is telling me to associate the object
with the aforementioned PvD, so that "last PvD wins" for any given
object, but this seems at odds with the idea of having multiple PvDs
active at once, with separate configurations.  So I'm not sure that
the "last updated" phrasing is giving the right impression.

  While resolving names, executing the default address selection
  algorithm [RFC6724] or executing the default router selection
  algorithm when forwarding packets ([RFC4861], [RFC4191] and

Is this an exhaustive list?

  [RFC8028]), hosts and applications MAY consider only the
  configuration associated with any non-empty subset of PvDs.

  For example, a host MAY associate a given process with a specific
  [...]

nit: maybe these should not be separate paragraphs?

Section 3.4.1

  When a host retrieves stateful assignments using DHCPv6, such
  assignments MUST be associated with the received PvD which was
  received with RAs with the M-flag set and including a matching PIO.

Is there a reason to use different language here than the previous
paragraph (which was "all the explicit and implicit PvDs received on the
same interface and [stuff about the RA]")?

  In cases where an address would be assigned by DHCPv6 and no matching
  PvD could be found, hosts MAY associate the assigned address with any
  implicit PvD received on the same interface or to multiple of
  implicit PvD received on the same interface.  This is intended to
  resolve backward compatibility issues with rare deployments choosing
  to assign addresses with DHCPv6 while not sending any matching PIO.

Wouldn't backwards compatibility be better if we specified "all implicit
PvD on the same interface" rather than leaving things in a
nondeterministic state?

Section 3.4.2

  When a PvD-aware host retrieves configuration elements from DHCPv4,
  the information is associated either with a single Explicit PvD on
  that interface, or else with all Implicit PvDs on the same interface.

This is further specified in the following two paragraphs, right?  So
maybe "as detailed below" would help the reader.

Section 3.4.4

  PvD-aware hosts can be provisioned with recursive DNS servers via RA
  options passed within an Explicit PvD, via RA options associated with
  an Implicit PvD, via DHCPv6 or DHCPv4, or from some other
  provisioning mechanism that creates an Implicit PvD (such as a VPN).

nit: didn't we say that IPsec VPNs were explicit PvDs?  If so, they will
not be provisioning recursive DNS servers via RA options, and thus are
not covered by any of the items in this listing.

  In all of these cases, the recursive DNS server addresses SHOULD be
  associated with the corresponding PvD.  Specifically, queries sent to
  a configured recursive DNS server SHOULD be sent from a local IP
  address that was provisioned by the PvD via RA or DHCP.  Answers

nit: are they provisioned "by" the PvD" or "with"/"for" the PvD?

  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.  Handling DNS across PvDs is discussed

just to check: this SHOULD is only at a per-API-call level, and
subsequent calls to getaddrinfo (even with the same arguments) are
permitted to use results from different PvDs?  I would have naievly
expected that the "default PvD" used for such non-PvD-aware applications
would be relatively stable over time...

Section 4

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

nit: I-JSON is a restricted profile of JSON, but does not itself has a
"restricted profile" subset, so I'd suggest just "is restricted to the
I-JSON profile".

Section 4.1

  Note that the DNS name resolution of the PvD ID, the PKI (Public Key
  Infrastructure) checks as well as the actual query MUST be performed
  using the considered PvD.  In other words, the name resolution, PKI

nit(?): I am not sure if these "PKI checks" are supposed to be DNSSEC or
the TLS validation.  I don't think we previously discussed having
separate per-PvD TLS trust anchors, which mostly leads me to assume
DNSSEC PKI, but greater clarity in the document would be welcome.

  If the HTTP status of the answer is greater than or equal to 400 the
  host MUST abandon and consider that there is no additional PvD
  information.  If the HTTP status of the answer is between 300 and

nit: "abandon" is a transitive verb and requires an object.

  399, inclusive, it MUST follow the redirection(s).  If the HTTP
  status of the answer is between 200 and 299, inclusive, the host MAY
  get a file containing a single JSON object.

Is redirect-chasing recursive or one-time?
I agree with Alissa that this "MAY" is not normatiave.

  After retrieval of the PvD Additional Information, hosts MUST
  remember the last Sequence Number value received in the RA including
  the same PvD ID.  Whenever a new RA for the same PvD is received with

nit: s/the RA/an RA/

  a different Sequence Number value, or whenever the expiry date for
  the additional information is reached, hosts MUST deprecate the
  additional information and stop using it until a new JSON object is
  retrieved.

Is this really just "a different Sequence Number value" or do we want "a
larger Sequence Number value"?  If the former, then it's not really
functioning as a *sequence* number, is it?
Also, is the "until [...]" clause really needed?  Regardless of whether
new additional information is retrieved (and validated), *this*
additional information is still not being used.

nit: if we are going to say "uniformly random" for the [(B-A)/2,B]
interval, we should probably also use "uniformly" for the "random time
between zero and 2**(Delay * 2) milliseconds".

  Since the 'Delay' value is directly within the PvD Option rather than
  the object itself, an operator may perform a push-based update by
  incrementing the Sequence value while changing the Delay value

nit: "Sequence Number"

Section 4.2

  RA by the network operator.  In particular, when a captive portal is
  present, hosts MUST still be allowed to perform DNS, PKI and HTTP
  over TLS operations related to the retrieval of the object, even
  before logging into the captive portal.

I assume "DNS" here means "DNS over UDP(/TCP) on port 53 in the
traditional, unencrypted, protocol of STD 13"?  It may be prudent to be
clear about the expectations here.

  Routers SHOULD increment the PVD Option Sequence Number by one
  whenever a new PvD Additional Information object is available and
  should be retrieved by hosts.  If the value exceeds what can be
  stored in the Sequence Number field, it SHOULD wrap back to zero.

Why are these just "SHOULD"?

  The server providing the JSON files SHOULD also check whether the
  client address is part of the prefixes listed into the additional
  information and SHOULD return a 403 response code if there is no
  match.

(I assume that the "SHOULD" is to allow for exceptions when NAT-shaped
things are in use.)
nit: "is part of" is perhaps a bit odd

Section 4.3

[perhaps update the example "expires" value to something slightly more
current, both here and in 4.3.1?]

  | noInternet | No Internet, set    | Boolean  | true              |
  |            | when the PvD is      |          |                    |
  |            | restricted.          |          |                    |

nit: "set to 'true'"; setting it to "false" does not provide such an
indication :)

In addition to Alissa's Discuss point, "MUST create sub-dictionaries,
[...] with a key of the format 'vendor-*'" is in conflict with "URN
namespace SHOULD be used rather than the 'vendor-*' format".

Section 4.4

  When a host retrieves the PvD Additional Information, it MUST verify
  that the TLS server certificate is valid for the performed request
  (e.g., that the Subject Alternative Name is equal to the PvD ID
  expressed as an FQDN).  This authentication creates a secure binding
  between the information provided by the trusted Router Advertisement,

What makes an RA "trusted"?

  and the HTTPS server.  However, this does not mean the Advertising
  Router and the PvD server belong to the same entity.

Can you give me an example of when they would not be part of the same
entity?  I can only partially see how that would happen.

I see there's some discussion of client IPv4 addresses here, but note
that the "prefixes" entry in the additional information is specifically
limited to IPv6 prefixes.  Does the prefix check just not work at all
for IPv4, or we know that NAT44 is too prevalent for it to be worth
trying, or ...?

Section 5

Do you want to also mention that some fields (e.g., Sequence Number) are
only listed when relevant, and/or provide default values for the
examples when they are not explicitly listed?

Section 5.2

  In the above example, non-PvD-aware hosts will only use the first RA
  sent from their default router and using the 2001:db8:cafe::/64
  prefix.  PvD-aware hosts will autonomously configure addresses from

nit(?): I can't decide whether "from" or "for" is intended in "from
their default router".

  both PIOs, but will only use the source address in 2001:db8:f00d::/64
  to communicate past the first hop router since only the router
  sending the second RA will be used as default router; similarly, they
  will use the DNS server 2001:db8:f00d::53 when communicating with
  this address.

nit: I'm not sure I understand what "communicating with this address" is
intended to mean (it would make more sense to me as "communicating from
this adddress").

Section 5.3

      *  RA Header: router lifetime = 1600 (PvD-aware hosts will use
        this router as a default router), implicit length = 2

just to check my understanding: this is only "use as a default router"
within the scope of this PvD (and will use the other RA's data as
default router for the other PvD)?  I'd perhaps consider adding "for
this PvD", though it's far from clear that such clarification in the
text is needed.

Section 6

This RA Option can include other RA Options; we should probably note
that the security considerations of the included options continue to
apply.

When RAs have to be split to avoid exceeding the link MTU, there is
perhaps some scope for selective packet blocking to influence host
behavior (by denying them some of the PvD-specific configuration),
though of course such attacks are pretty challenging on a local
network/link.

Attacks to block attempts to retrieve the additional information are
more likely succeed, though the scope is perhaps limited since all that
stuff is supposed to be optional.  We can't really limit what vendors
will do with it, though, so we should probably treat it as having some
significant risk of DoS.

Expiration times are represented as absolute times, so the usual
considerations about accurate time and clock skew apply.

  This specification does not improve the Neighbor Discovery Protocol
  security model, but extends the purely link-local trust relationship
  between the host and the default routers with HTTP over TLS
  communications which servers are authenticated as rightful owners of
  the FQDN received within the trusted PvD ID RA option.

I think I need some more persuasion to believe that the routers are
actually "authenticated as rightful owners of the FQDN received" as
claimed here.  In light of the following paragraph in the text, perhaps
we should say something more like "validates that the owner of the FQDN
authorizes its use with the prefix advertised by the router" and "in
combination with implicit trust in the local router (if present), this
gives the host some level of assurance that the PvD is authorized for
use in this environment.  However, when the local router cannot be
trusted, no such guarantee is available."

  Users cannot be assumed to be able to meaningfully differentiate
  between "safe" and "unsafe" networks.  This is a known attack surface
  that is present whether or not PvDs are in use, and hence cannot be
  addressed by this document.  However, a host that correctly
  implements the multiple PvD architecture ([RFC7556]) using the
  mechanism described in this document will be less susceptible to such
  attacks than a host that does not by being able to check for the
  various misconfigurations described in this document.

I think this is only true for certain definitions of "safe" and would
like to learn more about what definition the authors had in mind when
writing this.

Section 7

Whenever we introduce new identifier (types), the question of privacy
considerations arises with respect to tracking of the identified entity
or related entities, among other things.  The PvD itself here is not
really "trackable", so we seem to be concerned only with tracking of
devices that connect to /use a given PvD.  I'll try to walk through the
workflow to confirm that there's not more that needs to be said here:
Generally, a host is going to mostly just be receiving the PvD ID value,
and not broadcasting it in much outgoing traffic.  It would perhaps get
some configuration about PvD IDs in some area (though configured PvD IDs
seems more likeoy on routers than hosts), and receives PvD IDs via RA
options, and uses the PvD ID to correlate/associate information across
RAs, potentially across networks and mobility events.  The only time I
see the PvD ID being sent outbound from a PvD-aware host is in the query
to the PvD's well-known URI for additional information, and we say that
the DNS resolution used to look up that name must be from the same
configuration that claims to use that PvD. This is done with the intent
that there's no additional information leakage, as we're essentially
just echoing back the PvD ID to the same administrative entity that gave
it to us.  For honest routers it clearly should work fine, but what
happens if we have dishonest routers?  A dishonest router could send an
RA claiming a different/bogus PvD ID, and an honest host as specified
here would then go ahead and make the DNS+HTTPS query for additional
information, which is still just echoing back the value that was sent,
to who sent it.  There would only be some additional information leakage
if the host was configured to be selective about which PvDs to fetch
additional information for, so that the attacker could check whether a
given PvD ID was on the whitelist or not.  I think, though, that even if
a host does have a whitelist of PvD IDs it will use, there's still no
harm from always fetching the additional information and just discarding
it for non-whitelisted PvDs -- that lets such a host blend into the
genera population of PvD-aware hosts without directly revealing that it
has a whitelist or the contents thereof.  (Its subsequent network
traffic might still give some implicit signal, though that's perhaps
less conclusive.)

I don't have a great sense of how (un)likely host-leve PvD whitelists
are to be seen in practice, and thus whether it's worth putting the
above advice/analysis (just the "to blend in, always fetch even if you
ignore" part) into the document.  Given that we do mention
FQDN/IP-prefix whitelists, I'm leaning towards including this aspect as
well.

(The above analysis changes some if a host is going to be caching any
PvD-specific information across mobility events within the same PvD, but
I don't see much to indicate that such long-term caching would occur.)

  default router, this property can't be ensured.  Therefore, hosts
  willing to retrieve the PvD Additional Information before using it
  without leaking identity information, SHOULD make use of an IPv6

nit: this is either tautological or not saying what it's intended to,
since it's impossible to use the information without having first
retrieved it...

  Privacy Address and SHOULD NOT include any privacy sensitive data,
  such as User Agent header or HTTP cookie, while performing the HTTP
  over TLS query.

...so perhaps rephrasing akin to "To minimize the leakage of identity
information while retrieving PvD Additional Information, hosts SHOULD
[...]" is in order.

  From a user privacy perspective, retrieving the PvD Additional
  Information is not different from establishing a first connection to
  a remote server, or even performing a single DNS lookup.  For
  example, most operating systems already perform early queries to well
  known web sites, such as http://captive.example.com/hotspot-
  detect.html, in order to detect the presence of a captive portal.

I understand the desire to only use names/numbers designated as "for
example use" in RFCs, but this seems like a case where it might be worth
making an exception.

  Network operators SHOULD restrict access to PvD Additional
  Information to only expose it to hosts that are connected to the
  local network, especially if the Additional Information would provide
  information about local network configuration to attackers.  This can

(It seems that even the existence of a vendor-* subobject might be
considered "sensitive" in this fashion.)

Section 8.2

Is there any additional guidance we wish to give to the Experts?

Section 8.3

  document (as specified in Figure 1).  Future assignments require
  Standards Action [RFC8126], via a Standards Track RFC document.

nit: please drop the "via a Standards Track RFC document" clause; it's
basically redundant with Standards Action and I'm not sure why there's a
specific need to disallow BCP documents from allocating such codepoints.

Section 8.4

  Interoperability considerations: This document specifies format of
  conforming messages and the interpretation thereof.

nit: "the format"

  Applications that use this media type: This media type is intended to
  be used by network advertising additional Provisioning Domain
  information, and clients looking up such information.

nit: "networks" plural

Section 10.1

I'm not sure whether RFCs 2131, 3646, and 8106 need to be Normative.

Section 10.2

On the other hand, RFC 2818 does seem like it needs to be Normative (and
7556 as was already mentioned).

[Ballot comment]
Thank you for writing such a useful (and readable!) document; the amount of Operational Considerations (and examples) warms my heart :-)
I was going to point out the "an hostile network" nit, but Barry beat me to it...

Thanks to Tim Chown for his OpsDir review, and the authors for addressing the comments.

[Ballot comment]
I believe that rfc7556 must be a Normative reference: it defines PvDs, which are the base for this specification.

[I am not balloting DISCUSS because this should be a fairly simple issue to address, and I trust the Responsible AD to do the right thing.]

[Ballot discuss]
This is a nit that should be easy to resolve but I'm confused by it, so I'm flagging it here. The reference for [URN] in Section 10.2 says '[URN] "URN Namespaces", n.d..,' which seems like an error. Given the way [URN] is used in 4.3, I'm not sure I understand why organizations with formal URN namespaces  would be expected to be using PvDs, if that is what the document intends to convey. In any event, at a minimum the reference needs to be fixed.

[Ballot comment]
= Section 4.1 =

"If the HTTP
  status of the answer is between 200 and 299, inclusive, the host MAY
  get a file containing a single JSON object."

This seems like a misuse of normative MAY, as the behavior is determined by the sending server, not the host.

= Section 7 =

s/IPv6 Privacy Address/IPv6 temporary address/
(to align with RFC 7721 terminology)

[Ballot comment]
Thanks for this well-written document (and thanks Martin for the TSV-ART review)!

I have no real issues but two quick questions:

1) In Sec 3.4 (and somewhere earlier as well), you say:
"In case multiple PvD Options are found in a given RA, hosts MUST
  ignore all but the first PvD Option."
Why is that restriction actually needed? I mean given you can send multiple RA from the same source address with each an PvD Option with either different of the same ID, would it be so bad to have multiple PvD Option in the same RA?

2) As this document refers to draft-kline-mif-mpvd-api-reqs, is there any plan to update and publish this doc? However, this draft anyway "only" talk about API requirement, but I guess some network signalling would also be needed...? Is there any additional work?

P.S.: The shepherd writ-up seems a bit out-dated...

[Ballot comment]
Thanks for this well-written document (and thanks Martin for the TSV-ART review)!

I have no real issues but two quick questions:

1) In Sec 3.4 (and somewhere earlier as well), you say:
"In case multiple PvD Options are found in a given RA, hosts MUST
  ignore all but the first PvD Option."
Why is that restriction actually needed? I mean given you can send multiple RA from the same source address with each an PvD Option with either different of the same ID, would it be so bad to have multiple PvD Option in the same RA?

2) As this document refers to draft-kline-mif-mpvd-api-reqs, is there any plan to update and publish this doc? However, this draft anyway "only" talk about API requirement, but I guess some network signalling would also be needed...? Is there any additional work?

[Ballot comment]
This is a well written document, but I have a small set of issues I would like to discuss:

4.4.  Detecting misconfiguration and misuse

  When a host retrieves the PvD Additional Information, it MUST verify
  that the TLS server certificate is valid for the performed request
  (e.g., that the Subject Alternative Name is equal to the PvD ID
  expressed as an FQDN).

The last sentence is not right: you should say “one of Subject Alternative Names is equal to ... “ because a server certificate can have multiple Subject Alternative Names.

5.4.  Providing Additional Information to PvD-Aware Hosts

This section is using HTTP/2 syntax for requests and responses, but HTTP 2 RFC is not listed as a reference.

[Ballot comment]
4.4.  Detecting misconfiguration and misuse

  When a host retrieves the PvD Additional Information, it MUST verify
  that the TLS server certificate is valid for the performed request
  (e.g., that the Subject Alternative Name is equal to the PvD ID
  expressed as an FQDN).

The last sentence is not right: you should say “one of Subject Alternative Names is equal to ... “ because a server certificate can have multiple Subject Alternative Names.

[Ballot comment]
Nit in Section 6: “an hostile network access provider”.

In Section 8.4, please add the “Fragment identifier considerations” entry in the template, as required by RFC 6838.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-intarea-provisioning-domains-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the IPv6 Neighbor Discovery Option Formats registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

the entry for option type 21, PVD ID Router Advertisement Option will have the reclaimable text removed from the registration and have the reference changed to [ RFC-to-be ].

Second, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a new entry will be added to the registry as follows:

URI Suffix: pvd
Change Controller: IETF
Reference: [ RFC-to-be ]
Status: permanent
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, a new registry is to be created called the Additional Information PvD Keys registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Expert Review as described in [RFC 8126].

There are initial registrations in the new registry.

IANA Question --> The author provide two tables in section 4.3 of the current draft. One is a set of mandatory keys, the other is a set of optional keys. Which (or, both?) of these tables is to be used as the set of initial registrations for the new registry?

Fourth, a new registry is to be created called the PvD Option Flags registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Standards Action as defined by [ RFC 8126 ].

There are initial values in the new registry as follows:

Bit Flag
Number Name Reference
--------+--------------+-------------
0 H-flag [ RFC-to-be ]
1 L-flag [ RFC-to-be ]
2 R-flag [ RFC-to-be ]
3-15 Unassigned

Fifth, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new media type will be registered as follows:

Name: pvd+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-intarea-provisioning-domains@ietf.org, int-area@ietf.org, ek@loon.com, Erik Kline , suresh@kaloom.com, intarea-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Discovering Provisioning Domain Names and Data) to Proposed Standard


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document: - 'Discovering Provisioning
Domain Names and Data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Provisioning Domains (PvDs) are defined as consistent sets of network
  configuration information.  This allows hosts to manage connections
  to multiple networks and interfaces simultaneously, such as when a
  home router provides connectivity through both a broadband and
  cellular network provider.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ballot/


No IPR declarations have been submitted directly on this I-D.

Document writeup for:

    https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains-07

based on the template here:

    https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/

as of 2019.06.06.

---

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

    [1a] The type of RFC being requested is Proposed Standard.

    [1b] This document meets the spirit of RFC 2026 section 4.1.1
    ("Proposed Standard"); the specification "has resolved known
    design choices, [and] is believed to be well-understood" though
    "further experience might result in a change...".

    [1c] The document's title page header states
    "Intended Status: Standards Track."

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

    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 WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

    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.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    I am not aware of any non-hackathon implementations.  The mobile
    operating system vendors have indicated their intent to implement.
    At least one network vendor is in the course of implementing, and
    has funded some open source Linux kernel work as well.

    I am not aware of any media type review that was requested; the
    media type registration template has been completed in the IANA
    Considerations section.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

    The Document Shepherd is Erik Kline .

    The Responsible Area Director is Suresh Krishnan .

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

    [3] I have read this document many times during its evolution. For
    this writeup I have reread it in detail.  I have sent some comments
    to the authors that I think will clarify several minor issues.  I
    would expect that a -08 version (incorporating the feedback as deemed
    appropriate) would be publishable as a proposed standards track
    document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

    [4] The general intarea concerns seem to have been hammered out in
    the discussion among those that spoke up.  It's not clear if others
    in the working group have grasped the potential new use cases and
    architectures that this document enables.  The authors and active
    discussion participants do seem to understand this, of course.

    Some of the comments from the SECDIR review of -04 are of interest,
    and there may well be future work around signing PVD data with JOSE.
    I expect operational experience will motivate and inform such work.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    [5] Beyond the directorate reviews and reviews required for
    IANA-related issues (questions 17 and 18), no additional review
    seems to be required.

    Operational experience will need to be gained with this proposed
    standard and subsequent documents will likely address the
    management of any complexity that arises.

    As mentioned in the SECDIR review, the use of the .well-known URI
    and "vendor-*" PVD JSON keys may need a rethink (I'm not sure, but
    "vendor-*" might fall into the same category as "X-*" vis a vis
    RFC 6648. I have no concerns about the use of either of these.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    [6] None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

    [7] All authors have confirmed that they know of no relevant IPR
    and therefore no appropriate IPR disclosures seem necessary.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    [8a] A search on the IETF datatracker IPR page for:

        https://datatracker.ietf.org/ipr/search/?doctitle=provisioning+domains&submit=doctitle

    turned up only 2 IPR claims, neither of which are filed against this
    document.

    However, this document does have an informative reference to a
    document with an IPR claim (https://datatracker.ietf.org/ipr/2722/).

    [8b] Not Applicable.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

    The document has the solid consensus of those most directly impacted
    by the lack (and, if published, presence) of explicit PvD indicators,
    namely the mobile operating system developers.  The document also
    has (at least one) vendor support.

    Surveying the mailing list archives, there appears to be consensus
    support and no one raising concerns (technical or otherwise) in the
    past year or so.  The number of voices in favor are not numerous,
    but the number opposing appears to be zero.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    [10] No public indications of opposition, nor are any known privately
    by me.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    [11] An email has been sent to authors with review comments. The
    [URN] reference appears to be incomplete.

    The automated checks have not flagged any errors in -07 and the
    document seems to not run afoul of anything listed in
    https://www6.ietf.org/id-info/checklist.html .


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

    [12] The IANA Considerations requests a media type and a .well-known
    URI.

    The media type request appears to conform to RFC 6838 Section 5.6.

    The .well-known URI may or may not have been requested per
    RFC 8615 Section 3.1 (see 17c). I am seeking confirmation from the
    authors.


(13) Have all references within this document been identified as either
normative or informative?

    [13] Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    [14] No; all normative references are already published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

    [15] No; all normative references are one of Internet Standard,
    Proposed Standard, or Draft Standard.  Of note, RFCs 2119 and 8174
    are listed as Informative, and I have sent a note to the others
    asking if they should be moved to normative.  If so reclassified,
    RFC 8174 is a BCP.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

    [16] No RFCs are updated nor any any obsoleted by this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

    [17a] The IANA section appears to be in order with the possible
    exception of the .well-known URI request (see 17c).

    [17b] The existing IPv6 ND Option value 21 is requested to be made
    permanent (remove the reclaimable designation from the existing
    temporary assignment).

    [17c] The IANA Considerations section mentions the RFC 8615
    "Well-Known URI" registry, but it's not clear if registration
    according to RFC 8615 Section 3.1 has taken place or not.

    [17d] The two newly created registries are both identified ("PVD
    Option Flags" and "PVD Additional Information Keys"), define their
    present contents, and document the procedure for updates
    (former: standards action, latter: expert review).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

    [18] This document requests a new IANA registry for
    "Additional Information PvD Keys" new assignments for which would
    require Expert Review.

    Suitable experts would include people familiar with host operating
    system implementations, particularly PVD-aware operating systems,
    since they are likely intended consumers of this data.

    Additionally, review from operators of networks that provide Explicit
    PVD information services could be sought, to confirm there are no
    operational deployment concerns with any proposed new keys.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    [19] None.  Visual inspection of I-JSON text only.

Document writeup for:

    https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains-07

based on the template here:

    https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/

as of 2019.06.06.

---

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

    [1a] The type of RFC being requested is Proposed Standard.

    [1b] This document meets the spirit of RFC 2026 section 4.1.1
    ("Proposed Standard"); the specification "has resolved known
    design choices, [and] is believed to be well-understood" though
    "further experience might result in a change...".

    [1c] The document's title page header states
    "Intended Status: Standards Track."

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

    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 WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

    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.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    I am not aware of any non-hackathon implementations.  The mobile
    operating system vendors have indicated their intent to implement.
    At least one network vendor is in the course of implementing, and
    has funded some open source Linux kernel work as well.

    I am not aware of any media type review that was requested; the
    media type registration template has been completed in the IANA
    Considerations section.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

    The Document Shepherd is Erik Kline .

    The Responsible Area Director is Suresh Krishnan .

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

    [3] I have read this document many times during its evolution. For
    this writeup I have reread it in detail.  I have sent some comments
    to the authors that I think will clarify several minor issues.  I
    would expect that a -08 version (incorporating the feedback as deemed
    appropriate) would be publishable as a proposed standards track
    document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

    [4] The general intarea concerns seem to have been hammered out in
    the discussion among those that spoke up.  It's not clear if others
    in the working group have grasped the potential new use cases and
    architectures that this document enables.  The authors and active
    discussion participants do seem to understand this, of course.

    Some of the comments from the SECDIR review of -04 are of interest,
    and there may well be future work around signing PVD data with JOSE.
    I expect operational experience will motivate and inform such work.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    [5] Beyond the directorate reviews and reviews required for
    IANA-related issues (questions 17 and 18), no additional review
    seems to be required.

    Operational experience will need to be gained with this proposed
    standard and subsequent documents will likely address the
    management of any complexity that arises.

    As mentioned in the SECDIR review, the use of the .well-known URI
    and "vendor-*" PVD JSON keys may need a rethink (I'm not sure, but
    "vendor-*" might fall into the same category as "X-*" vis a vis
    RFC 6648. I have no concerns about the use of either of these.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    [6] None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

    [7] All authors have confirmed that they know of no relevant IPR
    and therefore no appropriate IPR disclosures seem necessary.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    [8a] A search on the IETF datatracker IPR page for:

        https://datatracker.ietf.org/ipr/search/?doctitle=provisioning+domains&submit=doctitle

    turned up only 2 IPR claims, neither of which are filed against this
    document.

    However, this document does have an informative reference to a
    document with an IPR claim (https://datatracker.ietf.org/ipr/2722/).

    [8b] Not Applicable.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

    The document has the solid consensus of those most directly impacted
    by the lack (and, if published, presence) of explicit PvD indicators,
    namely the mobile operating system developers.  The document also
    has (at least one) vendor support.

    Surveying the mailing list archives, there appears to be consensus
    support and no one raising concerns (technical or otherwise) in the
    past year or so.  The number of voices in favor are not numerous,
    but the number opposing appears to be zero.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    [10] No public indications of opposition, nor are any known privately
    by me.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    [11] An email has been sent to authors with review comments. The
    [URN] reference appears to be incomplete.

    The automated checks have not flagged any errors in -07 and the
    document seems to not run afoul of anything listed in
    https://www6.ietf.org/id-info/checklist.html .


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

    [12] The IANA Considerations requests a media type and a .well-known
    URI.

    The media type request appears to conform to RFC 6838 Section 5.6.

    The .well-known URI may or may not have been requested per
    RFC 8615 Section 3.1 (see 17c). I am seeking confirmation from the
    authors.


(13) Have all references within this document been identified as either
normative or informative?

    [13] Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    [14] No; all normative references are already published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

    [15] No; all normative references are one of Internet Standard,
    Proposed Standard, or Draft Standard.  Of note, RFCs 2119 and 8174
    are listed as Informative, and I have sent a note to the others
    asking if they should be moved to normative.  If so reclassified,
    RFC 8174 is a BCP.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

    [16] No RFCs are updated nor any any obsoleted by this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

    [17a] The IANA section appears to be in order with the possible
    exception of the .well-known URI request (see 17c).

    [17b] The existing IPv6 ND Option value 21 is requested to be made
    permanent (remove the reclaimable designation from the existing
    temporary assignment).

    [17c] The IANA Considerations section mentions the RFC 8615
    "Well-Known URI" registry, but it's not clear if registration
    according to RFC 8615 Section 3.1 has taken place or not.

    [17d] The two newly created registries are both identified ("PVD
    Option Flags" and "PVD Additional Information Keys"), define their
    present contents, and document the procedure for updates
    (former: standards action, latter: expert review).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

    [18] This document requests a new IANA registry for
    "Additional Information PvD Keys" new assignments for which would
    require Expert Review.

    Suitable experts would include people familiar with host operating
    system implementations, particularly PVD-aware operating systems,
    since they are likely intended consumers of this data.

    Additionally, review from operators of networks that provide Explicit
    PVD information services could be sought, to confirm there are no
    operational deployment concerns with any proposed new keys.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    [19] None.  Visual inspection of I-JSON text only.