[Int-area] Intdir early review of draft-ietf-intarea-provisioning-domains-01

[Zhen Cao <[e-mail]>]

Reviewer: Zhen Cao
Review result: Ready with Issues

I am an assigned INT directorate reviewer for this draft. These
comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherds should treat these comments
just like they would treat comments from any other IETF contributors
and resolve them along with any other Last Call comments that have
been received. For more details of the INT directorate, see
<http://www.ietf.org/iesg/directorate.html>.

Thank the authors for the work.  This document provides a way for a host to
perform informed selection about the Provisioning Domains (PvDs) of its access
networks, by extending the RA with the defined PvD ID option.

The document is quite ready in the specification of option and associated
actions required by the router and host.   However, some clarification will be
helpful and necessary, see below.

1.  About the 'informed transport selection'.  The abstract mentions that "
This allows applications to select which Provisioning Domains to use as well as
to provide configuration parameters to the transport layer and above." , but
Introduction says that "..when choosing which PvD and transport should be
used."    First of all, this is somehow not aligned, are you going to provide
informed selection of the transport configuration or the transport protocols
(mptcp/tcp/quic) themselves?  But I think informed transport protocol selection
by the RA option is not a recommended approach.   Second, I search the document
and try to find an example of the informed transport configuration selection
but failed.   I think it will be quite useful to include one at least.  I think
one case may be relevant for you to consider, i.e., one provisioning domain is
connected with constrained and lossy links, with minimal available MTU, so that
a small MSS will be included when responding TCP connecting request.   Or maybe
this has further connection with the taps wg?  I hope I am the only one that
feels confused.

2.  in Section 3.3.3, quoted "The exact behavior is TBD  but it is expected
that the one or several PvD associated to the shared interface (e.g. cellular)
will also be advertised to the clients on the other interface (e.g.  WiFi)",  I
am suggesting replace TBD with out of scope of this document.

3.  Authors may consider to include RFC6731 (one fruit of the concluded mif wg)
as an informative reference, there,  informed DNS recursive server selection is
made possible by explicit DHCP extension, which is quite relevant and the
example case in RFC6731 strengthens the case and problem this document wants to
address.

4. some nits, on Page 5:
       A-flag      :   (1 bit) '.... (See section
      4.2 of target="RFC4861"/>).
(may attribute to your xml file)