Hi Pierrick, Thank you very much for adopting the comments. Now I'm very satisfied with the document. BR, Haibin > -----Original Message----- > From: pierrick.seite@xxxxxxxxxxxxxxxxxx > [mailto:pierrick.seite@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, April 27, 2011 3:58 PM > To: Songhaibin; tsv-dir@xxxxxxxx > Cc: tsv-ads@xxxxxxxxxxxxxx; ietf@xxxxxxxx; > draft-ietf-mif-current-practices@xxxxxxxxxxxxxx > 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:haibin.song@xxxxxxxxxx] > > Envoyé : mercredi 27 avril 2011 05:43 > > À : tsv-dir@xxxxxxxx > > Cc : tsv-ads@xxxxxxxxxxxxxx; ietf@xxxxxxxx; draft-ietf-mif-current- > > practices@xxxxxxxxxxxxxx > > 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 tsv-dir@xxxxxxxx > > 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 Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf