Re: [mif] WGLC for MIF happy eyeballs

[GangChen <[e-mail]>]

2015-12-16 3:00 GMT+08:00, Daniel Migault <[e-mail]>:
> Hi,
>
> Please see my comments for
> https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07.
> I think it is important for the WG to have such a document.

Thank you, Daniel. Please see my reply inline.


>
> BR,
>
> Daniel
>
> Section Introduction:
>
> """   In multiple interface context, the problems raised by hosts with
>    multiple interfaces have been discussed.  The MIF problem
>    statement[RFC6418] described the various issues when using a wrong
>    domain selection on a MIF node.  """
>
> I think the first sentence should be removed. It does not bring any
> information. In addition, it seems contradicting the second sentence
> with one problem and multiple issues.
>
> s/the most fast/fastest/

Agree. I have updated in my local copy.

>
> I assume the goal of the document is describe MIF-HE to adapt the HE
> concept to the multiple provisionning domain architecture. If I am correct,
> I think it would be good to have it explicitely mentioned.
>
> MIF-HE should be in the terminology section.

Good suggestion. I add new terminology section.
For the completeness, the new section will mention both HE and HE-MIF.

    <section title="Terminology">
      <t>This document makes use of following terms:</t>
      <t><list style="symbols">
      <t>Happy Eyeballs (HE): it specifies requirements [RFC6555] for algorithms
       that reduce user-visible delay of dual-stack hosts within a
single home. </t>

      <t>HE-MIF: it adopts HE methodology to the multiple
      provisioning domain architecture. It describes requirements for algorithms
      that offer connectivity tests to the PVD-aware and non-PVD-aware
nodes [RFC7556].</t>
      </list></t>

    </section>




>
> I am not an english native speaker, but I guess this sentence should
> checked. I also suspect there are multiple nits that should be fixed.
>
> s/A MIF node has both 3/4G and WiFi interface./Assume a MIF node has
> both a 3/4 G interface and a Wifi interface/
>
> s/it' cheap/it is cheap/ maybe cheap should be avoided as well.

I edit the sentence as follows:

[OLD]
   A MIF node has both 3/4G and WiFi interface.  When the node enters a
   WiFi area, a common practice would always prefer WiFi because it'
   cheap and fast-speed normally.

[NEW]
   Assuming a MIF node has both 3GPP mobile network interface and WiFi
   interface, a common practice would always prefer WiFi connection when
   the node enters a WiFi area.

>
> s/User/The user/
>
> s/got IP/got an IP/
>
> s/users have/the user has/
>
> s/Users may won't want /Users may not want/

Those have been corrected. thank you.

>
> """For instance, they may prefer to wait a little bit of time but not
> forever.""" I do not think that is correct. The user may rather accept to
> define an appropriate time slot for the node to attend to set a Wifi
> connexion.

The sentence in the draft doesn't conflict with your thoughts. It may get clear
if change some words.

[OLD]
For instance, they may prefer to wait a little bit of time but not forever.

[NEW]
For instance, they may prefer to wait an appropriate time slot but not forever.

> """Users may won't want the wait time too short, because the 3G path for
> most people is more expensive than WiFi path."""
>
> This sentence is not clear to me. I assume that if 3G/4G is more expensive,
> the user is more likely to provide the Wifi more time to set a
> communication.

As you mentioned, the user may accept an appropriate time slot to wait
on wifi connection. Once the time slot is expired, the user likely
switch over to 3G/4G path to get connection.
This sentence intend to say this time slot can't set too short, as
user likely gives several tries on free wifi.
I try to make following changes.

[OLD]
   After the timer is
   expired, users would finally give up the WiFi path and try to
   establish connection over 3G path.  Users may won't want the wait
   time too short, because the 3G path for most people is more expensive
   than WiFi path.


[NEW]
   After the timer is
   expired, users may finally give up the WiFi path and try to
   establish connection over 3GPP mobile network path.  Users may not
want a very short timer,
   because the mobile network path for most people is more expensive
than WiFi path.
   An appropriate timer is desired to balance user experience and expenditure.

> Section 3.
>
> s/Hard set/Hard Set/
>
> Section 4.2
>
> The section mentions a bootstart URL and then enumerates "e.g. Windows
> Vista, Windows 7, Windows Server 2008 and iOS." I think what you mean is
> that the URL may not be standardized but may be specific to each OS. If I
> am correct, I do not think that is relevant, since it may be provided by
> anyone including the ISPs.

You may suggest to not limited to specific OS implementation if I
understand correctly.
This draft doesn't mandate any implementation, it's just a example.
The draft could change the description similar with RFC7556

"In current implementations, some nodes already implement this, e.g., by trying
to reach a dedicated web server (see [RFC6419])."

> Maybe that is obvious, but I think we shoudl specify that L2 connectivity
> has been checked. Otherwise I am not sur ethis is the only possibility. It
> could also be a firewall for example in an corporate environment. Maybe it
> would be good to specify the assumption that leads to this conclusion, so
> if this assumption changes, the document may still be valid. In other
> words, we should avoid to hav ethat document bound to such assumption.
> Maybe another alternative is to restrict the scope of the draft to captive
> portable as it seems this is the main use case addressed.

Captive portable is the major use case. I'm unable to figure out a good way
to avoid the restriction. It's much appreciated if you have good texts added to
the draft.

> """If anything is abnormal, it assumes there is a proxy on the path. """

> The following sentence is not clear to me:
>
> """Parameters in a soft set should considered at this stage."""

The parameters in the soft set is defined in section 3. I will the
reference like

[NEW]

 """The soft set parameters defined in section 3 should considered at
this stage."""

>
> s/option[RFC6731]/option [RFC6731]/
>
>
>
> """Those information may weight a
>    particular interface to be preferred [one prior] to others sending
>    resolving requests."""
>
> There should be a white space before [RFC as well as "(".
>

That will be modified

many thanks

BRs

Gang

>
>
> On Wed, Dec 9, 2015 at 2:39 AM, GangChen <[e-mail]> wrote:
>
>> Mikael,
>>
>> Many thanks for the comments.
>>
>> 2015-12-08 20:45 GMT+08:00, Mikael Abrahamsson <[e-mail]>:
>> > On Tue, 8 Dec 2015, Hui Deng wrote:
>> >
>> >> Hello all
>> >>
>> >> We have two weeks WG last call for below document:
>> >>
>> https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt
>> >>
>> >> Please send your comments to this thread.
>> >> This WGLC will end on Dec. 22nd.
>> >
>> > The above link is wrong, it links to a 3 year old revision of the
>> > document.
>> >
>> > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07
>> > seems to be the latest.
>> >
>> > It's also my opinion that I would not want this document sent off until
>> we
>> > have decided what to do with the rest of the MIF documents, it's my
>> > opinion that the WGLC call is premature. I believe that MIF-HE is
>> > important, but I also think we should be more ready with the rest of
>> > the
>> > architecture before we ship this document off.
>>
>> It's true to desirably have very clear views of relevant mif documents
>> before the send-off. Yet, I still see the chance to collect wglc
>> comments considering the follows:
>> 1) MIF-HE is not a draft of MPVD cluster.
>> 2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product
>> quality and fix bugs.
>>
>> > Some other comments:
>> >
>> > I would like to see "3/4G interface" replaced with "mobile data
>> interface"
>> > or "3GPP interface" or something else.
>>
>> Sure. It will be fixed. thank you.
>>
>> BRs
>>
>> Gang
>>
>> >
>> > --
>> > Mikael Abrahamsson    email: [e-mail]
>> >
>> > _______________________________________________
>> > mif mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mif
>> >
>>
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif
>>
>