Re: [Gen-art] Gen-Art IETF LC review: draft-ietf-ipfix-testing-04.txt
Dear Joel, I posted a new version of the testing draft A new version of I-D, draft-ietf-ipfix-testing-05.txt has been successfuly submitted by Benoit Claise and posted to the IETF repository. Filename: draft-ietf-ipfix-testing Revision: 05 Title:Guidelines for IP Flow Information eXport (IPFIX) Testing Creation_date:2008-04-14 WG ID:ipfix Number_of_pages: 38 Abstract: This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.Conventions used in this document We hope to have addressed your concerns successfully. Would you mind checking this latest version. Note: we have addressed your point 10), as we thought we didn't want to be that formal in our test description. Regards, Benoit. I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please resolve these comments along with any other Last Call comments you may receive. Document: Guidelines for IP Flow Information eXport (IPFIX) Testing Reviewer: Joel M. Halpern Review Date: 15-Feb-2008 IETF LC End Date: 26-Feb-2008 IESG Telechat date: N/A Summary: This document needs some additional work before publication as an informational RFC. I would particularly recommend considering addressing at least the first comment below prior to RFC publication. I would also suggest that the test descriptions need some clarification as described in the technical section below, particularly items 5 and 6. Comments: Conceptual: 1) While the document is being published as an information RFC, the wording of the abstract and introduction make it seem that this document is actually defining conformance to the IPFIX RFCs. The IETF has generally carefully steered clear of defining such conformance. So, while publishing a useful test suite is probably a good idea, I strongly recommend fixing the wording of at least the abstract and introduction to make it quite clear that these are not mandatory tests, and that these tests do not define conformance. Related to this, please do not assert (in section 3) that passing this test suite constitutes conformance to the IPFIX architecture and protocol. (Among other things,test suite passage proves nothing about architectural conformance.) Technical: 2) In the terminology section, an Observation Point is defined simply as a place where packets can be observed. An Observation Domain is a collection of Observation points. Then, in the middle of the definition of an Observation domain it say In the IPFIX MEssage it generates... but up till now none of the things that have been defined generate IPFIX messages. It is possible that the it in the quote is supposed to be the Metering Process mentioned in passing earlier in the definition. But the English grammar does not lead the reader to such a conclusion. Later in that same definition, it beings to appear that an Observation Domain (which is a collection of points, not a process or entity) is supposed to generate IPFIX messages, since it is supposed to include a Domain ID in the messages it generates. This definition for an Observation Domain needs to be reworked, to avoid confusing the Domain with the Measurement Process which is running in / for / on the Domain. 3) The use of capital MUST in section 3.1 is almost certainly wrong. Firstly, what I think that section is saying is that being able to correctly perform the basic tests is a precondition for being able to perform further test successfully. Thats a precondition, not a MUST. Of lesser significance, this document does not provide any description of what it means by MUST. We are usually careful about how such language is used in informational RFCs. I think the meaning would be clearer if the real intent were stated. I suspect that some readers of this review may find my concern here pedantic. But the continual use of MUST in the document really, really bothers me. (I hope the next comment helps explain why it bothers me so much.) 4) Then, the test descriptions go on to keep using this language. This is a test suite description document. Simply state how to run the test. There is no need for MUST. Section 3 should indicate that the test descriptions describe the preconditions and
[Gen-art] Review of draft-ietf-mip6-hiopt-13
At 16 Apr 2008 12:52:00 +0300, Jari Arkko [EMAIL PROTECTED] wrote:
Alfred, thanks for your review. The stuff that you sent me seems to be
things that we need to fix. Please prepare a report and send it to
Heejin. Heejin, please wait for Alfred's fixes before you submit the -14.
Jari
Here we go.
Note 1:
As usual, change bars ('|') in column 1 and ^^^/vvv style pointer
lines are used to precisely point to dangling text or changes
proposed; they are annotation and in no way intended to become
part of the draft. Proposed text is re-`adjust`ed to RFC style.
Note #2:
Numbering of items preserved from discussion with Jari,
thus item (c) now intentionally left off below.
Note #3:
All paragraphs affected by the retrofit requested by
Jari (no MIP4, only dual-stack support) and already
modified by Heejin in the meantime are excluded from
the list below. The same holds for the other small
corrections already requested in this thread.
(a) Section 4.1, 4th paragraph
OLD:
When the mobile node sets the Id-type to 1 in the request, it MUST
include a sub-option with Sub-opt-code 1 which carries the FQDN of
the target network such as example.com. Note that a single Home
| Network Information option can carry at most one sub-option with Id-
| type 1 in the request.
^^^
NEW.1:
When the mobile node sets the Id-type to 1 in the request, it MUST
include a sub-option with Sub-opt-code 1 which carries the FQDN of
the target network such as example.com. Note that a single Home
| Network Information option can carry at most one sub-option with Sub-
| opt-code 1 in the request.
or:
NEW.2:
When the mobile node sets the Id-type to 1 in the request, it MUST
include a sub-option with Sub-opt-code 1 which carries the FQDN of
the target network such as example.com. Note that a single Home
| Network Information option can carry at most one sub-option with Sub-
| opt-code 1.
^^^
RATIONALE:
Sub-options do not have an Id-type of their own.
The 6th paragraph of 4.1 and Section 4.3 clearly admit multiple
Home Network Information options in the request with Id-type 1,
but different Home Network Identifiers (target MSPs) in their
(single) sub-option of Sub-opt-type 1. Therefore,
Sub-opt-code should be substituted there for Id-Type.
But the modified last sentence -- per NEW.1 -- equally holds for
the response, if I truly understand the intent of the draft.
Thus, it apparently makes sense to also suppress the trailing
in the request, as done in NEW.2.
Related PRO/CON considerations:
- The mobile node cannot enforce this condition in the response.
- The 8th paragraph already requests that the MN ignore a HNINF
option with Id-type 1 in the reply which does not contain a
home network identifier (Sub-opt-type 1) sub-option.
I recommend NEW.2, but also have no objections to using NEW.1,
if you have arguments in preference of that.
(Jari also has indicated leaving the choice to the authors.)
(b) Section 4.1, 5th paragraph
OLD:
The mobile node MUST NOT include a Home Network Information option
whose Id-type is other than 0, 1, and 2 as defined as Section 3.1. A
| value of 1 is only available Sub-opt-code in the request.
^
SYMPTOM:
The last sentence is ambiguous.
Does A value of 1 refer to the Id-type or to the Sub-opt-code?
Hence, does it mean:
[...]
| A value of 1 is the only Sub-opt-available code in the request.
^
or:
[...]
| In the Request, only a Home Network Information option whose Id-type
| is 1 can carry a sub-option, and this sub-option must have Sub-opt-
| code 1.
DISCUSSION:
In any case, I suggest to separate the clarified sentence from the
preceding one by a paragraph break (blank line), to better decouple
it from the preceding statement that is only related to the Id-type.
Thus, the two alternatives above result in the two proposals (below).
I'd prefer (NEW.1) over (NEW.2) because the latter restates
requirements already expressed in preceding parts of the text
and thus would add redunduncy to the text.
(Jari also has indicated leaving the choice to the authors.)
NEW.1:
The mobile node MUST NOT include a Home Network Information option
| whose Id-type is other than 0, 1, and 2 as defined as Section 3.1.
|
| A value of 1 is the only Sub-opt-code available in the request.
or:
NEW.2:
The mobile node MUST NOT include a Home Network Information option
| whose Id-type is other than 0, 1, and 2 as defined as Section 3.1.
|
| In the Request, only a Home Network Information option whose Id-type
| is 1 can carry a sub-option, and this sub-option must have Sub-opt-
| code 1.
(d) Section 4.1, 2nd-to-last paragraph
OLD:
As described later in Section 4.3, servers attempt to
Re: [Gen-art] [lemonade] Gen-ART review of draft-ietf-lemonade-convert-17.txt
[EMAIL PROTECTED] wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lemonade-convert-17.txt Reviewer: David L. Black Review Date: 15 April 2008 IETF LC End Date: 16 April 2008 Hi David, Thank you for your review. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This is a generally well-written draft on the CONVERT extension to IMAP. All of these comments are minor nits. In Section 2, please remove this convention: [[anchor3: Editorial comments and questions are marked like this.]] Done. p.10 contains a couple of example email addresses. Please use example.com, example.net or example.org as the domain. Somebody else complained about this earlier, so I've already fixed this in my copy. In Section 11.1 are the To: and Subject: lines needed as part of the IANA registration? If not, please remove them. They are a part of the IANA template in RFC 2506, so I would rather keep them In the IANA registration in Section 11.1, please ask IANA to replace RFC by the RFC number assigned to this draft. Ok. idnits 2.08.05 got confused by the square brackets used in IMAP syntax and reported a number of potential reference problems - there are no actual problems. Indeed. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-nfsv4-nfsdirect-07.txt
At 11:57 AM 3/21/2008, Francis Dupont wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft ... Editorial: - 3 page 3, etc: about the case of read/write: operations should get all uppercase, list only the first letter and other all lowercase. In term of grammar: nouns are in all uppercase, adjective one uppercase, verb all lowercase. Applying this: ... 4 page 5: RDMA READs and RDMA READ ... I have incorporated almost all of your comments, but felt I should indicate why I did not take just one in particular. The terms RDMA Read and RDMA Write are used consistently with these letter cases throughout RFC5040 and other documents, so it seems best to retain their style here. Your observation did lead me to fix a couple of other inconsistencies, however! Thanks for the careful review. Acknowledgment being spelled inconsistently was a particular surprise! :-) Tom. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
