Re: [P2PSIP] Review of draft-ietf-p2psip-self-tuning-08

[Jouni Mäenpää <[e-mail]>]

Hi,

Thanks for the comments! We have made an attempt to address them in the new -09 revision of the draft. Answers inline.

> - Page 3. Section 1 (Introduction). Expand DHT (first time it appears on the document).

This was fixed.

> - Page 4. Section 2 (Terminology). There is a reference to draft-ietf-p2psip-concepts. 
> We'll discuss in this meeting (and follow up on the ML later) what to do with this 
> document. Depending on the decision, you might need to modify/remove this part and 
> add some other changes.

The reference to the Concepts draft was kept. But we will submit a new revision if necessary after the ML discussion on the Concepts draft has concluded.

> - Page 4. Section 2 (Terminology). I think adding some text introducing the listed terms 
> would not harm.

The explanation of the terms was expanded.

> - Page 4. Section 2 (Terminology). Some reordering of the terms might be useful. For 
> example, numBitsInNodeId can be introduced before Chord Ring. Some comment 
> about Routing Table and Successor List.

Done.

> - Page 4. Section 2 (Terminology). Not sure it is needed to explain what
> log2(N) represents.

We removed log2(N).

> - Page 16. Not sure if it is worth to explicitly mention if the result of the join_rate 
> field is a "floor" or a "ceil".

This was fixed.

> - Page 16. I'd maybe use "(log2(N))^2" instead of "log2^2(N)".

Done.

> - Security Considerations. What would happen if a node sends fake estimates? Maybe
>  we need to add some text on that.

New text on this was now added to the Security Considerations section.

> - Section 9.1. I guess RFC-AAAA refers to the number assigned to RELOAD RFC, 
> right? If so, adding a note to the RFC-Editor would not harm. 

A note to RFC-Editor was added.

> - Section 11 (References). Ref [I-D.ietf-mmusic-ice] needs to be updated with 
> RFC 5245.

Done.

> - Section 11 (References). Check consistency in the format used for the references. 
> For example, use expanded or shortened month names in all of them.

Done.

> - The nits checking tool also reports the following:
>
> "The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but 
> does not include the phrase in its RFC 2119 key words list."

This was done as well.

Regards,
Jouni

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[e-mail]] 
Sent: 29. heinäkuuta 2013 17:12
To: [e-mail]
Cc: [e-mail]
Subject: Review of draft-ietf-p2psip-self-tuning-08

Hi,

I've performed a Document Shepherd review of draft-ietf-p2psip-self-tuning-08.

I think the document is in very good shape and I'll be requesting the publication of the document later this week. I have some very minor comments that maybe can be addressed by the authors in the next revision of the document, together with any other comments you might get during the next steps in the publication process:

- Page 3. Section 1 (Introduction). Expand DHT (first time it appears on the document).

- Page 4. Section 2 (Terminology). There is a reference to draft-ietf-p2psip-concepts. We'll discuss in this meeting (and follow up on the ML later) what to do with this document. Depending on the decision, you might need to modify/remove this part and add some other changes.

- Page 4. Section 2 (Terminology). I think adding some text introducing the listed terms would not harm.

- Page 4. Section 2 (Terminology). Some reordering of the terms might be useful. For example, numBitsInNodeId can be introduced before Chord Ring. Some comment about Routing Table and Successor List.

- Page 4. Section 2 (Terminology). Not sure it is needed to explain what
log2(N) represents.

- Page 16. Not sure if it is worth to explicitly mention if the result of the join_rate field is a "floor" or a "ceil".

- Page 16. I'd maybe use "(log2(N))^2" instead of "log2^2(N)".

- Security Considerations. What would happen if a node sends fake estimates? Maybe we need to add some text on that.

- Section 9.1. I guess RFC-AAAA refers to the number assigned to RELOAD RFC, right? If so, adding a note to the RFC-Editor would not harm. 

- Section 11 (References). Ref [I-D.ietf-mmusic-ice] needs to be updated with RFC 5245.

- Section 11 (References). Check consistency in the format used for the references. For example, use expanded or shortened month names in all of them.

- The nits checking tool also reports the following:

"The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list."

Thanks,

Carlos