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

[GangChen <[e-mail]>]

Dear Jouni,

We have posted a new update on mif happy eyeballs according to your comments.
The edition has also been polished after reviewer's detailed reviews.
Your further guidance is appreciated.

Many thanks

Gang


A new version of I-D, draft-ietf-mif-happy-eyeballs-extension-10.txt
has been successfully submitted by Gang Chen and posted to the
IETF repository.

Name:           draft-ietf-mif-happy-eyeballs-extension
Revision:       10
Title:          Happy Eyeballs Extension for Multiple Interfaces
Document date:  2016-08-02
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/internet-drafts/draft-ietf-mif-happy-eyeballs-extension-10.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/
Htmlized:
https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-10
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-10

Abstract:
   This memo proposes extensions to the Happy Eyeball's algorithm
   requirements defined in RFC6555 for use with the multiple
   provisioning domain architecture.  The Happy Eyeballs in MIF would
   make the selection process smoother by using connectivity tests over
   pre-filtered interfaces according to defined policy.  This would
   choose the best interface with an automatic fallback mechanism.

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