RE: TSVDIR review of draft-ietf-mif-current-practices-10

[Songhaibin <[e-mail]>]

Hi Pierrick,

Thank you very much for adopting the comments. Now I'm very satisfied with the document.

BR,
Haibin

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, April 27, 2011 3:58 PM
> To: Songhaibin; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: TSVDIR review of draft-ietf-mif-current-practices-10
> 
> Hi Haibin,
> 
> Thanks for the review. The draft has been updated accordingly. Please see
> inline for more details.
> 
> Br,
> Pierrick
> 
> > -----Message d'origine-----
> > De : Songhaibin [mailto:[e-mail]]
> > Envoyé : mercredi 27 avril 2011 05:43
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]; draft-ietf-mif-current-
> > [e-mail]
> > Objet : TSVDIR review of draft-ietf-mif-current-practices-10
> >
> > Hi, all,
> >
> > I've reviewed this document as part of the transport area directorate's
> > ongoing effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> > document's authors for their information and to allow them to address any
> > issues raised. The authors should consider this review together with any
> > other last-call comments they receive. Please always CC [e-mail]
> > if you reply to or forward this review.
> >
> > The document describes how the current practices cope with challenges
> > raised by multiple interfaces. This draft is very good to read. And the
> > content is complete in my opinion. But I also have one main comment and
> > two minor comments.
> > --------
> > The main comment:
> >
> > Section 3.3.  Focus on access network selection
> > This section describes the current practices about how to select the
> > access network/points, especially how connection manager deal with the
> > list of preferred SSID and how does it select the access point for
> > attachment. I think this is out of the scope of MIF WG, which is aimed to
> > address the problems raised by multiple interfaces, instead of attachment
> > network/point selection for one interface. And the charter explicitly
> > says: " Network discovery and selection on lower layers as defined by RFC
> > 5113 is out of scope."
> >
> 
> ok, section 3.3 is removed.
> 
> > -------
> > Two minor comments:
> >
> > 3.1.1 Nokia S60 3rd Edition, Feature Pack 2
> >
> > Paragraph " When SNAPs are used, it is possibly for the operating system
> > to notify applications when a preferred IAP, leading to the same
> > destination, becomes available...."
> >
> 
> Rewording:
> 
> When SNAPs are used, the operating system can notify applications when a
> preferred IAP, leading to the same destination, becomes available (for example,
> when a user comes within range of his home WLAN access point), or when the
> currently used IAP is no longer available. If so, applications have to reconnect
> via another IAP (for example, when a user goes out of range of his home WLAN
> and must move to the cellular network).
> 
> > When the word "possibly" is used here, I am a little confused. I guess the
> > authors mean the operating system provides the capability to notify the
> > applications, but the applications may/may not use it. Or does it mean the
> > operating system can decide whether to notify the applications?
> >
> > Section 3.3.1 and 3.3.2
> >
> > These two sections describe the access network selection for Android/HTC
> > Magic and RIM BlackBerry. But they use the similar method and most of the
> > text are the same. So it is possible to merge these two sections. But my
> > this comment is useless if the main comment is accepted.
> >
> 
> n/a since section is removed.
> 
> > By the way, in Section 3.1.3 line 2, delete duplicate "can use".
> >
> 
> Done.
> 
> > I hope this feedback will be useful to the authors.
> >
> 
> Yes, thanks.
> 
> > -Haibin