Hi Alvaro, Thanks. And agree with the suggested text and place for it.
Best Regards! -Haibin > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:[email protected]] > Sent: Friday, February 26, 2016 12:12 AM > To: Songhaibin (A); Alissa Cooper > Cc: Roni Even; [email protected]; [email protected]; > IESG; [email protected]; Barry Leiba > Subject: Re: [P2PSIP] Barry Leiba's Discuss on > draft-ietf-p2psip-diagnostics-19: > (with DISCUSS and COMMENT) > > On 2/24/16, 10:10 PM, "iesg on behalf of Songhaibin (A)" > <[email protected] on behalf of [email protected]> wrote: > > Haibin: > > > Hi! > > >I did the editing job and have submitted a new version of the document > >according to the comments received and the discussion in the list. I > >also add some text in the change history appendix for it. Please check > >if the updated version has addressed your comments. > > > >https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 > > I think that the text added in 4.3 maybe needs a little word-smithing (see > below > for a suggestion), and I think it should be in a more prominent place (I > suggest > 4.1) because the issue is not specific to Path_Track. > Otherwise I think it's ok. > > >I keep the intended status of the document as it is. Alvaro thought > >Experimental might be a better status, when I check the change history > >in the document, as it is defined as a mandatory RELOAD extension, the > >current intended status seems suitable. Otherwise we need go through > >another WGLC to change the intended status. > > I don't think a new WGLC would be needed (or IETF LC for that matter) since it > was already approved at a "higher" maturity level. I also don't think we need > to belabor this point much longer. > > I will clear my DISCUSS. > > Thanks! > > Alvaro. > > > Suggested text update: > > OLD> > One important thing is that, this document does not guarantee what it > conveys must be the information that caused the previous failures, > but with the retrieved information from the previous traversed nodes > (with high probability they are, as it cannot guarantee the exact > same path), a user or machine can analyze and infer what is the > problem. Symmetric routing is achieved by the Via List as defined in > [RFC6940] (whatever DHT routing algorithms are used), but response > message could go through not exactly the same path as there still can > be node failures during that very short period. And there can also > be lack of accurate path informaiton of the previously failed > message. > > > NEW> > It is important to note that the mechanisms described in this document > do not guarantee that the information collected is in fact related to > the previous failures. However, using the information from previous > traversed nodes, the user (or management system) may be able to infer > the problem. Symmetric routing can be achieved by using the Via List > [RFC6940] (or an alternate DHT routing algorithm), but the response > path is not guaranteed to be the same. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
