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