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

[GangChen <[e-mail]>]

Dear Ralph,

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-06-16 15:59 GMT+08:00, GangChen <[e-mail]>:
> Dear Ralph,
>
> I apologize for this late reply.
> Thank you for the comments.
> Those are informative for us.
> Please see my replies inline.
>
> 2016-05-04 5:15 GMT+08:00, Ralph Droms <[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.
>>
>> In my opinion, the documents lacks - and needs - a clear statement of
>> purpose.  What result is the document trying to achieve?  Who is the
>> audience?  How would the audience put the contents of the document to
>> use?
>
> the draft mainly intends to address the issue where a node has
> selected an interface
> and obtained a valid IP address from the network,  but Internet
> connectivity
> is not available. Such scenario is described in the "WiFi is broken"
> of use cases section.
> The purpose of HE-MIF is to avoid such issue. The audience is supposed
> to be connection manager implementors or web browser developer, who
> could integrate the HE-MIF framework into their implementations.
>
> This comment inspire me to re-construct the draft to clear the purpose
> statement.
> It's may probably be better to combine section 1 and 3, since the
> section 3 is major use cases description that may help to state the
> issue HE-MIF targeted.
>
>
>
>> The document must be edited carefully for english language usage
>> before publication.  I would consider this issue to be worthy of a
>> "Discuss" on the document.  I found that the document is unclear in
>> several areas, which prevented me from understanding the meaning of
>> that text.  For example, in section 2, does "within a single home."
>> mean a device in one home or a device with just one interface?  In
>> section 5.1, does:
>>
>>  users may dedicatedly prefer a 3GPP
>>  network interface to seek high-reliability or security benefits even
>>  to manually turn off WiFi interface.
>>
>> mean:
>>
>>  users may turn off a device's WiFi interface to guarantee use of a
>>  3GPP network interface to assure higher reliability or security.
>
> Your interpretation is correct and great example to me.
> I have realized there are several similiar language issues.
> Those days, I'm inviting english knowledged persons to help me fix the
> bugs.
> we will publish an new version to promote the readability.
>
>> Some sections seem to make observations about conditions that might
>> have an influence on an implementation of MIF-HE, but don't have any
>> actionable guidance for implementors.  This lack of clarity is related
>> to the lack of a clear statement of purpose for the document.  For
>> example, in section 5.1:
>>
>>  The decision on mergence of
>>  policies may be made by implementations, by node administrators, even
>>  by other standards investigating customer behavior.  However, it's
>>  worth to note that a demand from users should be normally considered
>>  higher priority than from other actors.
>>
>> I don't see anything in this text that I would consider actionable as
>> an implementor.
>
> The draft is virtually not a algorithm, but requirements for the
> algorithm or implementations.
> The section 5.1 reflects the wg discussion outcome. The actionable for
> implementors is to open an interface to accept user's input expressing
> their preference. And, this preference should be superior to other
> inputs.
>
>> It is unclear where the document explicitly choosing one interface as
>> "faster".  Section 5.2 includes text about "the outcome of each
>> connection attempt"; does this text refer to recording the connection
>> time and using that time as the basis for future interface selection?
>
> It's correct. A timer is used to flush each cache entry and triger
> next connection attempt.
>
>
>> How does HE-MIF interact with HE for selecting between IPv4 and IPv6?
>
> HE-MIF and HE are two parallel threads. They don't have compulsive
> interactions.
> In other words, a device use HE-MIF to choose the faster interface,
> afterwards it may
> use HE to select suitable IP family or it just uses default address
> selection to determine.
>
>
> I hope above could clarify.
>
> Many thanks
>
> Best Regards
>
> Gang
>
>
>>
>