Hi Haibin, Thanks for your reply. Please see my comments inline below.
On Fri, 2013-08-09 at 08:33 +0000, Songhaibin (A) wrote: > Thank you again, Carlos. Here is my feedback to you document shepherd > review. I also had an email discussion with my co-authors. > > Most of the comments are editorial and I agree on them. I copied the > comments which are not editorial with my feedback below. > > Section 2: What does "compatible" mean here? Also, depending on the > discussion we are going to have about -concepts in the WG, it might be > needed to remove this ref. > [Haibin] We will just use the word "use" instead of "compatible". We > can remove this reference to the -concepts, and will refer to the > -base document because it has definitions for terminologies we need. > Well, now that the WG has decided to resume the work on -concepts, you can keep the reference. > > Section 5.1.3: How is congestion measured? How are these 4 bits used? > This should be explained more carefullt, especially to ensure > interoperability/compatibility, as not all the nodes might > report/measure in the same way > [Haibin] I agree this is a problem. But this document is not going to > provide a measurement method for the congestion. I feel that a node > can contemplate its CPU/Memory/Bandwidth usage percentage in the past > seconds and normalize the highest value to the range [0x00, 0x0F], we > can just reserve the bits and leave it for this purpose, but it will > be defined in a future draft. > I think some adding some informative text then would help. > > Section 5.1.4, paragraph 2: Remove this part, and/or bring it to the > list to discuss what to do about it. > [Haibin] We will remove it. > OK. > > Section 5.5.2, paragraph 3: Does this spec requires clock > synchronization? (or adds more requirements on this aspect compared to > -base) Some text clarifying this issue would be helpful > [Haibin} I think here we need a decision from the WG. We need careful > consideration on how to use the timestamp because time synchronization > is a barrier in open Internet environment, while in a managed > environment, it may be less of a problem. Do we want to enforce the > time synchronization or do we want to lose a feature to check the > message expiration? We have to make a choice. Please, bring this to the ML in a separate thread and try to get feedback from WG participants, especially those with implementation experience, such as Marc. > > Section 7: I think this section is repetitive (the same content is in > 10.6). I'd remove it from here and leve it in 10.6 > [Haibin] ok. > OK, thanks, Carlos > > BR, > -Haibin > > > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:[email protected]] > Sent: Thursday, August 01, 2013 7:20 AM > To: [email protected] > Cc: [email protected] > Subject: Review of draft-ietf-p2psip-diagnostics > > Hi, > > I've performed a Document Shepherd review of draft-ietf-p2psip-diagnostics. > My review is attached to this e-mail (I added comments to the PDF version of > the draft, hope this is fine). > > I'd like authors to go through the comments before sending the document to > the IESG. There might be some issues that need to be brought to the WG for > discussion. > > Thanks, > > Carlos > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
