Re: [Int-dir] Intdir early review of draft-ietf-intarea-provisioning-domains-01

["Eric Vyncke (evyncke)" <[e-mail]>]

Zhen

Thank you again for the review, the authors are finalizing the rev-02 which includes changes based on all your comments and suggestions.

Regards

-éric

On 10/04/18 02:27, "Zhen Cao" <[e-mail]> wrote:

    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)