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