[Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09

[Jouni Korhonen <[e-mail]>]

I am an assigned INT directorate reviewer for
draft-ietf-mif-happy-eyeballs-extension-09. These comments were
written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) 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 on the INT Directorate, see
http://www.ietf.org/iesg/directorate.html.

I recon the review is way late but I am doing it still.

* The document is not ready for publication. The first issues that comes 
out is the language and grammar, which needs a major facelift. In many 
places the reader is left wondering what exactly was meant on the first 
few reads. The second issue really is the technical recommendations how 
to implement HE-MIF enabled device. I cannot say Section 5 describes the 
behaviour well enough for me to be able to implement anything (I do 
realize this is an Informational document but still..). Furthermore, 
Section 6 implementation framework description is somewhat thin.

* Some acronyms such as MIF and PVD are never expanded while some are 
multiple times (like HE).

* The document uses "fast interface" and "most fast path".. Does it mean 
fast by link bandwidth or actually the smallest connection RTT? All 
references to "fast" should be revisited and clarified what is actually 
meant.

* HE-MIF is described as adopting happy eyeballs to MPVD. After reading 
the document this connection is somewhat vague. The document should be a 
bit more concrete on how to apply MPVD specifically to happy eyeballs.

* Use case WiFi is broken:
121   might not be the case for several reasons, such as authentication
122   requirements, instability at layer 2, or even, perhaps, the WiFi

   It is unclear to me how "authentication requirements" applies here.
   Does it actually try to mean captive portal type scenario?
   Also, it is unclear to me how "instability at layer 2" applies here.
   Does it mean the connection is so bad that no packets go through? In
   that case it is likely the device would not be able to acquire or
   keep its IP address either on that interface.

* WiFi use case makes a sudden assumption the device is a mobile phone.
   While this is probably the case the use case description starts off
   with "MIF node".. recommend using something like "MIF enabled mobile
   device".

* I do not understand what the "time slot" means here:
127   to wait an appropriate time slot but not forever.  After the
       timer is

* No Reference to ANDSF.. most readers are linkely unfamiliar with it.

* Sections 5 should really be more concrete with its guidance to
   implementers what to do.

- Jouni