Hi Pierrick, Thank you very much for adopting the comments. Now I'm very satisfied with the document.
BR, Haibin > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Wednesday, April 27, 2011 3:58 PM > To: Songhaibin; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > 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:[email protected]] > > Envoyé : mercredi 27 avril 2011 05:43 > > À : [email protected] > > Cc : [email protected]; [email protected]; draft-ietf-mif-current- > > [email protected] > > 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 [email protected] > > 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 _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
