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

[GangChen <[e-mail]>]

Hi Jouni,

thank you for the comments.

2016-05-13 1:14 GMT+08:00, 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.

We will try to improve the readability through the revision.

> * 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.

"fast interface" and "most fast path" actually mean the shortest RTT.


> * 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.

That will be also clarified in the next revision.

> * 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?


You are right. It indicates the captive portal 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.

  The case indicate a weak wifi signal along a moving.
  Device get the IP at bootstrap but still detects the signalling so
it keeps IP addrsss.

> * 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".

   we will update the draft accordingly.

> * 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.


  That will be enhanced.

  BRs

  Gang

> - Jouni
>
>