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