[Gen-art] Genart review of draft-ietf-tcpm-experimental-options-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-experimental-options-03.txt Reviewer: Christer Holmberg Review Date: 14 December 2012 IETF LC End Date: 13 December 2012 IESG Telechat date: 20 December 2012 Summary: The draft is ready for publication, without any comments. Major issues: - Minor issues: - Nits/editorial comments: - Regards, Christer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART: Re-review of draft-ietf-p2psip-base-23
Russ asked that I re-review the updated document. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-p2psip-base-23 Reviewer: Mary Barnes Review Date: 14 December 2012 Re-Review started Date (-21): 28 March 2012 (was told a new version was coming out) Original Review Date (-17) : 6 August 2011 IETF LC End Date: 22 July 2011 Summary: Not Ready. I reviewed through section 6 of this version (section 5 of -17) against my comments on the -17 . Since many of my comments had not been addressed, I'm not going to take the time to re-review the remainder of the document. I also *strongly* recommend that you ensure Henning has reviewed this document *before* it gets into the RFC editor's queue. He has fairly strict (and quite accurate) views on grammar and structure but it really isn't good to have so many changes go in at AUTH48 as there is a risk of introducing true technical bugs or changing something that was carefully crafted to achieve WG consensus: http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html Comments: = I have reviewed my previous comments on this document -17 as compared to the -23. Comments from the -17 that remain are prefaced with [-17] Major: -- General: --[-17] The message names are used inconsistently. The IANA registry has the message codes all lower case. There are places in the examples and the body of the document where the _req part is missing, there is no _, the first letters are Upper case, etc. The messages are also used in a general sense - e.g., MUST perform an Attach, which should really be stated as MUST send an attach_req message). [-23] For the latter point, Cullen responded that this isn't really just talking about sending a message but rather performing a function that results in a message being sent. However, I still contend that there is inconsistency and the whole concept of an Attach function/process/whatever is not well defined. There are times when attached appears to be used purely as a verb rather than referring to the functionality, but it is not always clear. For example, the last two sentences in section 3.4: Instead, we use the Attach request to establish a connection. Attach uses ICE [RFC5245] to establish the connection. It is assumed that the reader is familiar with ICE. I will note that the only mention of Attach previously was in the definitions for Connection Table (Attach handshakes) and Routing Table (some peers will have Attached). The word Attach is used with the _req or the word request in places like the following in section 3.4 (1st sentence): There are two cases where Attach is not used. I have no idea really whether this means this Attach function/process is not needed or the message is not required to be sent. Major - detailed: - Section 3.4, last paragraph: Accepting Cullen's comment that this text is not normative, I'll let my first set of -17 comments on this one go. However, the following is still not clear to me: What is meant by the specified link set - is that referring to all the nearby peers or the peers+enough others? Or is this more clearly (and normatively) specified elsewhere, such that a reference could be added. - [-17 5.1.2] Section 6.1.2: -- Last paragraph (9) mixes normative text with in an example. The normative text needs to be separated from the example - e.g., split some of the sentences into the normative behavior and then the example. The example should be written in terms of what happens (which is what was done in the previous examples in this section and not what SHOULD, MAY or MUST happen). For example, this sentence: Node A MUST implement an algorithm that ensures that A returns a response to this request to node B with the destination list [B, Z, Y, X], provided that the node to which A forwards the request follows the same contract. should have a generic normative statement rather than saying Node A MUST. It should be something like: A node must implement an algorithm that ensures it returns a response …, then the same sentence can be a For example, Node A MUST… - [-17 5.3.2.1] Section 6.3.2.1: --1st paragraph: shouldn't this be normative? the configuration document has a sequence number... - the configuration document MUST contain a sequence number which MUST be monotonically increasing mod 65535 - [-17 5.3.2.2] -Section 6.3.2.2: --Paragraph after second structure, suggest the following changes: ---the generation counters should - the generation counters SHOULD ---An implementation could use.. - An implementation MAY use… ---the node confirms that the generation counter matches - the node MUST confirm that the generation counter matches ---If it does not match, it is silently dropped. - If it does not match, it MUST be silently dropped. - [-17 5.3.3.1] Section 6.3.3.1: --1st para: a request returns - a request MUST
Re: [Gen-art] Assignments for the 2012-12-20 telechat
Hi all, The following new documents have been added to the agenda: Ben Campbell draft-ietf-karp-routing-tcp-analysis-06 * Elwyn Davies draft-ietf-sidr-usecases-05 Thanks, Jean On 12/13/12 5:39 PM, A. Jean Mahoney wrote: Hi all, The following reviewers have assignments: Reviewer LC end Draft Alexey Melnikov 2012-11-12 draft-ietf-mmusic-sdp-media-capabilities-16 * Christer Holmberg2012-12-13 draft-ietf-tcpm-experimental-options-03 Francis Dupont 2012-12-17 draft-ietf-sipclf-format-09 Joel Halpern 2012-12-17 draft-ietf-sipclf-problem-statement-11 ** Miguel Garcia2012-10-22 draft-ietf-fecframe-simple-rs-05 * Peter Yee2012-12-11 draft-ietf-avt-rtp-evrc-nw-09 * * Earlier draft reviewed ** Already reviewed I have made the assignments in the review tool: http://art.tools.ietf.org/tools/art/genart/ However, assignment spreadsheets are not available due to WebDAV issues. For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://wiki.tools.ietf.org/area/gen/trac/wiki/ Jean --- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review: draft-ietf-mboned-auto-multicast-14
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-mboned-auto-multicast-14 Reviewer: Mary Barnes Review Date: 14 Dec 2012 IETF LC End Date: 19 Dec 2012 Summary: Ready with comment/nits. Minor comments: References: - There is a normative downref to RFC 1321. Does this need to be a normative reference? Note, I could not find the shepherd write-up in the tracker to see if this had been noted and explained. Nits: - IDNITS identifies the following: - there are 15 instances of two long of lines - there is an obsolete reference to RFC 2236 (Obsoleted by RFC 3376) - there are a number of unused references that can likely be removed. - General: please add #s to all the figures - Section 4.1.3, 1st sentence: shouldn't relay services gateways be relay services gateway - Appendix A.1, 2nd paragraph: Section Section 5.3.6 - Section 5.3.6 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART: Re-review of draft-ietf-p2psip-base-23
Hi Mary, thanks for your review. I am adding Dean to this thread since he is currently editing the document. Cheers, Gonzalo On 14/12/2012 8:02 PM, Mary Barnes wrote: Russ asked that I re-review the updated document. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-p2psip-base-23 Reviewer: Mary Barnes Review Date: 14 December 2012 Re-Review started Date (-21): 28 March 2012 (was told a new version was coming out) Original Review Date (-17) : 6 August 2011 IETF LC End Date: 22 July 2011 Summary: Not Ready. I reviewed through section 6 of this version (section 5 of -17) against my comments on the -17 . Since many of my comments had not been addressed, I'm not going to take the time to re-review the remainder of the document. I also *strongly* recommend that you ensure Henning has reviewed this document *before* it gets into the RFC editor's queue. He has fairly strict (and quite accurate) views on grammar and structure but it really isn't good to have so many changes go in at AUTH48 as there is a risk of introducing true technical bugs or changing something that was carefully crafted to achieve WG consensus: http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html Comments: = I have reviewed my previous comments on this document -17 as compared to the -23. Comments from the -17 that remain are prefaced with [-17] Major: -- General: --[-17] The message names are used inconsistently. The IANA registry has the message codes all lower case. There are places in the examples and the body of the document where the _req part is missing, there is no _, the first letters are Upper case, etc. The messages are also used in a general sense - e.g., MUST perform an Attach, which should really be stated as MUST send an attach_req message). [-23] For the latter point, Cullen responded that this isn't really just talking about sending a message but rather performing a function that results in a message being sent. However, I still contend that there is inconsistency and the whole concept of an Attach function/process/whatever is not well defined. There are times when attached appears to be used purely as a verb rather than referring to the functionality, but it is not always clear. For example, the last two sentences in section 3.4: Instead, we use the Attach request to establish a connection. Attach uses ICE [RFC5245] to establish the connection. It is assumed that the reader is familiar with ICE. I will note that the only mention of Attach previously was in the definitions for Connection Table (Attach handshakes) and Routing Table (some peers will have Attached). The word Attach is used with the _req or the word request in places like the following in section 3.4 (1st sentence): There are two cases where Attach is not used. I have no idea really whether this means this Attach function/process is not needed or the message is not required to be sent. Major - detailed: - Section 3.4, last paragraph: Accepting Cullen's comment that this text is not normative, I'll let my first set of -17 comments on this one go. However, the following is still not clear to me: What is meant by the specified link set - is that referring to all the nearby peers or the peers+enough others? Or is this more clearly (and normatively) specified elsewhere, such that a reference could be added. - [-17 5.1.2] Section 6.1.2: -- Last paragraph (9) mixes normative text with in an example. The normative text needs to be separated from the example - e.g., split some of the sentences into the normative behavior and then the example. The example should be written in terms of what happens (which is what was done in the previous examples in this section and not what SHOULD, MAY or MUST happen). For example, this sentence: Node A MUST implement an algorithm that ensures that A returns a response to this request to node B with the destination list [B, Z, Y, X], provided that the node to which A forwards the request follows the same contract. should have a generic normative statement rather than saying Node A MUST. It should be something like: A node must implement an algorithm that ensures it returns a response …, then the same sentence can be a For example, Node A MUST… - [-17 5.3.2.1] Section 6.3.2.1: --1st paragraph: shouldn't this be normative? the configuration document has a sequence number... - the configuration document MUST contain a sequence number which MUST be monotonically increasing mod 65535 - [-17 5.3.2.2] -Section 6.3.2.2: --Paragraph after second structure, suggest the following changes: ---the generation counters should - the generation counters SHOULD ---An implementation could use.. - An implementation MAY use… ---the node confirms that the
