[Gen-art] review of draft-kornijenko-ivis-urn-00.txt
Summary: basically ready with nits I strongly recommend to convert the document to a tool like xml2rfc before to send it to the RFC editor! Other concerns: - the document should specify which kind of namespace registration is asked for (I've assume formal) - so there must be an IANA consideration asking for the registration - and compliance to RFC 3406 should be more evident (i.e., stressed) - note that I am not in urn-nid ML so I don't know if this step of the procedure was done nor if there were interesting comments... (I've checked the urn-nid archive, the procedure was followed in a burial silence (:-), only Leslie Daigle helped the author) - 2.2 page 2: the declared registrant should be an organization and the human the contact person for obvius stability reasons - 2.22 page 3: un - and - Acknowledgments page 5: there is only one author who should not be acknowledged (:-) - 7.1 page 5: perhaps the RFC 2141 should be referenced - 7.2 [3] page 5: misplaced closing - 7.2 [7] page 5: where are the acknowlegdments to see? Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-avt-rtp-eac3-01.txt
I am the assigned Gen-ART reviewer for draft-FOOBAR.txt. For background on Gen-ART, please see the FAQ at 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. Summary: ready Thanks [EMAIL PROTECTED] PS: the RFC editor should be warned he will have to update the self references (RFC ) in section 5.1. It should be fine to have a standard way to do this, IMHO it is too easy to miss this kind of things... ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dnsext-mdns-46.txt
I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt. For background on Gen-ART, please see the FAQ at 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. Summary: Ready with nits Some comments/suggestions (including a required fix for 5.3 [b]): - 2.1 page 5: the 512 octets default maximum seems a bit too conservative? - 2.1.1 C page 6: request - query (IMHO the document should use only the pair of terms query/response) - 2.9 page 14: check if SIG(0) is not now RSIG(0) (PS: as far as I know the RFC 2931 was not updated so it is still SIG(0)) - 3.1 pages 17 and 18: linklocal - link-local (twice) - 4.1 page 19: I am not happy with interpreted as an unsigned integer as this involves an ambiguous byte order (I assume it is big endian but it is not specified). I strongly prefer the lexicographical order. - 4.2 page 20: same than the previous point. - 4.2 page 21: requests - queries, and replies - responses - 5 page 22: 802.11 - IEEE 802.11 - 5.1 page 23: silently discarding them as rapidly as possible - silently discarding them (I don't know a way to slowly discard them :-) - 5.2 page 23: link layer security - link-layer security (the link-xxx style seems fine) - 5.2 page 23: local-link - local link - 5.3 [a] page 24: same than 2.9 - 5.3 [b] page 24: IPsec ESP has two NULL algorithms, NULL encryption and NULL integrity/authentication (cf RFC 4305, the term transform comes from RFC 4306 but algorithm is better). I strongly suggest: null-transform - NULL encryption algorithm. - 6 page 25: my dictionary has no coincident, in particular in this position... (i.e., there is a possible wording/language problem) - 8.2 pages 26/27: many informative references are for 2002 I-Ds, perhaps this can become a problem? - Acks page 28: Van-Valkenburg - van Valkenburg? (please check with him) - Open Issues page 30: should be marked as to be removed by the RFC editor. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-dnsext-mdns-46.txt
In your previous mail you wrote: I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt. For background on Gen-ART, please see the FAQ at 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. = hum, it seems the right boilerplate finishes by: Please wait for direction from your document shepherd or AD before posting a new version of the draft. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-rddp-ddp-06.txt
I am the assigned Gen-ART reviewer for draft-ietf-rddp-ddp-06.txt. For background on Gen-ART, please see the FAQ at 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. Summary: not Ready I have two main concerns: - section 1.1 Architectural Goals is not understable. - section 8.4.2 Requirements for IPsec Services for DDP refers to an obsolete version of IPsec. For the second point I suggest to contact the IESG to know what should be required (keep IKEv1 text, add some IKEv2 text, move to IKEv2). Detailed comments: - 1.1 page 4: this ection is far too hard to understand. IMHO the source of the problem is the use of the terms Local/Remote Peer when nearly everywhere we have Data Source/Sink. As DDP is an one way protocol (at the opposite of RDMAP for instance) I strongly suggest to simply use only Data Source/Sink. - 1.1 page 4 and many other places: i.e. and e.g. take a ',' just after (only 8.4.2 page 31 has this right). - 1.1 page 4: the LLP abbrev is used before being defined (in page 6). - 1.3 page 6: the RDMAP abbrev is never defined. - 1.3 figure 2 page 8: I suggest to add some // and lines to the payload to show it is the large field. - 2.1 pages 9/10: I suggest to remove Local/Remote Peers. - 2.1 page 9: RNIC is used before being defined (I suggest to add a reference to the section). - 2.1 page 10: OS - Operating System (there are already too many abbrevs). - 3 6. page 13: semantics require - semantics requires? - 3 8. page 13: stream - Stream (i.e., uniformize the case) - 5.1.1 page 19: bad wording (I suggest to remove the statement An STag identifies... as the next one explains the same thing). - 6.2.1 page 23: I suggest to replace Local/Remote Peers by Data Source/Sink. - 6.2.2 page 24: I don't like the term catastrophic, is fatal or unrecoverable still possible alternatives? (same 7.2 page 26) - 7.1 page 26: it seems the 5. is already included in the 4., what have I missed? - 8.4.2 pages 31...: the idea to follow the RFC 3723 is good, the problem is this RFC is a bit old. - 8.4.2 1. page 31: there is only one replay protection mechanism in IPsec and this service is offered by ESP. - 8.4.2 1. page 31: RFC2406 - RFC4303. - 8.4.2 3. page 31: RFC2409 - RFC4306 and remove the DOI. - 8.4.2 4. page 4: strictly speaking deletes are informational exchanges, not phase 2 (aka. quick mode). BTW there is no such IKE Phase 2 SAs, IMHO you mean IPsec SAs. - 8.4.2 5. and 6.: I strongly suggest to update the text to IKEv2. - 10.1/2 page 34: RFC 240x - RFC 430y. - 11.1 page 36: size need - size needs. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-rddp-rdmap-06.txt
I am the assigned Gen-ART reviewer for draft-ietf-rddp-rdmap-06.txt. For background on Gen-ART, please see the FAQ at 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. Summary: not Ready I have the same concern than for the companion I-D about DDP: the IPsec part (8.2.2) refers to an obsolete version of IPsec/IKE. Detailed comments: - i.e. - i.e., and e.g. - e.g., - 1.2 page 7: With - with - 1.3 figure 2 page 11: I suggest to add // and lines to the payload. - 3.2 page 26: what is the yesSTag (IMHO there is a typo)? - 4.1 page 28: what are IETF RNICs and RDMA RNICs (and for the second the R in RNIC stands for RDMA, doesn't it)? - 4.4 pages 32/33: the title RDMA Read Message Size is very ambiguous (i.e., the common meaning is not the intented one). - 4.8 figure 9 page 37: the Nones for Local Catastrophic Error doesn't specify what to put in the (BTW not optional) fields. - 5.4 page 46: the DDP layer mark - marks? - 5.5 20. page 50: more than one ... is - are? (same 7.1 24. page 55) - 7.1 21. page 55: Errors - errors. - 7.1 24. page 55: the rules 2 and 3 above are really 2 and 3 of 5.5? Or are they 22 and 23? - 8.1.1 8. page 58: range available - available range. - 8.2.1 page 60: RFC2401 - RFC4301 and IPsec an guarantee anti-replay, not sequencing. - 8.2.2 page 61...: look at my comments about DDP I-D. - 8.2.2 7. page 62: I disagree with the recommendation. I suggest to cite directly the draft-ietf-pki4ipsec-ikecert-profile-10.txt document than to overload the CERTREQ payload which as its name suggest requests that the peer sends a CERT payload through IKE... - 10.1/2 page 65: RFC240x - RFC430y. - 10.2 page 66: RFC2246 - RFC4346 (and TLS 1.0 - 1.1). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sieve-spamtestbis-05.txt
I am the assigned Gen-ART reviewer for draft-ietf-sieve-spamtestbis-05.txt. For background on Gen-ART, please see the FAQ at 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. Summary: Ready Two suggestions: - in 1 page 4: e.g. - e.g., - in 4 page 11: IHMO unknown content and origin is a bit weak, I'd prefer something like unknown content or untrusted origin? Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-rddp-ddp-06.txt
In your previous mail you wrote: As you suggested, I did contact the IESG, specifically the Security ADs, about IKEv1 vs. IKEv2, and the verdict is to stick with IKEv1 as profiled by RFC 3723 for iSCSI so that iSCSI and RDDP use the same profile of IPsec. If/when RFC 3723 is updated, all the protocols that use it will be uniformly affected. Text will be added to the next version of the draft to explain this. = IMHO this is a good solution... Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-fec-grouping-05.txt
For IETF Last Call reviews: I am the assigned Gen-ART reviewer for draft-ietf-mmusic-fec-grouping-05.txt. For background on Gen-ART, please see the FAQ at 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. Summary: Ready with nits In fact all my comments are about the same thing: reference [5]: - in 3 page 3 I suggest to add (RFC ) (as it is done in 4.1 page 3) - in 3 page 3 and in 9.2 page 5 I believe it is RTP in place of RFC (again 4.1 page 3 seems right) - I'd like to get the name of the I-D in 9.2 page 5, BTW it seems to be draft-ietf-avt-ulp-18.txt - IMHO the right place of this is in normative references, not informative (I can't see how the document can be applied without a FEC document and [5] is the only proposed one, to summary the two normative depencies should be grouping (RFC 3388) [2] and fec (RFC ) [5]) Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dnsext-dnssec-experiments-03.txt
I am the assigned Gen-ART reviewer for draft-ietf-dnsext-dnssec-experiments-03.txt For background on Gen-ART, please see the FAQ at 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. Summary: Ready Minor points (they should be fixed by the RFC Editor): - in 1 page 3: a missing closing parenthesis. I suggest to add the number of the RFCs too. - is validatable (in 4 page 7 and 6 page 9) a correct English word? - in 10.2 page 13 reference [6] is obsolete: a new version 03 was submitted in June. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] summary of draft-ietf-tsvwg-quickstart-06.txt review
About draft-ietf-tsvwg-quickstart-06.txt, the summary will be: Not Ready There is no real problem (yet :-) with the document but my comments won't be fixed without some editing... Of course, I'll try to send comments (at least the first comments) ASAP, and including to the authors. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART LC review of draft-ietf-tsvwg-quickstart-06.txt
Thanks, I'll be happy to read the new version as soon as it'll be available. [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART LC review of draft-ietf-tsvwg-quickstart-06.txt
In your previous mail you wrote: We have one detail still to address from your review, and that is to add a citation about deleting IP options being forbidden, or supposed to be forbidden, for IPv6. Do you have a citation to suggest for that? = there is nothing very clear about this (RFC 2460 uses the loose terms examine and process). I have still the strong opinion it is an important part in the design of IPv6 (*) but I am afraid we have to ask the list(s) to get something concrete to cite... Regards [EMAIL PROTECTED] PS (*): examples are source fragmentation and mobile IPv6 (at the opposite of IPv4 en route fragmentation and rejected proposals for mobility with home agent header injection/removal). ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-behave-multicast-03.txt
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-behave-multicast-03.txt Reviewer: Francis Dupont Review Date: 3 oct 2006 IETF LC Date: 2 oct 2006 IESG Telechat date: not known yet Summary: Ready Comments: I have two very minor suggestions: - 2.1 page 4: in as if it was a host was - is (or were)? (I propose to let the RFC editor decide) - some lines after, I believe the fact This document is a companion document to NAT Behavioral Requirements for Unicast UDP [I-D.ietf-behave-nat-udp]. should be exposed as soon as possible, i.e., in the introduction (section 2), for instance between NAT/NAPT (first paragraph) and PIM/IGMP (second paragraph). BTW this can be done in the behave-nat-udp draft itself, for instance in its applicability statement (just another change). I don't believe to add an informative reference from it to this document would be a problem. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART LC review of draft-ietf-tsvwg-quickstart-06.txt
In your previous mail you wrote: I just submitted a revised version of the draft, and put a copy at: http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-07.txt Let me know what you think. After you are done, then we can think about who to ask to read it from the ipv6 community... = fine, I believe we can move the summary to Ready with nits (the nit is the IPv6 part but unfortunately we can't directly solve it as we rely on the IPv6 community). Thanks [EMAIL PROTECTED] PS: IMHO the simplest way is to send a message to IPv6 and v6ps WG chairs. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART LC review of draft-ietf-tsvwg-quickstart-06.txt
In your previous mail you wrote: I have not included anything about deleting IP options being forbidden in IPv6. It seems sufficient to me just to have the document say that the router, when it denies a Quick-Start request, SHOULD either delete the option or zero the relevant fields in the Quick-Start option. = if someone from the IPv6 community has something to add we'll give the opportunity to do it. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-isis-caps-06.txt
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-isis-caps-06.txt Reviewer: Francis Dupont Review Date: 27 october 2006 IETF LC Date: 19 october 2006 IESG Telechat date: (if known) Summary: Ready with nits Comments: there are some little details which should be fixed (nothing critical and nothing which cannot be fixed by the RFC editor) : - 1 page 2: I know what is IS-IS but a random reader likely doesn't: add a reference to the ISO IS (i.e., [IS-IS]) in the first sentence. (and perhaps add IS-IS-IP too, cf last comment). - 1 page 2: two examples numbered from 1 to 3 (:-)! - 2 page 3: I don't understand the to prevent TLV looping but perhaps it is not TLV looping? - 3 page 3: I don't like the term domain flooding scope, it seems a bit redundant to me. - 3 page 4: stale capabilities information A system ^^ , a ? - 9.1 page 6: is ISIS-TE really a normative reference? BTW there is no reference in the text (same for the previous item, there is a nice checker for this: I suggest to use it...) Regards [EMAIL PROTECTED] PS: the list of authors doesn't match the list of editors, I expect you looked at the detailed instructions about this in the RFC editor documents. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] last reviews
I have some unfilled reports in gen-art-by-reviewer.html: - draft-ietf-isis-caps-06.txt: done after the last update (summary: Ready with nits) - draft-ietf-behave-multicast-03.txt: summary: Ready - draft-ietf-rddp-rdmap-07.txt: updated after the review, the main issue, reference to the old version of IPsec/IKE, should be solved by the update of RFC 3723, so there is no blocking point (i.e., summary: Ready). - draft-ietf-rddp-ddp-07.txt: same than for rddp-rdmap even I still don't like the used terminology which could be far simpler for rddp-ddp... Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-nemo-terminology-06.txt
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-nemo-terminology-06.txt Reviewer: Francis Dupont Review Date: 2006/12/1 IETF LC End Date: IESG Telechat date: 2006/11/30 Summary: Ready with nits Comments: I have many comments about language/wording, some have a technical impact but none is really critical: - in 1 page 4, 3.2 page 10, 4 page 11 (twice), 5.1 page 13 (twice), 5.2 page 13: e.g. or i.e. are not followed by a comma. - in 2 page 5, page 6 (twice), 2.1 page 7, 2.2 page 7 (twice), 6.8 page 18: the word subnetwork should be used in place of subnet in text (I propose to keep the abbrev in figures but to use the full term in text). - in 2 page 6 (technical): from the Access Router - from an Access Router. - in 2 page 6, 2.3 page 7 (always twice): IMHO one or more introduces a plural (ask the RFC editor to fix this). - in 2.8 page 8 (technical): the wording seems to exclude CNs which are on the same mobile network (!= fixed or *another* mobile). Is it the intention? - in 3 page 9: some sort - some kind? - in 3* pages 9 and 10: LFN, VMN and LMN are a partition of MNN. IMHO the wording should be a bit clearer, for instance with an either .. or construct? - in 4.1 page 11 (technical): there is no reason that the topology is a tree so the wording must be changed in order to explain how we can get a hierarchy from any interconnection graph. For this point IMHO the magic words are spanning tree with the Internet as the root but things can be more complex about the prefix delegation and/or with multi-homing. - in 4.4/4.7 pages 11/12: the opposite of parent is child, not subservient. Is there a good reason to avoid child-NEMO/child-MR terms? - in 5.1 page 13, 5.3 page 14, 5.4 page 14: either is for exclusive or and is used in situations where a standard inclusive or is better. - in 7.4 page 19: the word necessary is far too strong and surely not necessary... - in authors' addresses page 25: please use the French (and only correct in these cases) position for the postal code (aka zip code) which is supposed to have only a local (here pour nous) meaning. Not my comment: in 2.10 page 8: the abbrev CE (Correspondent Entity) collides with already heavily used CE (Customer Equipment). CNR was proposed (cf. IESG evaluation comment logs in the tracker). Regards [EMAIL PROTECTED] PS: as the document is informational I don't know if a LC is planned for it. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: review of draft-ietf-nemo-terminology-06.txt
In your previous mail you wrote: The definitions reads: 2.8. Correspondent Node (CN) Any node that is communicating with one or more MNNs. A CN could be either located within a fixed network or within another mobile network, and could be either fixed or mobile. So, we should just replace the word another with a in front of mobile network. = fine. - in 3 page 9: some sort - some kind? - in 3* pages 9 and 10: LFN, VMN and LMN are a partition of MNN. IMHO the wording should be a bit clearer, for instance with an either .. or construct? Would you clarify which is the sentence that should be clarified ? Please also not that the term MNN: is defined in 2.7, so that definition by itself might be enough to clarify your concern ? = hum, IMHO the best is to add an either before VMN in 2.7, i.e., put A Mobile Network Node may either be a fixed node (LFN) or a mobile node (either VMN or LMN). ^^ - in 4.1 page 11 (technical): there is no reason that the topology is a tree so the wording must be changed in order to explain how we can get a hierarchy from any interconnection graph. For this point IMHO the magic words are spanning tree with the Internet as the root but things can be more complex about the prefix delegation and/or with multi-homing. The reason why this could become a tree is that the visiting MR must obtain an address on the parent NEMO. ^^^ = the issue is about this the: I have no concern to have a constraint on considered topologies but this should be explicitely stated. However, the child NEMO can also be a parent NEMO over another path (says that a MNN in a sub-NEMO is an AR adversiting a prefix, so the MR from the parent-NEMO may get an address from the sub-NEMO. So, nested topologies could become very complex, and would bring some interesting issues. This could bring loops, but it is not the intention to discuss this in this document. I'm not sure the term spanning tree would fit in here. = spanning tree is the standard way to extract a tree from a random graph. - in 5.1 page 13, 5.3 page 14, 5.4 page 14: either is for exclusive or and is used in situations where a standard inclusive or is better. OK, we should just remove the word either if in English it has a definite exclusive meaning (I leave that to the RFC editor, then). = I agree: arguable language points should be handled by the RFC editor! - in 7.4 page 19: the word necessary is far too strong and surely not necessary... Well, from a usage and deployment point of view, everyone agree that optimizations are necessary. The reason why the solution is not optimzed yet is security as you know. So, optimizations are necessary from a performance point of view, but it's not clear yet if this would compromise security, in which case optimizations may not be provided. Anyway, I propose to change necessary with performance. = fine. - in authors' addresses page 25: please use the French (and only correct in these cases) position for the postal code (aka zip code) which is supposed to have only a local (here pour nous) meaning. This is an xml issue. The RFC editor will make sure that the address is 78153 Le Chesnay and not the other way round. = IMHO code should not be used for French postal addresses... (I use the city for the whole line) Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] (re)review of draft-ietf-rohc-rfc3095bis-framework-04.txt
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-rohc-rfc3095bis-framework-04.txt Reviewer: Francis Dupont Review Date: 2006-12-08 IETF LC End Date: 2006-11-28 IESG Telechat date: 2006-12-14 Summary: Ready Comments: none (it is a rereview of a document which was already ready). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-smime-escertid-04.txt
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-smime-escertid-04.txt Reviewer: Francis Dupont Review Date: 2007-01-30 IETF LC End Date: 2007-01-31 IESG Telechat date: 2007-02-02? Summary: Not Ready Comments: - a security consideration section is mandatory. - the introduction fails to explain how the hash is used even the idea is very simple (identify without ambiguity a certificate by its hash). - and its fails too to explain the choices. - 1 page 3: the text is painful to read. - 1 page 3 ESSCertID - ESSCertID, - why the version 2 is described before the version 1? - 2 page 4: the text is painful. - 2 page 4: SHA-1 able - SHA-1 to be able - 2 page 4: I.e. - I.e., - 3 and 5: why the authorization certificates became the certificates? - 3 and 5: what are the real differences between 3 and 5 texts? Is it possible to factorize them in order to make common and different parts easy to find? - 3 page 6: asserts apply - asserts to apply - 3 page 6: SigningCertificate - SigningCertificateV2 or perhaps you mean SigningCertificateV1 or SigningCertificateV2. I suggest to introduce SigningCertificate as the or of the two versions. - 4 page 8: choose between hashAlg and hashAlgorithm - 4 page 8: e.g. - e.g., - 4 page 8: I don't like the definition of issuer even it is copied from RFC 2634. For instance GeneralNames is not GeneralName, and the consequences must be drawn/explained... - 5 pages 9 and 10: what are the differences with RFC 2634 and why? - 7 page 12: PKIXCERT and RFC3280 are the same document! - I didn't check the ASN.1 (seems OK according to a diff with RFC's one). Is there a recommended tool? I know there is one for MIBs. - Author page 18: USA in the address, +1 in the phone number. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-mcwalter-uri-mib-02.txt
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-mcwalter-uri-mib-02.txt Reviewer: Francis Dupont Review Date: 2007-02-11 IETF LC End Date: 2007-03-08 IESG Telechat date: (if known) Summary: Almost Ready Comments: as already signaled this document has a real issue with its title. I recommend to take a model, for instance RFC 2851. Some minor details: - ToC and 6, pages 2 and 6: Acknowledgements - Acknowledgments - 2 page 3: the way STD 58 is referenced is inelegant (but it seems the issue is more in the STD 58 covering multiple RFCs...) - 6 page 6: perhaps to add the editor mention is the thing to do? - 7 pages 6 and 8: to cite the last I-D and status of RFCs is not the usage. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-avt-ulp-21.txt
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-avt-ulp-21.txt Reviewer: Francis Dupont Review Date: 2007-03-15 IETF LC End Date: 2007-04-03 IESG Telechat date: unknown Summary: Ready Comments: I have only a few minor editorial comments (which should be handled by the RFC editor): - 5 page 8 (section title): the usage is to put no space before a colon : in English. BTW I believe the best should be: 5. Uneven Level Protection (ULP) - 5 page 8: In stead - Instead ? - 7.3 page 11: in The P recovery field, the X recovery field, the CC recovery field, the M recovery field, and the PT recovery field are obtained via the protection operation applied to the P, X, CC, M, and PT values of the media packets associated with the FEC packet. it should be fine to add the P, X, ... and PT are names of RTP fields. - 11 page 28: a word seems to miss in The changing of encryption keys is another crucial issue needs to be addressed. - 17 pages 39 and 40: I know where the problem (again) comes from so I don't expect a solution for this document in particular: * to put a status like (Proposed Standard) is not standard * for a BCP the BCP number should be added * RFC 3388 has no status (it is right but not as the others?) So the RFC editor will have to reformat the references... Regards [EMAIL PROTECTED] PS: I have not checked all the numerical examples (not a job for a human :-). ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review (summary) of draft-ietf-hip-mm-05.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-hip-mm-05.txt Reviewer: Francis Dupont Review Date: 03 April 2007 IESG Telechat date: 05 April 2007 Summary: Not Ready Comments: I'll send full comments in some hours (with a better network connection) but I have a real issue (so the summary) with the Abstract which IMHO is not coherent (i.e., it doesn't say the same thing from beginning to the end. BTW it doesn't describe the real content of the document too, which seems to be between the two sides). Here I quote it to get other opinions: This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general LOCATOR parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. There are some other points but not critical at one exception (I'll send them ASAP). Regards [EMAIL PROTECTED] PS: IMHO the document provides readdressing which is a limited form of mobility (as explained inside the document, so the issue is in the wording) and a limited form of multihoming too. Perhaps the source of the problem is the mixed between the mechanism and its usage? ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review (full) of draft-ietf-hip-mm-05.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-hip-mm-05.txt Reviewer: Francis Dupont Review Date: 03 April 2007 IESG Telechat date: 05 April 2007 Summary: Not Ready Comments: - as I wrote in the summary message, IMHO the abstract needs a full rewrite - in 5.4 page 31, I have a real concern with the new SPI value SHOULD be random because IPsec people took a real care to *never* put such a constraint on SPI values. I simply propose to not specify how to choose a new SPI value (out of the reserved range of course) - I believe the reference [3] (Rendez vous) should be made not normative. Perhaps the introduction wording needs to be adapted (I don't believe so but you should check with your AD) (minor points) - abstract page 2, intro page 4, 3.2.3 page 14, 3.2.5 page 15, 3.3.4 page 21: I prefer a space before -- (as it is the rule in French, the language the construct is from :-) - intro page 4: double (and too close) usage of the word possible - 2 page 6: perhaps the right place to introduce the status keywords and locator types - 3.1 page 9: the for fault tolerante is too restrictive, I propose to add for instance - 3.1.2 page 10: other transport modes - formats? - 3.2.1 page 12: first use of the status keywords (UNVERIFIED, DEPRECATED and ACTIVE) - 3.2.3 page 13: question: what happens for addresses which are not in a locator? This is a generic issue, if we want to avoid this case the address selection rules (RFC 3484) should be prepended with a rule limiting the candidate set to locators - 3.2.3 page 13: in However, it is recommended that implementations attempt to support peers that prefer to use non-paired SAs why not RECOMMENDED? (BTW to avoid this kind of question the best is to use a synonym in the place of a lower case keyword) - 3.2.3 page 14: first use of locator types (and without any hint about what there are for a new reader) - 3.2.7 page 16: some type of mechanism - mechanisms? - 3.3.3 page 20: draft - document/text/... (but not draft! :-) - 3.3.4 page 21: unless the ESP anti-replay window is loose??? ^ I suggest is large enough - 3.3.4 page 22: I don't (want to) understand what you mean by at least reset its ESP anti-replay window ^ - 4 page 24: the P (preferred) flag is underdefined. It seems according to 5.5 -3 it is in fact a hint. So it can be an answer to my question: is it possible to set zero or more than one P flag to one? - 4.2 page 25: th locator type must be introduced before! - 5.1 page 26: the status must be introduced before! - 5.2 page 27 and 5.3 page 30: the IPv6 undefined address should be added to the illegal addresses (i.e., with broadcast and multicast)? - 5.5 -3 page 33: I really don't like the idea to pick randomly an address. Why not using the RFC 3484 rules? - 5.6 page 33: to stay polite and because my own opinion is already well known, I shan't say what I think about the CBA mechanism... - 7 page 42: the Section 5.3 doesn't define this parameter with a Value of 46 (easy but mandatory to fix as the IANA consideration will stay) - appendix A page 44: the usage is to specify the appendix will be removed by the RFC editor Regards [EMAIL PROTECTED] PS: IMHO the document provides readdressing which is a limited form of mobility (as explained inside the document, so the issue is in the wording) and a limited form of multihoming too. Perhaps the source of the problem is the mixed between the mechanism and its usage? ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: review (full) of draft-ietf-hip-mm-05.txt
In your previous mail you wrote: I discussed briefly with the authors. Your comment is consistent with some other recent comments that the draft does not fully specify a mobility and multihoming solution but only the readdressing mechanisms. = note that the only issue here is the (old) abstract doesn't reflect the content of the document. After thinking about your suggestion, I would be inclined to even retitle the document to something like: Readdressing Extensions for HIP Mobility and Multihoming to clarify that there are other aspects of mobility and multihoming that are not addressed. I would be inclined to keep Mobility and Multihoming terms in the title, though, because it is part of the HIP charter to produce such a document. = I have no problem with the title itself as soon as the abstract is clear. Would you agree with the following abstract? If not, can you suggest specific changes? OLD: This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general LOCATOR parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. NEW: This document defines readdressing extensions to the Host Identity Protocol (HIP) to facilitate host mobility and multihoming. Specifically, this document defines and specifies basic elements of procedure for a general LOCATOR parameter for HIP messages. The LOCATOR parameter allows a HIP host to notify peers about alternate addresses at which it may be reached, and further allows it to express policy preferences as to which address to use in different situations when there exists more than one choice for a destination address. Procedures for requiring a host to test the reachability of alternate addresses are also specified. Using this basic readdressing mechanism, limited forms of host mobility and multihoming may be performed, but detailed procedures for a full solution for mobility and multihoming are left for further study. = this new abstract is far better! Question for the chairs/AD-- what do you think about changing the document title at this date in the review? - in 5.4 page 31, I have a real concern with the new SPI value SHOULD be random because IPsec people took a real care to *never* put such a constraint on SPI values. I simply propose to not specify how to choose a new SPI value (out of the reserved range of course) AFAIK, this comes from even the very first drafts on HIP by Bob Moskowitz in 1999. The SPI is being used as an endpoint selector. I do not know the security assumptions that led Bob to recommend the SHOULD but I will ask. = I asked in the IPsec list whether SPIs should be random and the answer was a loud *no*. IMHO there is not good reason to have such a constraint. I believe we should simply ask the security ADs. - 3.2.3 page 13: question: what happens for addresses which are not in a locator? This is a generic issue, if we want to avoid this case the address selection rules (RFC 3484) should be prepended with a rule limiting the candidate set to locators I think the question is whether a host may use an address that was not learned during the base exchange or through the LOCATOR parameter. I would suggest that such addresses, if learned out-of-band from the mechanisms specified herein, be treated as UNVERIFIED addresses. = this is only a half solution as the interaction between the LOCATOR notion (including the status) and the RFC 3484 has to be specified (note this is an issue of RFC 3484: as soon as something new is introduced the rule sets, which are in a standard track document, have to be amended by another document at a similar level...). I can see you understand the problem in the new P flag text. If my proposed changes above are acceptable, the current open issues are: 1) whether the title should be changed 2) the SHOULD for setting the SPI value randomly 3) the CBA draft references need to be replaced with a permanent citation 4) should addresses learned out-of-band be treated as UNVERIFIED, and words to that effect be put in the draft? = fine with me. Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-shacham-sipping-session-mobility-03.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-shacham-sipping-session-mobility-03.txt Reviewer: Francis Dupont Review Date: 17 April 2007 IESG Telechat date: 10 May 2007? Summary: Ready Comments: some details which should be handled by the RFC editor: - 2 page 4: expand PSTN abbrev at its first use. - I don't really like the last sentence of REQ 1/Page 4 - 3 page 5: UA is expanded only at its second use (it should be once and at the first time). - 4 page 6: ie., - i.e., - 5.2.1.2 page 12: possiblity - 5.2.2 page 14: unidectional - 5.4 page 23: expand CPL? - 6.1 page 24: twice the paragraph If the CN and the local... - 6.1 page 4 (next paragraph): which need - which needs? Regards [EMAIL PROTECTED] PS: I believe this is more readdressing than mobility but as SIP is routed and the Abstract is very clear about the intended meaning of the word mobility IMHO there is no need to change this. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-tsvwg-addip-sctp-20.txt
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-tsvwg-addip-sctp-20.txt Reviewer: Francis Dupont Review Date: 2007-05-16 IETF LC End Date: 2007-05-18 IESG Telechat date: unknown Summary: Almost Ready Comments: I have only one major comment: the abstract doesn't reach the requirements for abstracts, in particular it is too short. I have no strong idea about what to add, perhaps a statement about what the document provides or about its goals... Some minor points (which should be handled by the RFC editor if you don't publish a new version): - 3 page 5: 2*32 - 1 - 2**32 - 1 (IMHO the right notation is with a ** and spaces around the -) - 4 page 5: and, seven - and seven ? - 4.1.1 page 7: message i.e. - message, i.e., - 4.2 page 8: Table 2, 3 and 4 - Tables 2, 3 and 4 ? - 4.2.3 page 11: Error Cause(s) or Return Info on Success - Error Cause(s) ? - 4.2.4 page 12: The Set Primary IP Address parameter may appear in the ASCONF Chunk, the INIT, or the INIT-ACK chunk type. remove ^ - 4.3 page 15: illegal ASCONF-ACK - illegal ASCONF-ACK. - 4.3.4 page 18: 2^^31-1 - 2**31 - 1 - 5.1.1 page 21 C5: a minimal path MTU. The minimum PMTU choose between minimal and minimum and use path MTU in place of PMTU - 5.2 page 22: (i.e. - (i.e., - 5.2 page 22: insert a blank line before E1 - 5.2 page 23: insert a blank line before E2 and V3 - 5.2 page 24 V4: e.g. - e.g., - 5.2 page 24 E7: PMTU - path MTU - 5.3 page 24 F0: 2^^31-1 - 2**31 - 1 - 5.3 page 25 F1: The receiver of the add IP address request may use the address as a destination immediately. The receiver MUST use the path verification procedure for the added address before using that address. This is a bit confusing... - 5.3.1 page 28: rule D4 - rule F4 - 5.4 page 29: (i.e. - (i.e., - 5.5 page 30: other i.e. - other, i.e., - 5.5 page 30: Each new ASCONFs lookup - Each new ASCONF lookup - 6 page 30: modfiy - modify Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dhc-dhcpv6-ero-01.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-dhcpv6-ero-01.txt Reviewer: Francis Dupont Review Date: 21 May 2007 IETF LC End Date: 28 May 2007 IESG Telechat date: unknown Summary: Ready Comments: only editorial (i.e., to be handled by the RFC editor) comments: - 4 page 4 last sentence: either the wording is poor or the sentence should finish by Relay-Reply message. - in 4 and 5 page 4, the abbrev ORO should be replaced or expanded into Option Request Option (I suggest to introduce the abbrev in section 4 to use it in section 5). - I suggest to use either a dash or a space in message names. BTW RFC 3315 uses Relay-forward and Relay-reply (a dash and one cap). - IMHO (i.e., do it if you'd like or if someone else asks for it) it should be fine to add a detailed reference (section 20.3 of RFC 3315) in the first sentence of section 5. Regards [EMAIL PROTECTED] PS: don't forget Brian's comments. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mip4-fmipv4-07.txt
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-mip4-fmipv4-07.txt Reviewer: Francis Dupont Review Date: 2007/06/01 IETF LC End Date: 2007/06/01 Summary: Ready Comments: some editorial (i.e., to be handled by the RFC editor) comments: at page 6 section 4.2: - in FA COA mode - in FA-COA mode - for the FSU field, I propose to add a MUST somewhere, for instance: are used - MUST be used and for each field XXX field must be - XXX field is in 10 page 25 (and TOC pge 2): Acknowledgement - Acknowledgment same? in 6.2 figure 4 page 11 In Security Considerations page 8 there is nothing about replay attacks, i.e., how the come back to where you was attack is handled? In IPv6 the protection is provided by IPsec with in the good case anti-replay, is it done in IPv4? Regards [EMAIL PROTECTED] PS: I apologize: I am late because I had to replace the disk of my notebook... ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-rtgwg-rfc3682bis-09.txt
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-rtgwg-rfc3682bis-09.txt Reviewer: Francis Dupont Review Date: 2007/06/10 IETF LC End Date: 2007/06/15 IESG Telechat date: not known Summary: Almost Ready Comments: I have only one major comment: the document does not explain it is a revision of RFC 3682, I propose to add a sentence at the beginning of the introduction stating that with a reference. Other points (minor/editorial/for the RFC editor): - 2 page 4 in: The possibility of denial-of-service (DoS) attack prevention, however, is based on the assumption that packet classification and separation of their paths is done before they go through a scarce resource in the system. two proposals: is - are and packet classification - classification of (the?) packets - 2.2 page 5: (i.e., trusted) - (i.e., are trusted) - 5.1 page 7: hasn't - has not - 5.5 page 12: multi-hop - multi-hop case - 6.1 page 12: add a reference for RFC 3682 here (in fact, everywhere at the exception of the abstract). - A page 14: I can't parse within TrustRadius (e.g., 1) of 255 instead of 255 Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
In your previous mail you wrote: = I reply here because there is a common misconception in this comment. I have been selected as the General Area Review Team (Gen-ART) An important requirement for IPsec-based protection of Mobile IPv6 route optimization is that the IPsec security associations are bound to the mobile node's home address. A malicious mobile node could otherwise misuse its own security association for impersonating the home address of a different mobile node. The draft ensures this requirement in section 3 by saying that... - the Traffic Selectors MUST match exclusively the Home Address of the Mobile Node and an address of the Correspondent Node (the address used for communication between peers). Yet the importance of this requirement, as well as its reason and effect, is unlikely to become clear to the non-expert reader. I would recommend adding a section in the Security Considerations sections elaborating on this. = in fact the home address impersonation attack exists only in the mobile node - home agent case, not in the mobile node - correspondent case. If a node can use the address of another node to communicate with the correspondent, establish some security association, etc, this is an IPsec issue if the address gives some specific authorizations. The mobility does not change this, in fact it makes just this a bit harder for a rogue mobile node in visit because of the home agent control. So in fact the requirement is not for security but only for safety. BTW I believe the MUST is good and should not be replaced by a SHOULD, and there will be some new text explaining the requirement. Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
In your previous mail you wrote: = in fact the home address impersonation attack exists only in the mobile node - home agent case, not in the mobile node - correspondent case. If a node can use the address of another node to communicate with the correspondent, establish some security association, etc, this is an IPsec issue if the address gives some specific authorizations. I do agree with you that the issue is with IPsec IF THE IP ADDRESS IS USED FOR AUTHORIZATION. Therefore, in the non-mobile case, IP address ownership may or may not be important. However, the specialty of the mobility case is that the IP (home) address is ALWAYS used for authorization. = I disagree, the authorization is given to the node. The whole purpose of using IPsec is IP (home) address ownership verification. = no, the whole purpose of using IPsec is to verify the node doing the signaling is the node owning the traffic. This is what is important and should be more carefully attended to in your draft. = what is really lacking is the goal of the draft: this is not to provide an absolute security, but to keep in the mobility + IPsec context at least the same security than in IPsec alone. The address ownership issue can be a real one but it is an IPsec issue: an attacker can not do significantly more damage with a fake home address than with just a fake address. BTW I am not against a SHOULD for the protection of statically assigned home address. My problem is this is not a real mobility issue so it is not formelly in the scope of the draft. I propose to put it in the PAD and SPD examples asked by Sam Hartman. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
In your previous mail you wrote: an attacker can not do significantly more damage with a fake home address than with just a fake address. With IPsec alone, an attacker wouldn't be reachable if it used a fake IP address. This is different when you add Mobile IPv6 because the attacker may then be reachable at the care-of address even if the home address is fake. = as this is the point we disagree about, just explain how this can happen! Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
In your previous mail you wrote: unless you bind the IPsec security association to the home address, an attacker could send a Binding Update message with a spoofed home address using its own IPsec SA. The correspondent node's IPsec instance would accept that message and hand it on to the Mobile IPv6 instance. The Mobile IPv6 instance would rely on the message being authenticated and update the binding cache entry for the spoofed home address. = I agree but I can't see an issue with this: if I remove the word home and all allusions to mobility your statement still applies so as I've already explained the home address is not special and this kind of spoofing is not specific to mobility. You can eliminate this issue with one or two additional, clarifying sentences in your draft. = IMHO it is not reasonable to forbid dynamic addressing in IPsec so it is not reasonable to forbid dynamic or pseudo-anonymous home addresses (pseudo-anonymous: which has no particular property attached to it). And please note the initial IPsec establishment has to be done before IPsec can protect the mobility signaling so without asking anything to IPsec for this IPsec is already at least as good as a return routability check. To finish I've also already stated I am not against a SHOULD for a protection in the case of statically assigned home addresses: - it is easy to do in this case - it improves the security - as this protection is required in the MN-HA context and in this case the simplest way is to encode it in the certificate it should be got for free. To summary if a spoofed home address is accepted it is because the IPsec configuration was setup to accept it. The only thing we have to do is to enforce it was not by accident. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-shacham-sipping-session-mobility-04.txt
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-shacham-sipping-session-mobility-04.txt Reviewer: Francis Dupont Review Date: 2007-09-20 IETF LC End Date: done IESG Telechat date: on next agenda Summary: Ready Comments: I have a few editorial comments: - ToC page 2 and 11 page 32: s/Acknowledgements/Acknowledgments/ - 1 page 4: s/teh/the/ - 3 page 5: s/SLP [18]Directory/SLP [18] Directory/ - 4 page 6: s/search e.g.,/search, e.g.,/ ? - 5.2 page 9: please expand the AOR abbrev at its first use. - 5.3.1.2 page 13: s/active endpoint, opening/active endpoint [by] opening/ ? - 5.4.1 page 18 and some others: some too long lines in the examples - 5.4.1 page 19: s/5.3.2/5.4.2/ ? (note this is the only one which is not at 100% in the scope of the RFC Editor, so please check) Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-rmt-bb-fec-rs-03.txt
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-rmt-bb-fec-rs-03.txt Reviewer: Francis Dupont Review Date: 2007-09-26 IETF LC End Date: 2007-10-04 IESG Telechat date: unknown Summary: Ready Comments: I have only editorial (i.e., for the RFC editor) comments: - abstract page 2: s/FEC/Forward Error Correction (FEC)/ (IMHO it is needed even it is in the title) - 3.2 page 6 and at many other places: s/i.e./i.e.,/ and s/e.g./e.g.,/ - 3.2 page 7 and some other places: in q = 2^^m please try to put the equation on the same line - 3.3 page 7: s/A.K.A./a.k.a./ ? - 4.1 page 8: s/There are a maximum/There is a maximum/ ? - 4.1 page 9 and others: please try to put the caption on the same page than the figure - 4.2.3 page 10: s/,m/(m)/ ? - 4.2.4 page 10: please add a reference to the document where the EXT_FTI format is defined (i.e., as it is done for FLUTE)? - 4.2.4.2 page 10: expand FDT? - 6.2 page 15: add final . at the end of sender output and receiver input items? - 8.1 page 18: monomial is only an adjective? - 8.4 page 20: s/this padding need not be/this padding does not need to be/? - 8.4 page 21: s/Reed Solomon/Reed-Solomon/ - 8.4 page 22: my speller complaims about erasures - 9 page 23: if (and only if) there is a document describing a scheme less expensive than digital signatures (*) please cite it! - 10 page 24: in fact the [2] is a revision of the RFC 5052 where the IANA registery is defined... - 12.2 pages 26/27: an extra space before the final dot. Regards [EMAIL PROTECTED] PS (*): for instance (I don't remain the name) for a secret value use the hash N times then the hash N-1 times, etc, as for one-time passwords. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] (full) review of draft-ietf-nfsv4-nfsdirect-06.txt
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-nfsv4-nfsdirect-06.txt Reviewer: Francis Dupont Review Date: 2007-10-10 IETF LC End Date: 2007-10-12 IESG Telechat date: unknown Summary: Almost ready Comments: I maintain my concern about the abbrevs in the Abstract even I recognize it is more from the way the nfsv4 stuff is cut out in several documents... There are some places where the wording is not so good (the RFC editor should fix them): - 5 page 6: buffers, lest an RDMA - 5 page 7: unbounded - unbound - 7 page 7: are required by that: thhat - this and BTW what is the specification, RFC 3530? - 7 page 8: the two by IANA. Regards [EMAIL PROTECTED] PS: in the batch of IETF LC reviews message I have this warning: This document contains two downward references (downrefs). As required by RFC 3967, the last call message for this document needs to bring these to the attention of the community. The downrefs are to specifications of earlier versions of the NFS protocol, which were published as Informational, because they had been developed outside the IETF: [RFC1094] NFS: Network File System Protocol Specification, (NFS version 2) Informational RFC, 1989. [RFC1813] B. Callaghan, B. Pawlowski, P. Staubach, NFS Version 3 Protocol Specification, Informational RFC, 1995. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-simple-partial-publish-06.txt
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-simple-partial-publish-06.txt Reviewer: Francis Dupont Review Date: 2007-10-16 IETF LC End Date: none IESG Telechat date: unknown Summary: Ready Comments: only minor editorial stuff which should be handled by the RFC editor (i.e., please don't rush to your keyboard :-): - Abstract page 2: to constitue is not in my dicts (even I understand well the term?) - TOC page 2 and 7 page 13: Acknowledgements - Acknowledgments - 1 page 3: presentity is not in my dicts too but IMHO it doesn't matter as it is well introduced - 3.1 page 4: expilicitly - explicitly - 4.2 page 6: precedures - procedures - 4.3 page 7: dependant - dependent - 8.2 page 14: to Presence - to Presence Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review (summary) of draft-ietf-pwe3-pw-tc-mib-12.txt
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-pwe3-pw-tc-mib-12.txt Reviewer: Francis Dupont Review Date: 2007-11-06 IETF LC Date: 2007-11-09 IESG Telechat date: unknown Summary: Ready Comments: I have to run MIB doctor co on the document but IMHO there are only minor editorial concerns (i.e., things which should be handled by the RFC editor). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: review of draft-ietf-sip-multiple-refer-02.txt
In your previous mail you wrote: Comments: the comments are editorial, i.e., they enter in the kind of things which can be handled by the RFC Editor: - 2 page 3: according to the Introduction the REFER-recipient should be a server, not a user agent, i.e., either I've misunderstood the Introduction or there is a typo. First background information. In SIP most of the endpoints are called User Agents. When they send a request or receive a response they act as a User Agent Client; when they receive a request or send a response they act as a User Agent Server. So, the definition is technically correct. The term server in the introduction really means A box in the network and it is not connected to the term User Agent Server. The current version of the draft assumes that these two concepts are know by the reader, but it is not obvious for readers who aren't familiar with SIP, so, we should try to clarify them. = yes, you should not lose the reader in the introduction. In general you have to introduce terms with a different meaning than the common one. - 5 page 4: NOTIFY requests - messages (even they are requests (cf RFC 3261) in the common language it seems a bit strange to name them requests) In SIP a message can either be a request or response. NOTIFY is a request not a response. So, the text is technically correct. = this is the same problem: in the general meaning a notification is not a request, so a neutral term is IMHO better. Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-ipdvb-ule-ext-06.txt
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-ipdvb-ule-ext-06.txt Reviewer: Francis Dupont Review Date: 2007-12-13 IETF LC End Date: 2007-12-17 IESG Telechat date: unknown Summary: Almost Ready Comments: I have many editorial comments so even they can be handled by the RFC Editor IMHO you could publish a new version of the document. In details: - the Table of Contents should have page numbers to be useful - in the TOC page 2 and 5 page 13: Acknowledgements - Acknowledgments (this is the standard IETF spelling) - 1 page 3: to that of ULE? - 1 page 3: (NPA) address - (NPA)? (the destination is the NPA) - 1 page 3: addressed by the NPA (I don't like the word addressed here) - 2 page 4: FEC - Forward Error Detection (FEC) - 2 page 4: remove (or by Ethernet v2)? - 2 page 4: the real name of the ISO is nternational Organization for Standardization (cf ISO's name on http://www.iso.org/) - 2 page 5: remove , in encapsulates PDUs, into? - 3 page 6: 1536 Decimal - 1536 decimal - 3 page 6: utilises - utilizes - 3 page 6: optimisation - optimization - 3.1 page 8: labelled - labeled - 3.1 page 8 and others: i.e. - i.e., - 3.1 page 8 and others: e.g. - e.g., - 3.2 page 10 and others: I suggest to change PDU-Length-1 into PDU-1-Length, etc. - 3.2 page 10: spurious _ in (LT=00)_ - 3.3 page 12: synchronised - synchronized - 5 page 13: annexe - annex (and BTW it is an appendix) - 7.2 page 14: ISO real name again... Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-ccamp-mpls-gmpls-interwork-reqts-03.txt
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-ccamp-mpls-gmpls-interwork-reqts-03.txt Reviewer: Francis Dupont Review Date: 2007-12-21 IETF LC End Date: IESG Telechat date: unknown Summary: Ready Comments: some editorial comments to leasve to the RFC Editor: - Abstract page 1: A MPLS-TE - An MPLS-TE - 1 page 3: the top of the page 3 has perhaps a pb: GMPLS protocols were developed as ... - 3.1 page 5: is the 'adjacencies' word in a dictionary? - 3.9 page 6 (and some others): please introduce list with a sentence finishing by ':'. - 4 page 7: the border routers form part - the border routers are part? - 4 page 7: the position of the Security Considerations is unusual but I don't believe it matters as soon as there is one. - 5.1 page 9: All three LSP types MAY - All the three LSP types MAY? - 5.3 page 9: please introduce the FRR abbrev Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-simon-emu-rfc2716bis-12.txt
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-simon-emu-rfc2716bis-12.txt Reviewer: Francis Dupont Review Date: 2008-01-09 IETF LC Date: 2007-12-27 IESG Telechat date: 2008-01-10 Summary: Ready Comments: I have some editorial comments (editorial means they should be handled by the RFC Editor): - 2.1 page 4: s/backend security server/backend authentication server/ - 2.1.1 page 5: s/e.g. /e.g., / - 2.1.2 page 7: s/remoted/remote/ - 2.2 page 16: s/need not be/needs not be/ (subject is the identity) - 5.1 page 22: s/KDF/key derivation function/ - 5.2 page 24: s/RDN/relative distinguished name (RDN)/ - 5.2 page 24: s/CN/CommonName (CN)/ ? (I know CN is more used than the full name but as far as I know the official name is CommonName) Note there could be other not introduced abbrevs - 5.3 pages 24 and 25: s/conformant/compliant/ ? - 6.2 page 28: s/Bands IEEE 802.16e/Bands, IEEE 802.16e/ - Acknowledgments page 29: it is not usual to add the companies - Authors' Addresses page 30: please add USA (yes! :-) For the iESG I am not very satisfied with the reference to the NIST SP800-57: this document is a good one and it is better to reference it than to leave nothing but the IETF is an international body so one could complain about the National in NIST... I don't know if it really matters, BTW it is an informative reference, but it should be nice to find a way to avoid any complains for this kind. (Note I don't complain but I know the editor of the similar French gov text (from an organization with the same N in its name :-) so I am trying to understand what he should think about this point). Thanks [EMAIL PROTECTED] PS: as EAP-TLS seems to still be the only blessed EAP method usable according to RFC 4017 it is (was now) very important to have a high quality new version of 2716, so again thanks! ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-daboo-imap-annotatemore-12.txt
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-daboo-imap-annotatemore-12.txt Reviewer: Francis Dupont Review Date: 2008-01-14 IETF LC End Date: 2008-01-30 IESG Telechat date: unknown Summary: Ready Comments: Some editorial (i.e., to be handled by the RFC Editor) comments: - Abstract page 1: add (IMAP) after Internet Message Access Protocol - 3.3 page 8: A user - Users - 3.3 page 8: If the client - if a client - 4.1 page 9: i.e. - i.e., (there are four i.e.s in this page and some others after) - 4.2 page 11: this criteria - these criteria - 4.3 page 12: the extended LIST command return - ... returns - 5 page 22: parenthesised - parenthesized - 6.3.5 pag 27: remove Please register... Note you have some comments from the Last Call and many normative references are still at the draft state (the second point should not be a problem, the RFC Editor will just publish all interdependent documents together). Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mip6-hiopt-10.txt
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-mip6-hiopt-10.txt Reviewer: Francis Dupont Review Date: 2008-01-30 IETF LC End Date: 2008-02-04 IESG Telechat date: unknown Summary: Not ready Comments: I have three series of comments: editorial (which should be handled by the RFC editor but you may fix them if (and only if) you publish a new version for a different reason), formal and not-formal. Editorial comments: - ToC page 2 and 7 page 18: s/Acknowledgements/Acknowledgments/ - 4.2 page 13: the [Editor's note] is a sure source of editorial issues (for instance the abbrev AVP) - 4.2 page 13: s/OPTION_CLIENTID/Client-id option/ - 4.[23] page 14: s/Relay Message/Relay-message/ - 4.2 page 14: s/Information Request/Information-request/ - please use the same spelling for pre(-)configured along. Formal comments: - you should explain in 1 (introduction) or 3 (options) that DHCP is used to get informations, not resources (so the client uses an Information-request message in the framework described by the RFC 3736 (Stateless DHCPv6)) with a HN Identifier/Information option exchange. (I'll come back to this in not-formal comments). - 3.1 page 6: the HN Identifier field must be marked as optional. - 3.2.1 page 8: the HN Information is not to be provided to a mobile node because the MIP6 relay agent option is sent to a server. - 4.1 page 12: why the should for the two not more than one is not a SHOULD? - 4.2 page 13: RFC 3315 allows a chain of relays so the SHALL to the DHCP server should be relaxed. - 4.2 page 14: a second to the DHCP server - 4.2 page 14: the Relay-message (- and lower case m) option of the Relay-reply message carries a Reply, not an Information-request. - 4.3 page 14: the MIP6 Relay Agent option is not in the Information- request message. Not-formal comments: - I don't like to use DHCPv6 as a service discovery protocol as it was designed to assign resources. But as the RFC 3736 narrowed the protocol to this kind of things it is a matter of taste (but please explain this point and cite the RFC). - the HN Identifier/Information is not at all in the style of DHCPv6 which uses two (other) ways: * ORO when the client just says it'd like to get it * options, including skeleton options when the client has to say more, even it is just the number of options in the answer Applied to the Home Network options, they should be merged and the Identifier become a sub-option. - ORO doesn't make sense for HN Information (nor more it makes sense for IAs). ORO could be used to replace the id-type 2 but IMHO it is not a good idea. - as a DHCPv6 implementor, I don't like at all optional fields (and the HN Indentifier is an optional field - IMHO the V flag should be in the option itself, not in sub-options - the architecture enforces the NAS to be the first (and even the only) DHCP Relay. There is no good reason for this constraint and a better wording can remove it, i.e., the only point to keep is the excellent idea to collocate the NAS and the DHCP agent - Quoting RFC 4580/4649 this statement should be added about server behavior with MIP6 Relay Agent option: There is no requirement that a server return this option and its data in a Relay-reply message. - the MIP6 Relay Agent option is brain damaged: either the relay doesn't know the infos to answer and it forwards the request to the next agent, or it knows and it is silly to insert the answer in an agent option when it is so simple to just answer. So in place of to get an active relay with a passive server I propose to follow the architecture of DHCPv6 as it was designed and to use an agent which is a relay or a server according it can answer or not (note as a relay may forward a request to multiple servers the or is not exclusive and an ORO for a very not-MIP6 option is not an issue). - the SHALL for the exclusive use of the Client-id for the MN identification should be removed as it is very unlikely the NAS knows the MN's DUID. BTW the Client-id option is not mandatory in Information-requests... - finally, prefixes have lifetimes when informative options have none (and RFC 4242 is Information-request wide) so I propose to reuse the ia-prefix option layout in HN prefix sub-option Thanks [EMAIL PROTECTED] PS: as the last call is still open you can consider my not-editorial comments as last call comments, i.e., if you ask I can cut past them to the MEXT and/or DHC list. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] about draft-ietf-ipdvb-ule-ext-07.txt
The preceeding version, draft-ietf-ipdvb-ule-ext-06.txt, was reviewed last year with the Almost Ready summary because of the large number of editorial comments. As the remaining/missed editorial issues should be handled by the RFC Editor, IMHO the document is now Ready. Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org http://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-vanelburg-sipping-served-user-04.txt
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-vanelburg-sipping-served-user-04.txt Reviewer: Francis Dupont Review Date: 2008-02-12 IETF LC End Date: 2008-02-04 IESG Telechat date: unknown Summary: Almost Ready Comments: I have many editorial comments so it is perhaps a good idea to publish a new version and not to rely on the RFC Editor: - TOC page 2: s/Acknowledgements/Acknowledgments/ - 1 page 3 and many other places: I propose to cite RFC with (RFC XXX [Y]) (no space after the parenthesis, one between RFC and the number) - s/signalling/signaling/ ? - 3.2 page 3: S-CSCF and AS (and ISC next page) abbrevs must be introduced (the Abstract is not considered as a part of the body of the document) (IMS is in this list too) - I don't like the plural As's - 4.1 page 4: I have 3 concerns with the word allocate[d]: * assigned seems better as a client is not something one can allocate * it is not clear what is allocated to what * s/allocated for/allocated to/ ? - I don't like *perform* its responsabilities - s/P-Asserted-Identy/P-Asserted-Identity/ ? - if there is no reason to use determines 4 times in the same paragraph please vary - 4.2 page 6: s/behaviour/behavior/ ? - 4.2 page 6 (and another one): s/realised/supported/ ? (BTW it should be realized) - 4.4 page 8 last paragraph: I don't like the mix of past and future - 6 page 8: you have to introduce the meaning of P in P-Header - s/standalone/stand-alone/ ? - 10 page 10: s/Acknowledgements/Acknowledgments/ - 11.2 page 11 [12]: please check the spelling Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org http://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-nfsv4-nfsdirect-07.txt
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-nfsv4-nfsdirect-07.txt Reviewer: Francis Dupont Review Date: 2008-03-21 IETF LC End Date: 2008-03-26 IESG Telechat date: unknown Summary: Ready Comments: some editorial comments (editorial == to be handled by the RFC Editor by default) and 3 questions (with positive answers): - first question: is the document good for standard track or BCP is better? There are many similar documents in standard track and this document should be handled as its companion drafts, so IMHO there is no issue with standard track. - should NFS and RDMA be more introduced. As this document is for people with a good knowledge of NFS and RDMA IMHO it doesn't need this kind of things. - should RPC abbrev be introduced in the Abstract? As it is a concept (and should be very well known) IMHO I don't think so, i.e., keep the Abstract. Editorial: - 2 page 3: the XDR abbrev should be introduced - 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: 3 page 3: null Write list 4 page 5: RDMA READs and RDMA READ 5.1 page 7: as READ or WRITE 6 page 8: RDMA READ ad RDMA WRITE (It is possible I've missed some) Spelling: - TOC and 9 page 9: Acknowledgments Regards [EMAIL PROTECTED] PS: the version on the gen-art site is the 06? ___ 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
In your previous mail you wrote: 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! = the rule itself does not matter, what is important is to have one and to apply it consistently (:-)! Thanks for the careful review. Acknowledgment being spelled inconsistently was a particular surprise! :-) = in fact IMHO both spellings exist but the RFC Editor decided for one (and again one had to be chosen and to become the only one to be used). Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-snell-atompub-bidi-06.txt
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-snell-atompub-bidi-06.txt Reviewer: Francis Dupont Review Date: 2008-04-22 IETF LC End Date: 2008-05-09 IESG Telechat date: unknown Summary: Ready Comments: one comment and two questions, all are editorial so have to be handled by the RFC Editor: - in ToC (page 2) and Appendix (page 6): Acknowledgements - Acknowledgments - some refs are pretty long (for instance [W3C.REC-xml-names-19990114]), I'd like to get opinions about this as there are pros and cons. - Acknowledgments are in an appendix, usually it is a section. Regards [EMAIL PROTECTED] ___ 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
In your previous mail you wrote: Francis: -08 is on the Telechat for this week. Please check if your concerns were resolved. = they were (BTW they were editorial) so I keep the Ready summary. Thanks [EMAIL PROTECTED] PS: I copy my answer to the gen-art list for the archives. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-vanelburg-sipping-served-user-04.txt
In your previous mail you wrote: Francis: Does -05 resolve your concerns? Russ = yes, they are editorial comments... I change the summary to Ready. Thansk [EMAIL PROTECTED] At 06:59 PM 2/12/2008, Francis Dupont wrote: Document: draft-vanelburg-sipping-served-user-04.txt Summary: Almost Ready Comments: I have many editorial comments so it is perhaps a good idea to publish a new version and not to rely on the RFC Editor: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pim-lasthop-threats-04.txt
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-pim-lasthop-threats-04.txt Reviewer: Francis Dupont Review Date: 2008-05-19 IETF LC End Date: 2008-05-23 IESG Telechat date: unknown Summary: Ready Comments: mainly editorial comments, i.e., should be handled by the RFC Editor: - ToC and section 5 page 11: Acknowledgements - Acknowledgments - Introduction page 3: abbrevs should be introduced (including PIM as the abstract is not considered as a part of the document body). - section 2 page 3: signalling - signaling - section 2.5 page 5: behaviour - behavior - section 2.6 page 5: TTL - time-to-live - section 4.2 page 8: the reference to GDOI is fine but as GDOI is old and there are many newer things. IMHO you should check with the msec WG chairs if they have something to add, or for instance you could announce this last call in the msec WG list... Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-kato-ipsec-camellia-modes-07.txt
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-kato-ipsec-camellia-modes-07.txt Reviewer: Francis Dupont Review Date: 2008-05-23 IETF LC End Date: 2008-06-10 IESG Telechat date: unknown Summary: Not ready Comments: my main concern is about the organization of the different camellia mode/ipsec documents, for instance why the CTR and CCM modes are not only in draft-kato-camellia-ctrccm with only the application to IPsec in this one? (note: you copied the RFC 3686 so I can understand you don't expect my comments :-) Other comments: - title page 1: Its - Their - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: to - by (in replacing block) - 1 page 3: lisences - licenses - 1 page 3: Openssl - OpenSSL - 1 page 3: Gran Paradiso - Firefox Gran Paradiso (proposed clarification) - 2.3 page 5: i.e. - i.e., - 2.5 page 5: the padding discussion doesn't apply for the Counter mode. I believe the problem is in the wording and is a side-effect of the mode + IPsec shaky structure of the document. - 3 page 7: there should be nothing about IPsec in this section. - 3.1 page 7: there *must* be a MUST about IVs in this section, you can't wait for the IPsec use! - 3.2 page 7: need not be - needs not to be (nonce value) - 3.2 page 7: that is making use - using - 3.2 pages 7 and 8: remove academic paper stuff From Pipelining is... to ...before the packet arrives. - 3.2 page 8: the IKE stuff is not at the right place. BTW how IKE can provide the nonce value? - 3.2 page 8: the last line (about [12]) just says either 3.2 is not normative and should not be there, or there are two competing specs of the same thing. Both very bad... - 3.3 page 10: same concern about the last sentence. - 3 pages 7-10: if there are some limits about the number of blocks in a mode, this is the right place. - 4.1 page 11: IMHO there should be only one MUST for the IV (and it should be unpredictable of course). - 4.2 page 12: the Authentication Data is not a part of the mode. - 4.2.1 page 13: need not be - needs not to be - 4.2.1 page 13 (twice): beginning - establishment - 4.2.2 page 13: this section is not at the right position (move it!) - 4.3.4 page 15: same that 4.2.1 (need, beginning (2)) - 5 page 17: use/using (bad wording) - 5 page 17: is camellia usable by IKE itself (if it is not (defined), please say it). - 5.1 page 17: explain where is the key length - 6 page 19: I don't believe it is useful to explain the IV issue, a reference should be enough. - 8 page 22: Acknowledgements - Acknowledgments Regards [EMAIL PROTECTED] PS: how to solve my main concern: I believe there are (at least) two solutions: either have a mode document and refer to it (with a copy of requirements) in an IPsec use separate document; or keep one document with both mode and IPsec use specs. In the second case, I believe a mode first IPsec details second organization for sections 3 and 4 is far better. And don't forget test vectors as an all-in-one document should be self contained. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-bfd-multihop-06.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-bfd-multihop-06.txt Reviewer: Francis Dupont Review Date: 2008-06-03 IESG Telechat date: 05 June 2008 Summary: Almost ready Comments: my concerns are editorial but as one is about the structure of the document I can't assume you can leave them to the RFC Editor: - 3.2 page 3: Signalling - Signaling - 3.2: BFD's - BFD (which is not a person) - 3.3: which must exist - which should exist (as there are cases where unidirectional links without a return path are useful (and used), even the document doesn't apply in these cases) - 5 page 4: I have a concern about this section: IMHO it should be the Security Considerations. This should solve a second concern about the empty Security Considerations when there is at least something about security. - Normative Refs page 5: don't forget you may provide Informational References. For instance IMHO OSPFv2, OSPFv3 and perhaps also BFD-MPLS should be only informative. - page 5: usually Security and IANA Considerations are sections and are before References. - Boiler plate page 7: Acknowledgement - Acknowledgment (if you know where your boiler plate comes from, please warn its author) To understand the document I read some other BFD I-Ds so I have a concer about draft-ietf-bfd-base-08.txt: IMHO it is not a good idea to standardize today a MD5-based authentication. I suggest to switch to SHA1 (I assume it should be kept for compatibility with current deployed implementations) and a SHA2 (SHA224 or SHA256) -based one. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pwe3-pw-atm-mib-05.txt
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-pwe3-pw-atm-mib-05.txt Reviewer: Francis Dupont Review Date: 2008-06-24 IETF LC End Date: 2008-06-24 IESG Telechat date: unknown Summary: Not Ready Comments: I have (too) many editorial concerns. Even the MIB part is to be processed by machines (vs. humans) it should be written with a minimal care. In details: - TOC page 2: Acknowledgements - Acknowledgments - 1 page 3: Network(PSN) - Network (PSN) - all abbrevs must be introduced (or replaced when they are used once). For instance PWE3 has to be introduced... - AN ATM - An ATM - MIBS - MIBs (twice. The rule itself doesn't matter but there should be a rule and this rule must be applied). - 3 page 4: a ATM - an ATM (twice) - net - network - BTW IMHO you should introduce some ATM terminology too, for instance VP and VC. - 5 page 5: VP and VC abbrevs should be introduced (including the VPI/VCI related abbrevs). - cells transmit - Cells transmit - replace OAM and ILMI by their definitions. - 6 page 6: is it PWE MIB or PWE3 MIB? - 8 page 7: I suggest a ':' after Table (and before the first '-'). - 1: 1 - 1:1 (many) - 9 page 8: please add the Country USA in addresses. - 9 page 9: the RFC Ed. comments have a string problem. - 9 page 11 and 12: please put a '.' at the end of description strings. (also pages 14 (twice), 17, 18 (twice), 20) - 9 page 12: (3).Unless - (3). Unless - 9 page 14: description strings should get an uniform identation (twice). (and pages 30, 32) - --Generic - -- Generic - 9 page 15: interuppted - interrupted - 9 page 16: .e.g. - e.g., - 9 page 17: please use the same case for all V[pP][iI] and V[cC][iI] (many) (and page 20) - 9 page 18: a ATM - an ATM (and page 21 - 9 page 33: for N:1 - for N:1 - 10 page 33: SNMPV3 - SNMPv3 - 10 page 34: the 'even if 'even then' seems strange (perhaps it is just something I don't know?) - 12.1 page 35: please put the name of the drafts. - 13 page 36: Acknowledgements - Acknowledgments Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-isis-rfc2763bis-00.txt
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-isis-rfc2763bis-00.txt Reviewer: Francis Dupont Review Date: 2008-06-25 IETF LC End Date: 2008-06-23 IESG Telechat date: unknown Summary: Almost Ready Comments: I have some editorial concerns: - first, as it is an update it should be fine to provided a temporary (i.e., marked as to be removed before publication) section about the changes from the RFC 2763. This would refrain me to raise concerns shared by the RFC 2763... - Copyright page 1: if (and *only* if) you issue a new version don't forget to update the year. - Abstract page 2: put Abstract from center to left - 1 page 4: a reference for IS-IS should be fine. And please add a statement about the use of IS-IS as an IP routing protocol (or I'll ask why you don't discuss about X.500 in place of DNS :-). - 1 page 4: the abbrev LSP should be introduced. - 2 page 5: there is a DNS RR for CLNS NSAPs, it is the NSAP RR. So I propose to replace A and PTR by a text like address and reverse. - 2 page 5: CLNS and TLV abbrevs should be introduced, and IMHO before section 2. - 3 page 5: the FQDN (Fully Qualified Domain Name) abbrev should be introduced. BTW the subset of the FQDN doesn't make sense, it is just a Domain Name. - 3 page 5: you have to be more accurate about the representation of DNs, obviously you'd like the textual representation (not the DNS on wire one with name compression, wouldn't you?) - 4 page 6: it's - its - 6 page 6: Others to be provided So provide some? - 8.2 page 9: RFC 2119 should be normative. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-capwap-dhc-ac-option-01.txt
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-capwap-dhc-ac-option-01.txt Reviewer: Francis Dupont Review Date: 2008-07-10 IETF LC End Date: 2008-07-14 IESG Telechat date: unknown Summary: Ready with nits Comments: I have two general questions and the usual editioral things (here editorial means they can be handled by the RFC Editor): - the first general question is about references to DHCP: * the whole document, including the Abstract, assumes the reader already knows what is DHCP. I have no concern about this but perhaps I should? I propose to keep this point closed until someone else raises it (so it could enter into the any other LC comments) * 1.2 (Terminology) is only about CAPWAP, IMHO even you don't abuse of DHCP specific terms it is a good place to add DHCP references (the three at the beginning of the Security Considerations for instance). - the second question is about the use (or abuse) of 2119 keywords at unusual places, namely in the Introduction (i.e., before the 2119 reference) and in the IANA Considerations. But it is only a question of usage/style... - in TOC and section 6: Acknowledgements - Acknowledgments Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-capwap-dhc-ac-option-01.txt
In your previous mail you wrote: - in TOC and section 6: Acknowledgements - Acknowledgments PRC I think perhaps your version is the queen's english, while mine is the one accepted in the US :( = there is no (not yet?) gen-art review FAQ but if the two spelling exist the RFC Editor loudly insists to use the one without the 'e'... Thanks [EMAIL PROTECTED] PS: you should have noted Ralph Droms' comment about v4/v6 option naming. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-pce-interas-pcecp-reqs-06.txt
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-pce-interas-pcecp-reqs-06.txt Reviewer: Francis Dupont Review Date: 2008-07-24 IETF LC End Date: 2008-07-31 IESG Telechat date: unknown Summary: Ready Comments: some edtorial problems and suggestions (editorial means they can be handled my the RFC Editor): - 1 page 2: the LSP abbrev should be introduced - 3 page 4 (or before): the ASBR one too (perhaps in 2?) - 3 page 5: I suggest to move the figure 1 at the beginning of section 3 - 3.1 page 5: have proven - have been proven ? - 4 page 6: perations - operations - 4.1.1 page 6: another abbrev to introduce: SRLG - 4.2 page 8: change inner '-' by another character like '*' - 4.3 page 8: This document addresses new requirements ^^^ IMHO the term suggests too much the document solves when it only specifies what are the requirements - 4.3 page 8: The PCEP MIB - The PCEP MIB (extra space) - 8 page 12: add USA in the first address (MA is not (yet) a Country) Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pwe3-pw-tc-mib-14.txt
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-pwe3-pw-tc-mib-14.txt Reviewer: Francis Dupont Review Date: 2008-08-19 IETF LC End Date: 2008-08-14 IESG Telechat date: 2008-08-14 Summary: Almost Ready Comments: I apologize for this late review (I lost the disk of my laptop). I share the concern about the naming of some textual conventions: - extra Type or TC - Identifier vs ID (I prefer ID/shorter names) Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dime-diameter-api-07.txt
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-dime-diameter-api-07.txt
Reviewer: Francis Dupont
Review Date: 2008-08-20
IETF LC End Date: 2008-08-08
IESG Telechat date: unknown
Summary: Not Ready
Comments: my main concern is the API as it is described up to section 3.7
is clearly impossible to implement so I strongly suggest to add soon
(in section 2 for instance) some text explaining the document only
specifies the visible/public part of some structures.
Another issue is most of the include part is missing.
Detailed comments:
- 1 page 4: code need only - code needs only
- 2.2 page 6: All of the functions - All functions ?
- 2.5 page 6: a DTD described it - a DTD describing it
- 2 page 6: IMHO this is the right place to explain the structs
defined in the document are the visible/public part of the real/internal
structs with a reference to section 3.7
- 3.1.12 page 10: if - when ?
- 3.1.15 page 12: the header (six, four) is obviously about a previous
version...
- 3.1.15 page 12: IMHO you should explain why, despite the name flags,
it is right to use an enumeration here (exclusive values, etc).
- 3.1.16 page 12: AAAGetDomainInterconnectType() doesn't return
this type (cf. 3.4.3.7) and it is not AAAGetDomainInternconnectType()
^
- 3.2.3 page 15: this type should be opaque, i.e., the name of the
fields should be private. This has two consequences:
* users don't know the names so can't misuse them (they have
AAAGetFirstAVP() co)
* it justifies a bit the *avpList in the next section (in place
of plain avpList)
BTW in a traditional double-linked list with tail pointer the
tail is a ** pointer
- 3.2.4 page 16: extra *Version fields (unneeded with AAA_IP_ADDR)
- 3.4.3.7 page 24: type should be a AAADomainInterconnect *
- 3.4.4.6 page 27: AAAGetCommandCode() must return an AAAReturnCode
and the return value text be updated to the usual one
- 3.4.5.4 page 29: occured - occurred
- 3.4.5.6 page 30: AAACreateAndAddAVPToList() is underspecified:
* can be the avpList created when it points to NULL?
(cf next section)
* what is the position when the list is not empty?
- 3.4.5.[67] pages 30 31: there is no way to free an AAA_AVP_List
so what to do if something fails? Obviously there are some use
restrictions so at least a reference to 3.6 is wellcome
- 3.4.5.1[45] page 34 (comment): obviously AAAGet{Next,Prev}AVP()
imply link fields in the real AVP struct!
- 3.4.6.1 page 36: extra ipVersion field
- 3.4.6.2 page 36 (comment): again the server id is an internal
AAAMessage field
- 3.6 page 38: (for uniformity)
(char *) ourAddress - (char *)ourAddress
- 3.7 page 39: this is a key point but one has to read ~40 pages
to find it. Note there are other ways to handle public/private
fields in C (but no highly recommended ways):
* the sub structure way (document's one)
* private fields at the end of the definition with a comment
explaining they are private
* private fields at the end of the definition protected by a #ifdef
I prefer the second one (no cast, sizeof() works but it relies
on the programmer's discipline) but you should simply give the
choice to implementors
- 3.9 page 41: 3.1.13 specifies there can be only one first/last,
for instance:
AAA_APP_INSTALL_FIRST: Install this callback as the first callback
in the chain. If subsequent callbacks are installed with this
code, then AAA_ERR_ALREADY_REGISTERED is returned.
so 3.1.13 and 3.9 are in conflict (note I prefer 3.1.13)
- 7.2 page 45: where are the DIAM_AVP_* co defined?
I am afraid you have to add them...
- Author's Addresses page 46: please add the Contry (USA? :-)
- I'd like to have a .h in annex (note the names of the .h and
of the DLL/library/... are part of the API)
Regards
[EMAIL PROTECTED]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] concerning draft-ietf-smime-ibearch-09.txt
I reviewed for the gen-art the version 05 of this document. My main concern, the missing ASN.1 summary, was addressed and no more stands for an informational document (but please keep it :-). Almost all other comments were editorial, BTW the last one (add USA in Author's Addresses page 34) still applies (AUTH48 was created to fix this kind of things, and I read some days ago a comment in the IETF mailing list saying postal addresses should explicitely include the country even it is USA, comment I subscribe). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mpls-ldp-igp-sync-03.txt
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-mpls-ldp-igp-sync-03.txt Reviewer: Francis Dupont Review Date: 2008-11-12 IETF LC End Date: 2008-11-18 IESG Telechat date: unknown Summary: Almost Ready Comments: I have many editorial concerns: - Abstract page 1: use of abbrevs (LSP, LDP, VPN, IGP). IMHO only IP and MPLS are supposed to be known by everybody... (note the Abstract is considered as an autonomous text for that) - Abstract page 1: e.g. - e.g., - ToC page 2: * With - with ? * Author's - Authors' * Acknowledgements - Acknowledgments - Abbrevs: as the document *heavily* uses abbrevations I propose to reference as early as possible (i.e., before the first abbrev) a place where the terminology (including abbrevs) is defined. - 1 page 2: i.e. - i.e., - 1 page 2:a L2 - an L2 ? - 1 page 3: can not - cannot ? - 2 page 4: can not - cannot ? - 4 page 5 (title): With - with - 5 page 5: trigged - triggered ? - 9 page 6: Author's - Authors' - 10 page 8: Acknowledgements - Acknowledgments - 10 page 8: please move Acknowledgments before the Copyright Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-smime-3851bis-08.txt
In your previous mail you wrote: I checked with some people on renaming the receipentKeyId field to recipientKeyid, and it's a no go. That name is used by compilers to name C code and changing it is going to cause problems. It's also been mispelled since about 1999 and nobody has said anything ;) I added a note in the ASN.1 that says: = my spell checker complained so I believed it was just a typo... -- receipentKeyId is spelt incorrectly, but kept for historical -- reasons. = I am fine with this. Thanks [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-tsvwg-admitted-realtime-dscp-05.txt
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-tsvwg-admitted-realtime-dscp-05.txt Reviewer: Francis Dupont Review Date: 2008-11-19 IETF LC End Date: 2008-11-27 IESG Telechat date: unknown Summary: Ready Comments: I have minor editorial (== to be handled by default by the RFC Editor) concerns and proposals (ending by '?'): - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: I suggest to introduce the EF (Expedited Forwarding) abbrev as soon as possible, i.e.: Expedited Forwarding - Expedited Forwarding (EF) - 1 page 3: the CAC (Call Admission Control) abbrev must be introduced, i.e.: CAC - Call Admission Control (CAC) - 1 page 3: I don't like aka (use i.e., in place of it, or no abbrev?) - 1 page 3: I'd like to get a reference for e-911 - 1 page 3: e.g. - e.g., - 1 page 3: the policy ... need - the policy ... needs ? - 1 page 4: i.e. - i.e., - 1.1 page 4 (PHB): introduce the DS (Differentiated Services) abbrev here? - 1.1 page 4: the not-introduced PSTN abbrev is questionable. IMHO you should keep it (common abbrev and not necessary for understanding). - 2.1 page 8: more questionable for SLA abbrev. - 2.1 page 8: conaining - containing - 2.1 page 8: MBPS is *not* an acceptable unit (I propose Mbits/s) - 2.2 page 9: reployed - deployed - 2.2 page 10: eg., - e.g., - 2.3 page 10: AAA abbrev: questionable but IMHO should be kept. - 3 page 11: Video classes - Video classes: ? - 6 page 12 (title): Acknowledgements - Acknowledgments - 6 page 12 (last character): , - . Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-pkix-ecc-subpubkeyinfo-10.txt Reviewer: Francis Dupont Review Date: 2008-12-03 IETF LC End Date: 2008-12-09 IESG Telechat date: 1008-12-18 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - the Abstract mentions RFC 3279 when the body of the document uses only the reference [PKI-ALG]. The standard solution should be to add the reference into the Abstract but it is forbidden so I propose to add the title of RFC 3279 in the Abstract. - TOC page 2: Acknowledgements - Acknowledgments - 1 page 2: I propose to add RFC 3279 before the first [PKI-ALG] - 2.1 page 4: This value is also used when a key is used with ECDSA. wording can be improved if the word used is not used twice? - 2.1.1 page 5: The AlgorithmIdentifier within subjectPublicKeyInfo is the only place ... formally the AlgorithmIdentifier is the type of the field, not the field name so is not a place - 3 page 7: at the first occurrence: CA - Certification Authority (CA) - 3 page 8: at the first occurrence: EE - End Entity (EE) - 4 page 10: please either add a reference for the MOV (Menezes, Okamoto and Vanstone) condition or improve the the wording making clear the whole sentence is referenced by [X9.62]. - 4 page 10: IMHO it is not really necessary to add references for MD2 and MD5. - 6 page 11: in NIST's arc - in the NIST arc - 7 page 11: Acknowledgements - Acknowledgments - 8.1 page 12: Standards for Efficient Cryptography - Standards for Efficient Cryptography Group (SECG) Regards [EMAIL PROTECTED] PS: I don't comment about the technical details (I believe a consensus was reached even this took a long time and many messages :-) and I assume the ASN.1 part was (or will soon be) checked with dedicated tools. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] about draft-daboo-imap-annotatemore-16.txt
I have no reason to change my review (of the -15 version) summary from Ready to something else. BTW I maintain my *minor* editorial concerns in 4.1 page 7 (spurious minimum words) and 4.2.2 page 10 (e.g. without the mandatory ','). Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-softwire-mesh-framework-05.txt
In your previous mail you wrote: the document is very unpleasant to read That would have to be regarded as a comment which is not actionable ;-) = if you find a magical way to improve the wording it should be very great (as a not native English writer I understand the issue but the first intent of a RFC is to be read...). too many authors We intend to leave the set of authors as is, and intend to remove the notation (editor). In my opinion, this is not an appropriate topic to be mentioned by a gen-art reviewer. = this was not directed against you but: - automatic checking tools will complain - it is an IESG policy and I am afraid the IESG enforces its policies. BTW a gen-art review is only an independent review so the IESG does what it'd like with it, including ignore or overrule. (the only technical issue) there is no more a main mode in IKEv2. BTW the text seems to mandate preshared keys when IMHO it requires only automatical SA establishment (better than key distribution). There have been a couple of security reviews, and this issue did not come up, = this just proves another review is always a good thing (:-). so I'm not sure what to make of this comment. = for the main mode you should remove it. cf RFC 4306, Appendix A, 2: 2) To simplify IKE by replacing the eight different initial exchanges with a single four-message exchange For the second part, if the with the preshared keys came with the in main mode the best and simplest is to remove the end of the sentence, i.e.: means of IKEv2 [RFC4306], operating in main mode with preshared keys. - means of IKEv2 [RFC4306]. Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-andreasen-sipping-rfc3603bis-07.txt
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-andreasen-sipping-rfc3603bis-07.txt Reviewer: Francis Dupont Review Date: 2008-12-24 IETF LC End Date: 2009-01-10 IESG Telechat date: unknown Summary: Ready Comments: some minor editorial concerns (i.e, to be fixed bt the RFC Editor): - Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an autonomous text, the abbrev is not used so is useless, etc) - ToC page 3: Acknowledgements - Acknowledgments - 1 page 5: this is the right place to introduce the SIP abbrev, i.e., SIP - Session Initiation Protocol (SIP) [RFC3261] - 2 page 6: the DCS abbrev is never introduced - 5 page 10: the UAC abbrev is not introduced, IMHO you should find a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary). - 5.1 page 11: .The trace-param - . The trace-param - 8 page 25: ccc-id - cccid (for uniformity) - 8.3 page 28: The UAC may also include a P-DCS-Redirect header. - The UAC MAY also include a P-DCS-Redirect header. (IMHO according to the context this should be the uppercase keyword) - 8.5 page 28: .Otherwise, - . Otherwise, - 12 page 37: Acknowledgements - Acknowledgments - 12 page 37: Tung- Hai - Tung-Hai ? - 13.2 page 38: please use the long names for months (first 4 entries) Don't forget you have expert review and IANA comments in the ID tracker. Regards francis.dup...@fdupont.fr PS: I don't comment about the lawful interception stuff. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-ccamp-gr-description-03.txt
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-ccamp-gr-description-03.txt Reviewer: Francis Dupont Review Date: 2009-01-15 IETF LC End Date: 2009-01-20 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: there are 4 authors in 11 (Authors' Addresses) but 3 only in front (first page). I am afraid Snigdho Bardalai was forgotten during some edits... Nits/editorial comments: - 4 page 7: P2MP - point to multi-point - 5.2.2 page 10: Path_State_Reomved - Path_State_Removed - 6 page 13 figure 2: resoure - resource and resouces - resources - 7 page 15: travelling - traveling - 11 page 17: CA 95134 - CA 95134 Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-ccamp-path-key-ero-03.txt
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-ccamp-path-key-ero-03.txt Reviewer: Francis Dupont Review Date: 2009-01-27 IETF LC End Date: 2009-02-03 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: IMHO it is just a typo but in 4 page 9: DNS - DoS Nits/editorial comments: - 7.1 page 12: Singlaling - Siglaling - 8 page 13: J.-P - Jean-Philippe Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-sdp-source-attributes-02.txt
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-mmusic-sdp-source-attributes-02.txt Reviewer: Francis Dupont Review Date: 2009-02-05 IETF LC End Date: 2009-02-09 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Abstract page 1: The Session Description Protocol - ... (SDP) - 3 page 4: receivers (who may never - receivers (which may never - 3 page 4 (twice): i.e. - i.e., - 4 page 5: synchronizaton - synchronization - 9 page 12: defintion - definition - 10 page 12: 0 - 2**32 - 1 - 0 .. 2**32 - 1 - 12.3 page 15: gropuing - grouping - Authors' page 18: NJ 07601, US - NJ 07601, USA Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] about draft-ietf-ccamp-gr-description-04.txt
All (minor/editorial) comments about the previous version were solved. I maintain the Ready summary. Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-iana-rfc3330bis-06.txt
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-iana-rfc3330bis-06.txt Reviewer: Francis Dupont Review Date: 2009-04-03 IETF LC End Date: 2009-04-18 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I have two concerns about the Abstract: - the first sentence This document obsoletes RFC 3330. should be removed before the publication as an RFC - the last sentence has an explicit reference to RFC 5156, this could be considered as forbidden in an Abstract, I propose to change it into: ... are described in another document (RFC 5156). In authors' addresses: United States - United States of America (there is an incredible amount of countries with a full name translating into united states in English :-). Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] about draft-ietf-ccamp-path-key-ero-04.txt
I reviewed the version 03, I keep the Ready summary. Regards francis.dup...@fdupont.fr PS: the spelling error in 7.1 page 12 only changed, correct spelling (checked twice as it seems really hard to type :-) is: signaling (leave it to the RFC Editor...) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mpls-p2mp-te-mib-08.txt (summary)
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-mpls-p2mp-te-mib-08.txt Reviewer: Francis Dupont Review Date: 2009-04-16 IETF LC End Date: 2009-04-17 IESG Telechat date: unknown Summary: Ready Regards francis.dup...@fdupont.fr PS: I'll send full comments tomorrow morning. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mpls-p2mp-te-mib-08.txt (full)
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-mpls-p2mp-te-mib-08.txt Reviewer: Francis Dupont Review Date: 2009-04-16 IETF LC End Date: 2009-04-17 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Abstract: add '(MIB)' as it is done in the introduction - Abstract: if you need to enforce the do-not-cite-rfc in the Abstract put reference to RFC 3812 and 4802 into parenthesis? - 4 page 5: remove spurious line break between: objects and tables some of which extend tables in MPLS-TE-STD-MIB [RFC3812]. [RFC4461] and [RFC4875] are clear that they apply to - 4.2 page 6: additional features or different behavior is required - are required - 4.2.1 page 8 (title): Compatiblity - Compatibility - 4.2.1 page 9: sematics - semantics - 4.2.2 page 10 (title): Compatiblity - Compatibility - 4.7 page 12: diagramatic - diagrammatic - 5.2 page 20 (multiple): SeesionAttribute - SessionAttribute - 5.2 page 24: thre - there - mplsTeP2mpTunnelRowStatus page 26: mplsTunneltable - mplsTunnelTable - mplsTeP2mpTunnelDestOperStatus page 47: aply - apply and destinaton - destination - mplsTeP2mpTunnelDestUp page 51: mplsTeP2mpTunneldestOperStatus - mplsTeP2mpTunnelDestOperStatus - Module Conformance Statement page 52: remove spurious line break between: for MPLS-TE-P2MP-STD-MIB. Such devices can be monitored and also be configured using this MIB module. - 8 page 56: please extend the VACM and USM abbrevs. - 8 page 57: IPSec - IPsec (BTW if the common way to deploy IPsec is to use it for infrastructure protection, IPsec can also be used with a finer grain for application protection, i.e., transport mode vs. tunnel mode) - 12 page 60: please add the country in Thomas' address. Regards francis.dup...@fdupont.fr PS: experience has shown spelling errors in MIB ids can't be fixed (because of backward compatibility). IMHO we should have a specific tool to help this spelling check. I sorted the output of a spell checker so I got some (fortunately in comments)... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-pce-monitoring-04.txt
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-pce-monitoring-04.txt Reviewer: Francis Dupont Review Date: 2009-04-22 IETF LC End Date: 2009-04-27 IESG Telechat date: unknown Summary: Not Ready Major issues: none but some minor issues which should need another cycle. Minor issues: - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8 IMHO it is the right place to introduce them, for instance (it should be hard to be simpler) add after the first path computation request the comment (PCReq message). Perhaps this is not the right thing but it should be clear from the introduction the document both specifies new messages and new objects, and these new objects can be used in PCReq/PCRep too. - 4.1 page 12: incompatible requirement There SHOULD NOT be more than one instance of the MONITORING object with PCRep syntax (response-list) - 4.1 page 13: even if MONITORING object has no optional TLV currently defined, the format of these TLVs must be specified. I propose the PCEP generic TLV format, RFC 5440 7.1. - 4.3 page 16: the variance of time is a squared time. I propose to switch to standard deviation (ecart type in French, the square root of the variance) - 8.6 page 23: CONGESTION object has no defined flag. (this is not editorial because of IANA review/processing) Nits/editorial comments: - Abstract page 2 is in one block, I suggest to insert a line break before In PCE-based - Requirements Language page 2 should be moved in the terminology section - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values - New Error-Values - ToC page 3 and 10 page 23: Acknowledgements - Acknowledgments - 1 page 4: IGP - Interior Gateway Protocol (IGP) - 1 page 4: troubeshooting - troubleshooting - 1 page 4: more than one PCE is - are? - 1 page 4: BRPC - Backward Recursive PCE-based Computation (BRPC) - 1 page 5: bolean - boolean - 1 page 5: By In band - By in band - 1 page 5 and many other places: e.g. - e.g., - 3 page 6: PCEMonReq - PCMonReq - 3 page 6: too many in this document (wording) - 3.1 page 8: insert a line break between: svec-list::=SVEC[svec-list] request-list::=request[request-list] - 3.1 page 8: Section 4.2.) - Section 4.2) - 3.1 page 8: charaterize - characterize - 3.1 page 9: PCMonreq - PCMonReq - 3.2 page 11: PROC-TIME and CONGESTION are defined further (8.[56]). where NO-PATH is defined? - 4.1 page 13: choose between Monitoring-id-number and monitoring-id-number - 4.1 page 13: a wrap back to one is unclear, 0x + 1 == 0, not 1. If the value zero is reserved this should be more explicit. - 4.3 page 15 1): Min, Average, Max and Variance - minimum, maximum, average and variance - 4.2 page 15 2): Procesing-time - Processing-time - 4.4 page 17: currently defined: - currently defined. - 6 page 18: value=Reception of an unacceptable number of unknown PCEP message. - value=5 Reception of an unacceptable number of unrecognized PCEP message. (i.e., put the reason value and correct meaning with a closing , BTW there are two occurrences to fix) - 6 page 19: in the next hop PCE: such next-hop choose between next-hop and next hop (I prefer the second). - 6 page 19: extra Upon receiving a PCMonRep message - 6 page 19: carrries - carries - 6 page 19: Multi-destination - multi-destination - 8.2 page 20 (last line): are defined in this document. - are defined in this document: - 8.3 page 21: as it doesn't define new error-type(s) I propose: New Error-Type and Error-Values - New Error-Values - 8.3 page 21: has been created - was created? - 9 page 23: denail - denial - 9 page 23: shapping - shaping - 10 page 23: Acknowledgements - Acknowledgments (IETF spelling) - 11 page 23-24: take the occasion to update references, for instance: I-D.ietf-pce-pcep - RFC5440 (this is usually done by the RFC Editor but as it seems you should publish a new/fixed version of the document..,) Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-sipping-update-pai-09.txt
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-sipping-update-pai-09.txt Reviewer: Francis Dupont Review Date: 2009-05-06 IETF LC End Date: 2009-05-11 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: IMHO the Abstract should be reworded a bit before publication (RFC Editor could handle this) Nits/editorial comments: - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: the right place to introduce common abbrevs: UAC, UAS, URI... - 2 page 3: UAC and URI abbrevs should be introduced - 2 page 4: same for UAS - 3.1 page 4: same for PSTN (I suggest in o PSTN gateways;) - 3.2 page 6: poor wording: with methods that are not provided for in RFC 3325 or any other RFC. - 7 page 10 (title): Acknowledgements - Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-sipping-update-pai-09.txt (resent)
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-sipping-update-pai-09.txt Reviewer: Francis Dupont Review Date: 2009-05-06 IETF LC End Date: 2009-05-11 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: IMHO the Abstract should be reworded a bit before publication (RFC Editor could handle this) Nits/editorial comments: - Behaviour - Behavior (i.e., American spelling) - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: the right place to introduce common abbrevs: UAC, UAS, URI... - 2 page 3: UAC and URI abbrevs should be introduced - 2 page 4: same for UAS - 2 page 4: standardised - standardized - 3.1 page 4: same for PSTN (I suggest in o PSTN gateways;) - 3.2 page 6: poor wording: with methods that are not provided for in RFC 3325 or any other RFC. - 6 page 10: standardised - standardized - 7 page 10 (title): Acknowledgements - Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-isms-secshell-16.txt (partial)
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isms-secshell-16.txt Reviewer: Francis Dupont Review Date: 2009-05-07 IESG Telechat date: 07 May 2009 Summary: none as draft-ietf-isms-secshell-17.txt was published before I finished the review... Comments are about the not-MIB part (i.e., not the section 7) and of course about the version before the update. Major issues: none in the read part Minor issues: - STD 62 (aka SNMPv3 aka RFC341[1-8]) must be explicitely cited Nits/editorial comments: - ToC page 3: Acknowledgements - Acknowledgements - 1 and 1.1 page 4: move the (SNMP) from 1.1 to 1. - 1.2 page 4: STD62 - STD 62 (but it should be referenced in 1, not here) - 3.1.4 page 12: a SSH - an SSH (based on es es haish pronunciation) - 5.1 page 16 (twice): e.g. - e.g., - 5.1 page 17: move the ASI abbrev intro from 5.3 to here - 9.1 page 30: DH - Diffie-Hellman exchange - 11 page 33: Acknowledgements - Acknowledgements - 12.1 page 34: bad page layout (I-D.ietf-isms-transport-security-model too long for the tool) - Authors' Addresses page 38: US - USA Regards francis.dup...@fdupont.fr PS: note you have some comments about -17 version from IESG. As I've seen a Revised ID Needed I (or another gen-art reviewer) wait for a -18... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-sip-eku-05.txt
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-sip-eku-05.txt Reviewer: Francis Dupont Review Date: 2009-06-02 IETF LC End Date: 2009-06-05 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: (I apologize to have been late to send this review) - 1.2 page 3: X.680 [5],X.690 [6]. - X.680 [5], X.690 [6]. - 3 page 4: the application need not recognize - needs??? (BTW the spelling error, if it is an error, is in RFC 5280) - 9.1 page 7: IMHO (and shown by experience) numbering of references can lead to problems... I suggest to go to named references for next documents, in particular if they are longer. Regards francis.dup...@fdupont.fr PS: I don't comment about the EKU idea, I've seen some PKI experts in Acknowledgments so I expect you do the right thing. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sipping-cc-framework-11.txt
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-sipping-cc-framework-11.txt Reviewer: Francis Dupont Review Date: 2009-06-09 IETF LC End Date: 2009-06-09 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in Abstract page 2: SIP - Session Initiation Protocol (SIP) - ToC page 3: Far fork - Far-fork (or Near-fork - Near fork but fixing the far branch seems better) - Toc page 4: Acknowledgements - Acknowledgments (IETF/RFC Editor spelling) - 2.3 page 10: the UA abbrev should be introduced (and IMHO far before) - 2.4.2.1 page 12: large- scale - large-scale - 2.6.7.2 page 17: the IVR abbrev must be introduced - 3.3.2 page 26: from controller) - from controller): - 3.3.2 page 26: i.e. - i.e., (same for other i.e. and e.g.) - 3.3.5 page 28: a central mixer) - a central mixer). - 3.3.8 page 29 (title): Far fork - Far-fork - 3.2.8 page 30: forked-media - forked media ? - 4 page 30: The class ... include - includes ? - 6.31 page 39: (ex: - (e.g., - 7 page 39 (title): Acknowledgements - Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] draft-ietf-sip-eku-05.txt
In your previous mail you wrote: - 3 page 4: the application need not recognize - needs??? (BTW the spelling error, if it is an error, is in RFC 5280) I believe that in this context, need is grammatically correct -- needs not recognize... does not seem to read very well. = there are in fact two questions: - is need the verb and the application the subject, in this case this seems to be a spelling error - in a quote should a spelling error be fixed? IMHO it should not. So I put some '?' to mark I have no strong opinion about this. PS: I don't comment about the EKU idea, I've seen some PKI experts in Acknowledgments so I expect you do the right thing. Yes; the draft was socialized extensively with PKIX WG. We even had a WG meeting slot to present the work and solicit face-to-face comments from PKIX during the formation of the work. The LC in SIP also was CC'd to the PKIX WG and comments solicited from that as well. = I missed most of last PKIX WG meetings (I can't be at two places at the same time :-) but I know who are the leaders in this WG (and the mixed opinion about EKUs in the community). BTW it is a typical LC item (it should be hard to find a more typical thing :-). Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-iana-rfc3330bis-07.txt
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-iana-rfc3330bis-07.txt Reviewer: Francis Dupont Review Date: 2009-07-06 IETF LC End Date: 2009-07-22 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I have still (cf review of the 06 version) two concerns about the Abstract: - the first sentence This document obsoletes RFC 3330. belongs to the document meta-data and should be removed before publication - the last sentence has an explicit reference to an RFC. It should be repeated in the introduction or perhaps moved to the introduction. Note the RFC Editor is in charge of the style of Abstract so these points should be discussed with him/her. Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-simple-xcap-diff-13.txt
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-simple-xcap-diff-13.txt Reviewer: Francis Dupont Review Date: 2009-07-15 IETF LC End Date: 3009-07-22 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 3 page 6: i.e. - i.e., - 3 pages 7 and 8: endoced - encoded - 4 pages 8-10: I am looking for a tool which can check the schema (something like MIB doctor, I've tried XSV...) - Authors' Addresses page 16: US - USA Regards francis.dup...@fdupont.fr PS (to gen-art): we need a tool to check XML schemas (it is easy to find one to check a document against a schema, not to check the schema itself). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-hokey-key-mgm-08.txt
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-hokey-key-mgm-08.txt Reviewer: Francis Dupont Review Date: 2009-07-30 IETF LC End Date: 2009-08-03 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: I understand this specification is very abstract about on wire entities (for instance there is nothing about encoding, etc) but this can become an issue about key labels, i.e., the reader has to read the (referenced) RFC 5295 if (s)he wants to know what are exactly these key labels (note the term label can denote many different things). I suggest to be lightly more reader friendly, for instance by writing the RFC 5295 establishes a IANA registry for USRK Key Labels too: for the specification of key labels - ... and associated IANA registry. Nits/editorial comments: [Usual RFC Editor style stuff] - ToC page 3 and 8 page 11: Acknowledgements - Acknowledgments - 1 page 4 and 6.1 page 10: e.g. - e.g., - 1 page 4, 2 page 5, 4 page 7 and 6.1 page 10: i.e. - i.e., - 6.2 pages 10 and 11: (suggestion) a RK - an RK - I give up about: handover - hand-over - 4 page 7 and 4.2 page 9: (suggestion) roundtrip - round-trip Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt
In your previous mail you wrote: Minor issues: - IMHO a transition paragraph is needed at the end of the Introduction in order to introduce technical dependencies: * clearance attribute is in fact from 3281bis (this is obvious when one reads the ASN.1 module appendix but it should be mentioned as soon as possible) I agree that's why it's in the last sentence of the 1st paragraph in the intro ;) = well, I missed it (:-). * the processings augment the RFC 5280 section 6 (so the text is understable only with this section in mind) It says this in section 4.1 and 5.1, but we could move something to the intro to explain that we're augmenting the 5280/3281bis processing rules. How about: This document augments the certification path validation rules for PKCs in [RFC5280] and ACs in [RFC3281bis]. = fine The whole idea is to prepare a first reader (IMHO it is a problem when a document needs to be read more than once to get a good idea about what it specifies :-). - another issue is the multiple values in a Clearance attribute. The Clearance attribute syntax of section 2 is in fact for an AttributeValue type and doesn't include multiple values (only multiple SecurityCategory). Of course the Attribute in AC can contains multiple values, so the text often uses the term value in a very ambiguous way. We restrict the number of times clearance can be included in a certificate to one or zero. We also restrict it to be single valued. = this is what I understood but there are some places in the document where the term value is used about the clearance AttributeValue type, for instance inside AuthorityClearanceConstraints. Are you referring to the Authority Clearance Constraint extension that can include multiple values? = an extension can contain only one value embedded inside an OBJECT STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions with the same OID. So IMHO extensions and multiple values are exclusive. - 3 page 6: I don't understand this statement: In addition, each Clearance attribute in the SEQUENCE must not contain more than one value. perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)? SEQUENCE refers to the ASN.1 construct for the extension. We didn't capitalize sequence previously so we'll switch it to lower case. Note the must ought to be MUST. = but a AuthorityClearanceConstraints contains clearances, no clearance attributes, so what does mean the more than one value? - 4.1.1.2 page 8: can't understand: If any of the Clearance attributes in the permitted-clearances contains more than one value This check makes sure there is only one value in permitted-clearances. = the permitted-value is either all-clearances or a AuthorityClearanceConstraints, so there is no Clearance attributes in it, nor a value... - 4.1.1.5.1 page 9: in If the permitted-clearances has special value of all-clearances, exit with success. what about the effective-clearance (unchanged?) There's no need to set this value as it's the special case where it matches all. = the output is both the effective-clearance (with the - everywhere, including in 4.1.1.6) and success/failure, so all exists must specify both. - 8 page 15: what is id-TBSL? It stands for To Be Supplied Later. I guess now would be a good time ;) I need to get an OID from Russ we'll add this in the next version. = until you'll get one IMHO a comment should explain this (only TBD is recognized :-). To fix my main concern about the term value, as ASN.1 is not LISP (:-) I propose to typecheck all types where the term is used and to keep it when the type can contain a value (typically contain an attribute), remove it if it can't or replace it by SecurityCategory (or other?) if it is what you'd like to mean. francis.dup...@fdupont.fr PS: occurences of value: Abstract The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. = correct 1 Organizations that have implemented a security policy can issue certificates that include an indication of the clearance values held by the subject. = correct 1 Some organizations have multiple TAs, CAs, and/or AAs and these organizations may wish to indicate to relying parties which clearance values from a particular TA, CA, or AA should be accepted. = correct 1 a security policy has been defined for Amoco with three security classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and = correct 1 Cross-certified domains can also make use of
[Gen-art] review of draft-ietf-mpls-gmpls-lsp-reroute-04.txt
(Oops, it seems I forgot to forward this) 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-mpls-gmpls-lsp-reroute-04.txt Reviewer: Francis Dupont Review Date: 2009-08-31 IETF LC End Date: 2009-08-31 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: none Nits/editorial comments: - ToC page 2 and 8 page 12: Author's Addresses - Authors' Addresses - 1 page 3: i.e. - i.e., - 2.1 page 4: please introduce the ERO (Explict Route Object) abbrev (note the TLV abbrev is supposed to be common so doesn't need to be introduced, cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt ) - 2.1 page 5: IF_IF - IF_ID - 2.2 page 6 and 2.3 page 6: conformant - compliant - 2.2 page 6: Re-routing - re-routing - 2.2 page 6: is note - is not Note: the usage of rerouting/re-routing is not very uniform... Regards (and sorry for the delay) francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-mpls-gmpls-lsp-reroute-04.txt
In your previous mail you wrote: = oops, catching an old message. - 2.2 page 6 and 2.3 page 6: conformant - compliant Why? = just because conformant is not in my dictionary, compliant is and is supposed to mean the same thing... Now my dictionary is not universal and is British oriented (:-). Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-roll-building-routing-reqs-07.txt
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-roll-building-routing-reqs-07.txt Reviewer: Francis Dupont Review Date: 2009-09-29 IETF LC End Date: 2009-09-24 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - IMHO the document is a bit USA centric (but it is not a problem if it is stated in the document, for instance with a reference from the (US) building automation community, cf 8.2 comment below) Nits/editorial comments: - the language of the document is not at the usual level (but at it should be considered as better it is not a concern) - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14. 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20: e.g. - e.g., - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e., add (MS) after facility management system - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous: it can stand for point and the point-to-point term usually refers to link topology. I propose: P2P - (peer-to-peer, P2P) (MP2P) - (multi-peers-to-peer, MP2P) (P2MP) - (peer-to-multi-peers, P2MP) - 4 page 10 and 5.4.3 page 14: acknowledgement - acknowledgment (for uniformity with the section title where this spelling is enforced) (multiple occurrences) - 5.1 page 11: no network knowledge - no communication network knowledge - 5.2.2 page 13: even it is also overloaded: point-to-point - end-to-end - 5.4 page 14: i.e. - i.e., - 5.4.3 page 14: 2000mah - 2000mAh - 5.7.6 page 17: msec - ms - 7 page 19: J. P. - JP. - 8.2 page 19: I'd really like to get a reference from the building automation community: explaining networking to them or an introduction for us (networking community) or both. I expect there are at least some framework standards. - 9.1.2 page 19: 2.4Ghz - 2.4GHz (BTW the ISM band text is very USA centric :-) - 9.3.1 page 20: missing final '.' - Authors' Addresses page 22: unfinished (???), add +1 for USA phone number, -- - - (and BTW try to use the same separator) Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-connectivity-precon-06.txt
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-mmusic-connectivity-precon-06.txt Reviewer: Francis Dupont Review Date: 2009-10-12 IETF LC End Date: 2009-10-14 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 3.1 page 4: the precondition types don't include sec which is mentioned after (IMHO it is because it was added after the RFC 3312 cited the page before) - 5 page 10: succesful - successful - 5 page 10: prequisite - pre-requisite or prerequisite - 6 page 15: there are two des:conn in the last example, I believe it is a typo and the second is a conf:conn? - 7 page 15: TCP[RFC0793] - TCP [RFC0793] Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-6man-overlap-fragment-03.txt
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-6man-overlap-fragment-03.txt Reviewer: Francis Dupont Review Date: 2009-10-29 IETF LC End Date: 2009-11-02 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Personal comment as a IPv6 implementor: overlapping fragments have no utility in IPv6 so I never added code to support them. BTW the specs just didn't disallow them (at explained in the introduction but not in the Abstract) and most implementors didn't care. Some lazy copied the IPv4 code and removed the overlap support to get something simpler, some are so lazy they kept everything... But to explicitely disallow them is the right idea. BTW I remember an old paper about BRO (before the IDSs :-) where a fragmentation/segmentation overlap was found bad, so it is not new (i.e., it is older than IPv6...). Nits/editorial comments: - Abstract page 1: allows - does not disallow?? - Toc page 2: Acknowledgements - Acknowledgments - 2 page 3: the term 'check' is not enough because it is for protection, something like 'security check' should be better (but a bit too strong). - 3 page 5: it is possible to get bad overlapping fragments from an error too (i.e., it is not always an attack, of course the action should be to drop the whole packet anyway). - 4 page 6: received), MUST - received) MUST? - 6 page 6: Acknowledgements - Acknowledgments Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] re-review of draft-ietf-pkix-authorityclearanceconstraints-03.txt
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-pkix-authorityclearanceconstraints-03.txt Reviewer: Francis Dupont Review Date: 2009-08-10/2009-11-30 IETF LC End Date: 2009-08-14 IESG Telechat date: unknown Summary: Almost Ready Comments: the previous major issue was the I-D is too hard to read. All minor issues and NITs were addressed but I read the document enough times to be too familar with it so I can't say if the major issue is solved (but IMHO this version is already far better). So I put an almost and leave the assessment to someone else. Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-ccamp-lsp-dppm-10.txt
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-ccamp-lsp-dppm-10.txt
Reviewer: Francis Dupont
Review Date: 2009-11-28
IETF LC End Date: 2009-11-23
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: too many authors in Authors' Addresses (see below)
Nits/editorial comments:
- the document is heavily cut paste between sections. This makes it
like a MIB document so I have a mixed opinion about whether it is a
good thing: the document is very clear, each part stands by itself,
but it is a bit long and certainly boring to read.
- Abstract page 3: I prefer to get the LSP abbrev introducted
(the Abstract should stand by itself and LSP is not stared by
the RFC Editor as well known/doesn't need expansion)
- TOC page 6:
* extra space in 12. title
* Acknowledgements - Acknowledgments
- Introduction page 8: same concern about LSP (but in this case you can
consider it was introduced in the document title)
- 4.7 page 13 (and 5.7 page 16, 6.7 page 20, 7.7 page 24):
(T2 -T1) - (T2-T1)
- 4.8 page 13 (and 5.8 page 17, 6.8 page 20, 7.8 page 25, 8.8 page 29):
uppper - upper
- 6.6 page 20 (and 7.6 page 23):
Thus, In practice - Thus, in practice
- 8.8 page 29: eg. - e.g.,
- 12 page 39 (title): Bidirectional LSPs - Bidirectional LSPs
- 12.7.2.1 page 42 (first statement):
multiple bidirec... - Multiple bidirec...
- 18 page 49 (title): Acknowledgements - Acknowledgments
- Authors' Addresses:
* add a space after a comma (',' - ', ')
* CN - China (many!)
* Telecommunicaiton - Telecommunication?
* you have too many authors, I suggest to keep the two editors and
to put other authors in a contributors section. Look at the RFC
Editor site about how to do this.
Regards
francis.dup...@fdupont.fr
PS: spelling of Re[sS]erVation in RSVP is not uniform but this happened
12 years ago... too late to fix it.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt
In your previous mail you wrote: Now I see what gave you a pain... A series of unfamiliar abbreviations may hamper readability. Please take a look at the following style. The key words below are spelled out: = BTW I am familiar with most of these abbrevs (I worked a lot in Mobile IPv6 area) but it is just a matter of taste: the abuse of abbrevs is IMHO a bad style for a written text. And this includes the use English words the first time, introduce abbrevs and use them in place of plain English after. Please note it is a matter of taste and I am not against the use of abbrevs, just against the abuse. Regards francis.dup...@fdupont.fr PS: I apologize for the delay (travel, mail server crash, ...) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-brown-versioning-link-relations-05.txt
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-brown-versioning-link-relations-05.txt Reviewer: Francis Dupont Review Date: 2009-12-23 IETF LC End Date: 2010-01-11 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - A.1 page 10: I don't know if it is by design or an unexpected side effect of xml2rfc but I don't understand why the section 1 of the appendix A is at this place... IMHO it should be(come) the appendix B. - Authors' Addresses page 13: (twice) US - USA Regards francis.dup...@fdupont.fr PS: I' like to know the real content of the draft.all aliases, of course tools.ietf.org MTAs refuse EXPN SMTP command... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
