[Gen-art] second/independent view on draft-ietf-softwire-map-10.txt
I reviewed the draft-ietf-softwire-map-10.txt document but I was too involved in Softwire stuff to be able to judge whether the text is understable without prior knowledge. Can someone from the team look at it and summary in the list? 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-ietf-softwire-map-10.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-map-10.txt Reviewer: Francis Dupont Review Date: 20141009 IETF LC End Date: 20141010 IESG Telechat date: 20141016 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: First please note I participated to Softwire WG work so it is possible the document is not understantable by someone who has no knowledge about the topic. I'll ask another member of the gen-art team to look at it to check this particular point. Other comments: - there are more than 5 authors. RFC 7322 (the new RFC Style Guide) provides an accurate (i.e., more than previously) indication about this problem. - ToC page 2 and 13 page 20: Acknowledgements -> Acknowledgments - 1 page 3: (FYI comment): RFC 1933 automatic tunneling was historically the first way to run IPv6 (end of March 1995 when IPv6 over Ethernet ran only at the July IETF meeting the same year). So in fact the RFC was published in 1996 but the mechanism itself was implemented a year before... - 1 page 4: IMHO there is no need to expand the MAP abbrev at its first use because it is in the title (note this would not apply if it was in the Abstract). - 1 page 4: provider's(SP) -> provider's (SP) - 3 page 5: NAPT should be in the terminology, in particular because the standard abbrev is more NAT-PT - 3 page 5 and many other places: e.g. -> e.g., and i.e. -> i.e., - 4 page 6: encapsulation/ -> encapsulation / - 4 page 7: figure 1 should be in one page (the RFC Editor should take care of this in his final editing). - 5 page 8: a missing closing parenthesis in "MAP BR (see Section 5.4." - 5.1 page 8: minimise -> minimize - 5.2 page 10: /prefix -> / prefix - 6 page 13: figure 8 in one page (cf figure 1) - 11 page 19: glitch in the text version: "Attacks facilitated by restricted port set:" - 12 page 19 and 20, and Authors' Addresses page 32: CN is not a valid Country in a postal address, I suggest China or better P.R. China - A Example 3 page 25: please expand FMR in the example title. - A Example 5 page 26: avoid page break after a title - A Example 5 page 27 (twice): DHCP. -> DHCP - A Example 5 page 27: please expand BMR abbrev (i.e., make the text easier and more pleasant to read). 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-forces-packet-parallelization-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-forces-packet-parallelization-02.txt Reviewer: Francis Dupont Review Date: 20140930 IETF LC End Date: 20140929 IESG Telechat date: 20141002 Summary: Ready with nits Major issues: none Minor issues: none Nits/editorial comments: - Abstract page 1: the FE abbrev should be introduced (in particular one can believe it means ForCES Element in place of Forwarding Element) - ToC page 2 and 6 page 23: Acknowledgements -> Acknowledgments - 1 page 3: the ForCES abbrev must be introduced again (the Abstract is not a part of the document for this) - 1 page 3: same for LFB - 1 page 3 and 2 page 6: modelling -> modeling - 1 page 3 (multiple), 2 page 5 (twice) and 9.2 page 26 : Cilc -> Cilk (BTW the reference and wikipedia say Cilk :-) - 1 page 3: bad wording: "Being an experimental document the LFB Class IDs cannot be included..." - 1.2 page 3: FE itself should be in the list (likely the first item) - 1.2 page 3: same for CE... - 2 page 5: e.g. -> e.g., - 2.1 page 8, 4.3.3 page 15 and 5 page 17: (not a US vs UK sp!) LFBParallelOccurenceLimit -> LFBParallelOccurrenceLimit - 4.2.2 page 14: what is the MergeWaitTimeoutTimer unit? (if the answer is not trivial it should be added in the document) - 8 page 25: parallezation -> parallelization - Authors' Addresses: please add USA (not US as postal addresses require country names, not ISO IS 3166 codes (BTW VA is a valid 3166 code but English is not one of its official languages even wikipedia doesn't seem to have a very clear idea about them :-)). 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-appsawg-multimailbox-search-01.txt
In your previous mail you wrote: > Thanks, Francis, for the review. > > > first a meta-question: should this kind of documents refer to its > > parent, RFC 6237 (same subject but RFC 6237 is Experimental, the > > I-D is for Standards Track)? IMHO it should not (so the I-D is > > right) because this will be (only) mentioned in the RFC index. > > I'm not sure what you're asking: do you mean to muse about whether the > predecessor document should appear in the references section? => yes > If so, > I agree with your conclusion: it shouldn't... because the predecessor > document will be made obsolete by this one, and because there's > nothing in the predecessor to which this is referring (except to its > existence). => it is my reasonning too (and the fact there is a predecessor is in the RFC Index so is not lost). > > - ToC page 2 and 9 page 11: Acknowledgements -> Acknowledgments > > Doh! I've fixed the spelling in my working version; thanks. 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-ietf-appsawg-multimailbox-search-01.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-appsawg-multimailbox-search-01.txt Reviewer: Francis Dupont Review Date: 20140717 IETF LC End Date: 20140721 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: first a meta-question: should this kind of documents refer to its parent, RFC 6237 (same subject but RFC 6237 is Experimental, the I-D is for Standards Track)? IMHO it should not (so the I-D is right) because this will be (only) mentioned in the RFC index. - ToC page 2 and 9 page 11: 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] review of draft-ietf-sidr-bgpsec-reqs-11.txt
In your previous mail you wrote: > > - 3 3.7 (twice), 3.11 page 4 and 4 4.3 page 6: need -> needs > > i believe that "x need not do y" is correct, so will leave it to the > rfced if you will indulge => you are the native English writer (:-). Anyway the RFC Editor could fix it if needed... > > - 3 3.14 page 4: wording (I had to read the 3.14 multiple times > > to understand it) > > how about > >While the formal validity of a routing announcement should be >determined by the BGPsec protocol, local routing policy MUST >be the final arbiter of best path and other routing >decisions. => far better! Regards francis.dup...@fdupont.fr PS: I apologize for the delay: I am back from a very long week-end (with the Bastille day...) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sidr-bgpsec-reqs-11.txt
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sidr-bgpsec-reqs-11.txt
Reviewer: Francis Dupont
Review Date: 20140703
IETF LC End Date: 20140703
IESG Telechat date: 20140710
Summary: Ready for nits
Major issues: None
Minor issues: None
Nits/editorial comments:
- Abstract page 1 and 1 page 2: only BGP is a well known abbrev,
AS or RPKI are not, now it is only a formal concern as anybody
with some interest in reading this document not only should know
these abbrevs but should expect to get them as abbrevs only...
- 3 pages 3 and 4: I have a concern about the "must" keyword
in lower case: I know it is allowed but it is clearly ambiguous
(BTW it is not a real problem for this kind of documents, just
not the best example for writers)
- 3 3.1 page 3: posessed -> possessed
- 3 3.1 page 3: wording
authority to announce the prefix in the announcement.
- 3 3.6 page 3 and 4 4.4 page 6: i.e. -> i.e.,
- 3 3.7 (twice), 3.11 page 4 and 4 4.3 page 6: need -> needs
- 3 3.9 page 4: ASNs -> AS numbers
- 3 3.10 page 4: AS-SETs -> AS_SETs (or AS SETs)
- 3 3.14 page 4: wording (I had to read the 3.14 multiple times
to understand it)
- 3 3.18 page 5: wording (I suggest)
customer, and provider relationships -> customer / provider relationship
- 6 page 5: e.g. -> e.g.,
- Authors' Addresses page 8 (twice): US -> USA
(both because it is the right name in the postal system, and
it is used by the third author :-)
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-mmusic-rtsp-nat-21.txt
In your previous mail you wrote: > Dear Francis, > I've done the changes, but I need some more information: > > > 4.2 page 9 (connection-address): (ambiguous wording) > > ... An IP address > > SHOULD be used, but an FQDN MAY be used in place of an IP address. > > [JIG] I'm not getting the ambiguity. => IMHO "A SHOULD be used, but B MAY be used" without a complete list of cases where B SHOULD be used (i.e., the exceptions) is inherently ambiguous. > Unusually, we deliberately _are_ recommending using an IP address > over an FQDN but allowing both => I understand the idea but IMHO the wording is not the right one (i.e., SHOULD is too strong). > and the reasoning for preferring an IP address is self > evident from additional complexity in the succeeding sentences. => the succeeding sentences are about support (where SHOULD+MAY don't conflict). Thanks francis.dup...@fdupont.fr PS: there are (at least) two ways to solve this: - to ignore my comment (I put it into editorial comments to allow this solution, the other choice was to make a minor point with a high probability to see a DISCUSS about the point :-). - to get some advice from the list as I shall be very surprised it is the first case we have a conflict for a SHOULD+MAY about use. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Telechat review of draft-ietf-hip-rfc4843-bis-06
Suresh Krishnan writes: > Summary: This draft is almost ready for publication as a Proposed > Standard but I have a comment you might wish to address. > * Section 2 > > The Encode_96 function mentions that the output is obtained by > "extracting the middle 96-bit long bitstring" from the argument. This > seems to be in conflict with Appendix E of RFC5201bis where the HIT suite > 3 recommends truncation of the hash to 96 bits. Shouldn't this just be a > truncation function? => Encode_96 is a truncation function because it takes a continuous part of the input, or with other words truncated allows to truncate one at one end, or twice. I agree it is not the usual/default truncation function which takes the first bits. So IMHO there is no conflict, even one can argue RFC5201bis is not enough accurate. (*) BTW all truncation functions are not really equivalent from a crypto point of view but in this particular use case it doesn't matter. To finish the Orchid v1 (RFC4843) uses an Encode_100 with the middle 100 bits. Regards Francis Dupont PS (*): RFC5201bis misses the 128 bit Context ID in the hash input so there is already a conflict. PPS for Julien: at line 289 OLD ORCHID := Prefix | Encode_96( Hash ) NEW ORCHID := Prefix | OGA ID | Encode_96( Hash ) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-rtsp-nat-21.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-rtsp-nat-21.txt Reviewer: Francis Dupont Review Date: 20140620 IETF LC End Date: 20140620 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None (a metacomment anyway: with the arrival of IPv6 we should not spend too much time/effort on NAT traversal...) Nits/editorial comments: - Abstract page 1 (and many other places): signalling -> signaling - ToC page 3 and 12 page 30: Acknowledgements -> Acknowledgments - 1 page 3: (style) too many "number" in There have been a number of suggested ways of resolving the NAT- traversal of media for RTSP of which a large number are already used in implementations. - 3 page 5 (4) (and 6.10 page 20, 9 page 27): e.g. -> e.g., - 4.1 page 6: (style) must be -> has to be - 4.2 page 9 (connection-address): (ambiguous wording) ... An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. - 4.2 page 10 (extension-att-*): delimeter -> delimiter - 6.3 page 16 (and 6.13 pages 22 and 23): (uniform use of a space after ';') RTP/AVP/TCP;unicast;interleaved=0-1 -> RTP/AVP/TCP; unicast; interleaved=0-1 - 6.7 pages 18 and 19: Succeded -> Succeeded - 7.1 page 23: will need to be run -> will be run - 9 page 26: i.e. -> i.e., 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-multicast-scopes-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-multicast-scopes-05.txt Reviewer: Francis Dupont Review Date: 20140530 IETF LC End Date: 20140530 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: (only editorial stuff in the case they are not caught by the RFC Editor) - 2 NEW page 4: contraint -> constraint - 7 page 5: missing final dot - Author's Address page 6: US -> USA 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-ietf-ipsecme-esp-ah-reqts-07.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ipsecme-esp-ah-reqts-07.txt Reviewer: Francis Dupont Review Date: 20140428 IETF LC End Date: 20140503 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in Toc page 2 and 6 (title) page 8: Acknowledgements -> Acknowledgments - 5 page 8: compability -> compatibility Regards francis.dup...@fdupont.fr PS: I have no expert opinion (as not being an expert, i.e., a cryptographer) about the backgound of requirement changes. Nevertheless they seems to be in phase with one can find in current publications... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-idr-last-as-reservation-04.txt
In your previous mail you wrote: > Yes, this duplicate paragraph in IANA considerations is a typo introduced => fine (the problem with a typo is authors' intent is not clear / hard to infer). > I'm also willing to change to Acknowledgments (no e after g) which I think > is the suggestion being made? => yes, it is US English so without the 'e'. Thanks francis.dup...@fdupont.fr PS: I'll move to Ready so the I-D should go further (e.g., IANA review). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-idr-last-as-reservation-04.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-idr-last-as-reservation-04.txt Reviewer: Francis Dupont Review Date: 20140401 IETF LC End Date: 20130403 IESG Telechat date: unknown Summary: Not Ready Major issues: there is a typo in the IANA considerations, i.e., the heart of the document. It seems to be a trivial typo but there is no proof of this... Minor issues: None Nits/editorial comments: Appendix A page 4: Acknowledgements -> Acknowledgements Regards francis.dup...@fdupont.fr PS: the typo looks like a bad cut & paste between versions 03 and 04. If (/when?) this is confirmed by authors I'll change summary to Ready and the typo from major issue to editorial. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sidr-policy-qualifiers-01.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sidr-policy-qualifiers-01.txt Reviewer: Francis Dupont Review Date: 20140222 IETF LC End Date: 20140225 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None (but some basic concerns were raised during the last call) Nits/editorial comments: - ToC page 2 and 5 page 3: Acknowledgements -> Acknowledgments - 2 page 2: IMHO it should be fine to get CP and CPS in long somewhere to make the document more readable. - Authors' Addresses page 4: US -> USA 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-l3vpn-mldp-vrf-in-band-signaling-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03.txt Reviewer: Francis Dupont Review Date: 20140211 IETF LC End Date: 20140212 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - the number of authors is greater than the (soft) limit - 1 page 5: too many 'o' in 'co-oordination' - 1.2 pages 5 & 6: IMHO you should describe more terms in the Terminology section, e.g., UMH, RPA and even RD (as VRF is already in it) 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-housley-pkix-test-oids-00.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-housley-pkix-test-oids-00.txt Reviewer: Francis Dupont Review Date: 20140122 IETF LC End Date: 20140211 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - typo 3 page 2: ... The actual polices used for production certificates has a significant impact ^ BTW if the word is policies than has -> have 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-moriarty-pkcs12v1-1-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-moriarty-pkcs12v1-1-03.txt Reviewer: Francis Dupont Review Date: 20130104 IETF LC End Date: 20130110 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: (not really technical) PKCS#12 was subject to concerns from teh cryptography community, in particular from Peter Gutmann, based on: - its (too) high complexity (BTW IMHO it is a legitimate concern: complexity is not wellcome for a security device) - (related to the previous item) its possible misuse with private key, summarized by this famous warning in OpenSSL FAQ: "Occasionally someone suggests using a command such as: openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose." Unfortunately I can't see how we can address these concerns in the document. Perhaps with a stronger security considerations section? Nits/editorial comments: - TOC page 3 and F page 29: Acknowledgements -> Acknowledgments - 1 page 4 in: The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. respectively suggests the same order but the private key is used to sign and the public key to encrypt. I propose to swap keys, i.e., to use "private/public" key pairs. - 5.1 5 B page 16: i.e. -> i.e., - a full example should have been wellcome but IMHO it is far too late (and there are a lot of tools able to produce examples if needed :-). 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-trill-oam-framework-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-trill-oam-framework-03.txt Reviewer: Francis Dupont Review Date: 20131120 IETF LC End Date: 20131126 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 3 and 9 page 30: Acknowledgements -> Acknowledgments - 1.1 page 5 (ECMP): Pathing -> Path - 2.1 page 6 and many other places: e.g. -> e.g., (and i.e. -> i.e., too... First at 2.4 page 12) - 2.6 page 12: ask the RFC Editor to manage to get the title not at the very end of the page - 6.1.5 and 6.1.6 page 26: in group item titles you put "/" and "," separators, for instance: - VLAN / Fine grain label / Flow parameters and - Target RBridge Nickname (unicast), Tree Identifier (Multicast) and IP multicast group Is there a good reason? And BTW the IP multicast group is for the multicast case. Note my comment is only about the wording: the spec is very easy to understand. - 6.1.7 page 27 (and 6.1.8 page 28): in Repeat Count "For proactive monitoring this may be set to allow for infinite monitoring." what is the recommended value to set the counter (or with other words how is encoded the infinite)? - 10.2 page 31 (TRILL-BFD): Interconnetion -> Interconnection (Note the spelling error is in the referenced I-D itself but it has at least one common author) Regards francis.dup...@fdupont.fr PS: my spell checker insists about congruency (the correct term is congruence) and IMHO it is right... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-sdp-g723-g729-04.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-sdp-g723-g729-04.txt Reviewer: Francis Dupont Review Date: 20131120 IETF LC End Date: 20131127 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Abstract page 1: usually the Abstract should not reference an RFC by its number. IMHO here it is the exception: the I-D will be included into the next revision of the RFC. - I don't like the annexa/annexb name (nor my spell checker) but they are the names used by the RFC... - ToC page 2 and 7 page 7: Acknowledgement -> Acknowledgment - 1 page 3 (wording suggestion): implied if -> implied when - 1 page 3: BTW IMHO "use or preferred" should be interpreted as preferred in the offer and use in the answer so the RFC is correct. But as you mentioned some implementations didn't follow the interpretation so I understand why a clarification new document (this I-D) is needed. And of course I fully agree with 3.1 and 3.2. - 7 page 7: Note I checked the spelling of "Harprit S. Chhatwal (InnoMedia)" (uncommon for our eyes but correct). 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-forces-ceha-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-forces-ceha-08.txt Reviewer: Francis Dupont Review Date: 20131028 IETF LC End Date: 20131106 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 1 pages 2 and 3: I have a concern with the order of definitions. IMHO there are 3 solutions: * keep the document order arguing definitions are repeated for convenience so it doesn't matter there are backward references (i.e., someone new in the domain should first read referenced RFCs, and at the opposite someone not new in the domain already knows the used acronyms) * introduce each acronym at its first use * same + reorder the definition list to minimize out-of-order internal references Note the best choice depends on the intended public so you have a better idea than me about this... - 2.2 second 1. page 5: IMHO the interface is Fp, not Fr. - 3.1 figure 2 page 7: Estbalishment -> Establishment - 3.1.1 page 7: parametrization -> parameterization - 4.1 page 11 (twice): i.e. -> i.e., - 4.1 2. page 11: the and in "+ and 2" should be moved to the end of the previous item, i.e., I suggest to change: + 1 (HA Mode - Cold Standby) represents that the FE is in HA mode cold Standby + and 2 (HA Mode - Hot Standby) represents that the FE is in HA mode hot Standby into + 1 (HA Mode - Cold Standby) represents that the FE is in HA mode cold Standby, and + 2 (HA Mode - Hot Standby) represents that the FE is in HA mode hot Standby Note if you want to put something at the end of each items the correct character is ";", and "." for the last item. - 4.2 page 13: practise -> practice - 4.2 pages 13 and 14: figure 4 should be on one page (this is something to leave to the RFC Editor anyway). - 4.2 figure 5 page 14 (3!): Estbalishment -> Establishment - Appendix A page 20: some indent problems with "The FE should stop | continue" (same remark: we can expect the RFC Editor will use a XML pretty-printer for the final editing). Regards francis.dup...@fdupont.fr PS: I am at the IETF meeting. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-roll-terminology-13.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-terminology-13.txt Reviewer: Francis Dupont Review Date: 20131014 IETF LC End Date: 20131027 IESG Telechat date: 20131024 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: (BTW only editorial comments) - Title page 1: Ruting -> Routing - Abstract page 1: e.g. -> e.g., - ToC page 2 and 5 page 7: Acknowledgements -> Acknowledgments - 2 page 3: commisioning -> commissioning - 2 page 4 Data Sink: move the LBR into from Field Device to here - 2 page 4 and many pages 5 and 6: e.g. -> e.g., and i.e. -> i.e., - 2 page 4: I suggest to use real units, i.e., KiB (aka kibibyte) and kbits/s (K not followed by i stands for Kelvin :-) - 2 page 5 P2MP: RFC4461]and [RFC4875] -> RFC4461] and [RFC4875] - 2 page 6: arbitratry -> arbitrary 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-p2psip-drr-10.txt (resent)
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-p2psip-drr-10.txt Reviewer: Francis Dupont Review Date: 20130927 IETF LC End Date: 20130930 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: the title and the abstract must get an explicit expansion of the RELOAD acronym, e.g., the title shoud be: An extension to REsource LOcation And Discovery (RELOAD) protocol to support Direct Response Routing Nits/editorial comments: - proposed changes to the title and to the abstract (both page 1) - ToC page 2 and 10 page 13: Acknowledgements -> Acknowledgments - IMHO Authors' Addresses should be in the body so before the Appendix - 2 page 3 in Publicly Reachable: closed system -> closed network - 3.1.2 page 6 (in fact more for the RFC Editor): Figure 2 label should be in the same page than the figure itself (or with other words please avoid silly page breaks). - 3.2.1 page 6: the responding peer receives a response... if I am not fully lost it should be a request, not a response? - 5.1 page 8 (4 times): e.g. -> e.g., - 5.2 page 9: I trust you (and the WG) for the delays... - 8 page 13: drat -> draft (and IMHO document is far more appropriate as it will be published as an RFC before this draft :-). - 11.2 page 14: add a reference to RFC 6887 (and see below). - A.1 page 16: endpoint- independent -> endpoint-independent - A.1 page 16: even it doesn't provide a direct way of getting the external assigned address (but read 11.6) PCP [RFC 6887] must be added to UPnP-IGD and NAT-PMP. If you need some words, one can consider PCP as a far more complete version of NAT-PMP. BTW the "test address" comment applies too to PCP. Regards francis.dup...@fdupont.fr PS: my checker complains about standalone (-> stand-alone), inline (?, please ignore), publically (-> publicly?, this should be addressed, even by the RFC Editor, as it occurs many times), etc. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-delayed-duplication-02.txt (resent)
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-delayed-duplication-02.txt Reviewer: Francis Dupont Review Date: 20130925 IETF LC End Date: 20130924 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2 and 7 page 7: Acknowledgements -> Acknowledgments - 3 page 4: "Figure 1" (which should be in the same page than the "figure") is not a figure... 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-p2psip-drr-10.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-p2psip-drr-10.txt Reviewer: Francis Dupont Review Date: 20130927 IETF LC End Date: 20130930 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: the title and the abstract must get an explicit expansion of the RELOAD acronym, e.g., the title shoud be: An extension to REsource LOcation And Discovery (RELOAD) protocol to support Direct Response Routing Nits/editorial comments: - proposed changes to the title and to the abstract (both page 1) - ToC page 2 and 10 page 13: Acknowledgements -> Acknowledgments - IMHO Authors' Addresses should be in the body so before the Appendix - 2 page 3 in Publicly Reachable: closed system -> closed network - 3.1.2 page 6 (in fact more for the RFC Editor): Figure 2 label should be in the same page than the figure itself (or with other words please avoid silly page breaks). - 3.2.1 page 6: the responding peer receives a response... if I am not fully lost it should be a request, not a response? - 5.1 page 8 (4 times): e.g. -> e.g., - 5.2 page 9: I trust you (and the WG) for the delays... - 8 page 13: drat -> draft (and IMHO document is far more appropriate as it will be published as an RFC before this draft :-). - 11.2 page 14: add a reference to RFC 6887 (and see below). - A.1 page 16: endpoint- independent -> endpoint-independent - A.1 page 16: even it doesn't provide a direct way of getting the external assigned address (but read 11.6) PCP [RFC 6887] must be added to UPnP-IGD and NAT-PMP. If you need some words, one can consider PCP as a far more complete version of NAT-PMP. BTW the "test address" comment applies too to PCP. Regards francis.dup...@fdupont.fr PS: my checker complains about standalone (-> stand-alone), inline (?, please ignore), publically (-> publicly?, this should be addressed, even by the RFC Editor, as it occurs many times), etc. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mmusic-delayed-duplication-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-delayed-duplication-02.txt Reviewer: Francis Dupont Review Date: 20130925 IETF LC End Date: 20130924 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2 and 7 page 7: Acknowledgements -> Acknowledgments - 3 page 4: "Figure 1" (which should be in the same page than the "figure") is not a figure... 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-mpls-targeted-mldp-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-targeted-mldp-03.txt Reviewer: Francis Dupont Review Date: 20130827 IETF LC End Date: 20130903 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in general I don't like the style used in this document but it is still understable. - abstract page 1: it is not recommended to explicitly cite RFCs by number in the abstract (the idea is to make easier to update base specs, note in this particular case the reviewed document should be merged in the references during the update) - 1.2.1 page 4: an example of dubious wording (cf style comment): The particular method used to select an "upstream LSR" is determined by the Service Provider (SP). The method to use is determined by provisioning; whichever method is used, must be known a priori to all the LSRs involved. - 7 page 9: please add the country (USA) Regards francis.dup...@fdupont.fr PS: in the header I can see "IJsbrands Wijnands", in Authors' Addresses and in the mLDP reference "IJsbrand Wijnands"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-storm-ipsec-ips-update-03.txt
In your previous mail you wrote: > Thank you for the review. I have made all three changes in my > working version that will become the -04. => thanks, I raised the status to "Ready" even the -04 doesn't seem to be available in the tools.ietf.org I-D repository? francis.dup...@fdupont.fr PS: the draft-ietf-storm-ipsec-ips-update is at the IESG agenda of the 2013-08-29 teleconf (cf http://datatracker.ietf.org/iesg/agenda/) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-storm-ipsec-ips-update-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-storm-ipsec-ips-update-03.txt Reviewer: Francis Dupont Review Date: 2013-08-14 IETF LC End Date: 2013-08-19 IESG Telechat date: unknown Summary: Almost ready Major issues: None Minor issues: - this is in fact a pure editorial concern but as it can have a big impact on not IETF expert readers I put it here: At the end of 3 page 9: use of IPsec v3 is recommended -> use of IPsec v3 is RECOMMENDED Two notes for the discussion: - a RFC 2119 keyword doesn't need to be capitalized - it is the only place with a preference for IPsec v3 over v2. Nits/editorial comments: - Authors' Addresses page 16 (twice): US -> USA 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-emu-crypto-bind-04.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-emu-crypto-bind-04.txt Reviewer: Francis Dupont Review Date: 20130722 IETF LC End Date: 20130724 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - headers page 2: the keyword section is in the headers (vs the body). This is not the usual place... (BTW it is not the first time I do this comment so either the policy is different than I believe or there is a draft skeleton with this in it?) - Toc page 3 and 7 page 22: Acknowledgements -> Acknowledgments - 3.2.4 page 14: IMHO it should be fine to have an informational reference about EMSK (my idea is to help people to add it in design from the beginning). - 4.2 page 17: edition problem? in: should require mutual authentication be present in the session. to accomplish this, implementations including channel binding or - 5.2 page 19 (at the end of the line) EAp- -> EAP- - 5.2 page 19: my spell checker has a concern with "interoperably" Thanks 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-xrblock-rtcp-xr-discard-rle-metrics-05.txt
In your previous mail you wrote: > > - 1 page 3: take benefit of the first "Extended Reports" to introduce > > the XR abbrev > > It is in the title, but I've expanded it at first occurrence in text. => the convention is to consider the title and the abstract as other independent parts of the document. > > - 1 page 3: playout > play out (according to my spell checker) > > In multimedia we often use: playout buffer, playout delay. > But in this case playout is acting more as a verb instead of a noun. > Anyone else have an opinion about this? => I agree it is a common term: this is why I added "according to my spell checker"... BTW this should typically be handled by the RFC Editor. Thanks 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-rtgwg-cl-requirement-10.txt
In your previous mail you wrote: > > Minor issues: None > > OK. Thanks but it appears the document is headed back to another WGLC > due to other comments, mostly due to the RtgDir review comments. => yes, I saw that. > > Nits/editorial comments: > > - ToC page 3 and 7 page 12: Acknowledgements -> Acknowledgments > > It appears that both spellings are acceptable according to my spell > checker. I will leave as is unless there is continued objection. => Acknowledgements is UK English, Acknowledgments is US English. The usage is more for US English but anyway it is something for the RFC Editor... > > - 3 page 5 (component link): the term NPO is used before being defined > > > > - 3 page 5 (component link): expand the WDM abbrev -- not well known > > according tothe RFC Editor list: > > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > > > - 3 page 5 (flow identification): same for the PW abbrev > > A last call comment from our AD is to expand all acronyms before use. > The SecDir comments also requested this. => not a bad policy anyway even the official one makes this optional for well known acronyms (the acronyms with a star in the list, e.g., it is not really required to expand TCP/IP :-). > I will also do a full spell check and see what else the spell checker > find. (I am using International Ispell Version 3.3.02 12 Jun 2005 > with English and American English dictionary files). => I use the same but by default with only the American English one (even I have the UK and of course the French (from France) dicts too). 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-ietf-xrblock-rtcp-xr-discard-rle-metrics-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05.txt Reviewer: Francis Dupont Review Date: 20130625 IETF LC End Date: 20130701 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - title page 1: for Run Length -> for Run Length - ToC page 2 and 9 page 9: Acknowledgements -> Acknowledgments - 1 page 3: take benefit of the first "Extended Reports" to introduce the XR abbrev - 1 page 3: expand the RR abbrev (not well known according to the RFC Editor list http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt and BTW has at least 3 different meanings :-) - 1 page 3: RLE is well known (so you can keep it!) - 1 page 3: playout > play out (according to my spell checker...) - 3 page 4 (still the spell checker): recaps 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-ietf-rtgwg-cl-requirement-10.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-rtgwg-cl-requirement-10.txt Reviewer: Francis Dupont Review Date: 20130617 IETF LC End Date: 20130619 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 3 and 7 page 12: Acknowledgements -> Acknowledgments - 2 page 4: double include words in: The services supported include pseudowire based services (RFC 3985 [RFC3985]), including VPN services, I suggest something like: The supported services are, but not limited to, pseudowire based services (RFC 3985 [RFC3985]), including VPN services, - 3 page 5 (component link): the term NPO is used before being defined - 3 page 5 (component link): expand the WDM abbrev -- not well known according tothe RFC Editor list: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt - 3 page 5 (flow identification): same for the PW abbrev - 4.1 page 6: CAN -> MAY - 6 page 12 (MR#10) -> interpretted -> interpreted - 9 page 13: Encrption -> Encryption - Authors' Addresses: add the country (USA) in postal addresses 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-mpls-ldp-dod-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-ldp-dod-08.txt Reviewer: Francis Dupont Review Date: 20130527 IETF LC End Date: 20130527 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: (Note most of them should be handled by the RFC Editor) - "Requirement Language" section page 1 is not in the body - the requirement keywords are not used everywhere in the document, if I understand well there is a normative part. BTW the question stands too about the Security Considerations. - ToC page 2 and 8 page 31: Acknowledgements -> Acknowledgments - I have some problems with the abbrevs, I suggest: * refer to the RFC Editor list to know if an abbrev is well known or not, in the second case consider to introduce it * IMHO all not well known abbrev required to understand the text or used more than once must be introduced at the first use * another way is to refer to a terminology RFC - 2 pages 4 and 5: figure 1 should be on one page (BTW this is a good example of something which could be handled by the RFC Editor) - same figure problems for figures 2 - 2.1 page 8: examples of the abbrev issue with ECMP, LAG and FEC. - 4.1 page 19: i.e. -> i.e., - 4.3.2 page 23: [RFC5036] (section A.1.1, page# 100) -> ([RFC5036] section A.1.1, page 100) ?? - 4.4 page 23 and 5 page 25: the title should not be at the last line - 4.4 page 24, 7 page 28 and 7.1.2 page 29: e.g. -> e.g., - 5 is a normative part so uses KEYWORDS (IMHO this should be explained, for instance in the Requirement Language section if it is moved to a more standard position) - 5 page 26: the Queue Request Type is TBD but is 0x0971 in the schema? - 6.1 page 27: I suggest to add a reference for RFC5036 (i.e., RFC5036 -> [RFC5036] as it is in other positions) - 7: I have no problem at all (:-) with using KEYWORDS in Security Considerations! - 7 page 28: are considered as -> are applied as ? - 7.2 page 30 (about keywords): for instance 'should NOT' -> 'SHOULD NOT' and keep the MAY in 5. - 7.3 page 30: a more questionable 'may' - 7.4 page 31: two should's which should be IMHO 'SHOULD' - Authors' Addresses page 32: another paging (?) issue - Authors' Addresses page 33: some issues: * French ZIP codes are in front (but is it possible to change from the XML? I don't know so if you find a simple way to fix it please both fix it and explain it to me) * ITU TS E.123 requires no optional part in the middle of a phone number, i.e., 1-(978)-589-8861 -> +1-978-589-8861 * no ZIP code for London? BTW grep finds 'FELTHAM TW14 8HA' (Cisco's communication department should know the canonical address. BTW in my company we had to agree about the canonical company name... :-) 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-housley-rfc2050bis-01.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-housley-rfc2050bis-01.txt Reviewer: Francis Dupont Review Date: 20130420 IETF LC End Date: 20130514 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2 and 9 page 6: Acknowledgements -> Acknowledgments - 3 page 3: (more for the RFC Editor) the word "IANA" should be the first of the page 4, not the last of page 3. - 7 page 6: IMHO it is the right place to add a reference to the RPKI (i.e., how the security considerations are implemented) - 9 page 6: I give to SM the opportunity to get his full name in 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-roll-terminology-12.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-terminology-12.txt Reviewer: Francis Dupont Review Date: 20130323 IETF LC End Date: 20130330 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: There are some missing forward definitions for some abbrevs, i.e., the first time an abbrev is used it should be explained too (*). (*) "too" because it is explained (i.e., put in its long form) in its entry which can be after the first use. Nits/editorial comments: - Abstract page 1: e.g. -> e.g., - ToC page 2 and 5 page 7: Acknowledgements -> Acknowledgments - 1 page 2: please introduce the HVAC abbrev (the Abstract should be considered as to be independent) - 2 page 3: commisioning -> commissioning - 2 pages 4 and other: i.e. -> i.e., and e.g. -> e.g., (including at the end of line) - 2 page 4: K -> k (or if you prefer Kelvin -> kilo in units :-) - 2 page 5 (LLN): refrigeration.. -> refrigeration. or refrigeration... - 2 page 5 (PER): I suggest: error- even -> error - even - 2 page 5 (P2MP): an example of a missing forward definition for RPL, i.e.: RPL -> Routing Protocol for Low-Power and Lossy Networks (RPL) - 2 page 6 (RPL): arbitratry -> arbitrary Regards francis.dup...@fdupont.fr PS: a terminology with a lot of cross references can be hard to read (so to write). I had a very bad experience with an ISO OSI one in the past so the only thing IMHO should be required is to be readable in one pass in the beginning to end order (vs. hopping order), so my comments about abbrev definitions. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [therightkey] review of draft-laurie-pki-sunlight-07.txt
In your previous mail you wrote: > I just wanted to check if you Francis feel that the issues have been > adequately addressed. FWIW, I read the document with the respect to the > major issues raised in your review at least, and thought that the -09 > was clear enough for me. => oops, it seems I forgot to update the gen-art wiki... I agree there was nothing still needed to be addressed in the PKI sunlight I-D. Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [therightkey] review of draft-laurie-pki-sunlight-07.txt
In your previous mail you wrote: > I believe the RFC editor allows either English or American > spellings so long as the document is consistent. => in fact I believe the RFC editor is chartered to allow any language... 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-laurie-pki-sunlight-07.txt
In your previous mail you wrote: > > Minor issues: => BTW I received a side comment stating the document is too long and should be split into 3 parts (maths, mechanisms, application). Of course you may answer it is too late... > > - section 2 is not enough accurate, for instance: > > * the critical [k1:k2] notation is introduced after its first use, IMHO > >it is the primary one, i.e., [n] is a short hand for [0:n] > > Notation is rather tricky here, but I don't think that saying D[n] is > shorthand for D[0:n] adds clarity. This is because D[k:n] becomes > D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just > confusing (and, indeed, wrong). => I don't say D[k:n] is the same as D[0:n-k], just that D[0:n-k] is the same than D[n-k]. But this is a matter of taste and I have no good proposal to make this section very clear... > > * the largest power of two must be strictly smaller, not just smaller. > > There is no difference between "strictly smaller" and "smaller" (in > contrast to "decreasing" and "strictly decreasing"). => it is a language problem: I leave it to native English speaker. > > - 1 page 4: it is a general mechanism but what are its constraints at > > the exception of the intended usage. For instance is the mechanism > > applicable to any end entity public key certificate? or larger?? > > I don't know what this comment refers to. => you have a mechanism which can be applied to more than public TLS server certificates. IMHO it should be fine to put a few words about the technical (vs usage) scope of the mechanism. Note the term "general" before mechanism and the very limited scope are both at the end of the first paragraph of section 1. > > - 1 page 5: misbehaviours -> misbehaviors > > (and 3.3 page 16, and others too) > > I am not American. => nor I am: I just applied an american English spell checker and reported what it considered as spelling errors. Note that RFCs are supposed to be written in american English (even it is not a strict rule at all), and what I did is a good practice when they are many authors from different countries (i.e., in the general case). > > - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list" > > is IMHO a bit uncommon even I can understand it. > > It's maths. => I am clearly under the Bourbaki's influence (i.e., maths should be written in the best possible wording :-). > > - 2.1.4 page 10: using a key of at least 2048 bits. -> > > using a public key of at least 2048 bits. (or a modulus as it is for RSA > ?) > > The public and private keys are the same length in RSA (and the length > is the length of the modulus). => as keys in RSA are not integers but tuples of integers they have no length by themselves. Now I agree the common meaning is what you say so I remove my comment (i.e., to be more accurate will be pedantic without a clear benefit). > > - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not > > ASN.1 itself, nor C? > > The format of certificates is defined elsewhere. The name ASN.1Cert > (which is what I assume you refer to) is taken from RFC 5246. => oops, I missed the 1.2 where this was stated. > > - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they > > are insipid and stupid :-) > > I love you, too. => I thought you know the LISP programming language acronym... (I was a LISP programmer so I know all jokes about LISP :-) > In fact, they are required, see section 4.5 of RFC 5246. => I see. But in this case there are spurious 255 (not (255) as the default is one byte?). RFC 5246 uses (255) so I suggest to change all 255 at the end of enums into (255) *if* you have the opportunity to do this. > > BTW if the document creates new OID perhaps they should be put > > in an annex? > > I am not aware of a requirement to do so. => nor I am (this is why I put a question mark) > > PS: I noted there are still some LC comments in the ML. > > I am not aware of any I have missed. => it was just a reminder to the LC comment statement at the beginning of the standard gen-art template, and an indication to other gen-art ML readers. 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-ietf-dhc-secure-dhcpv6-07.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-secure-dhcpv6-07.txt Reviewer: Francis Dupont Review Date: 20130220 IETF LC End Date: 20130225 IESG Telechat date: 20130228 Summary: Not Ready Major issues: the proposal fails to provide the expected security, in particular it does nothing real against replay and the basic function (anti-spoofing) relies on pre-configuration. Minor issues: some but major issues should imply enough changes to make them more candicates for comments Nits/editorial comments: (including technical comments) - first the I-D format is not followed (printed the 17 pages with 4 pages per sheet gives 9 sheets...) - Abstract page 2: IMHO the Abstract should be first (i.e., just after the title and before the Status of this Memo) - I know well SeND so when I compare to it I can see a lot of issues. To summarize SeND uses 4 devices: nonces, timestamps, CGAs and a PKI. Nonces and timestamps are for anti-replay (IMHO nonces have a crypto function too as they introduce unpredictable random in messages, but I don't know if it is an important point or not). CGAs are for authentication and message integrity. The PKI (known today as the RPKI) is for authorization, i.e., the prefix is checked to be really assigned to the entity running the router. When I compare to the secure DHCPv6 proposal I can get only the CGA part. There are timestamps but one way and without any text explaining how to apply them (i.e., the proposal is incomplete about this point: anti-replay). The authorization problem is not addressed until the end of the document where pre-configuration is introduced. BTW the current DHCPv6 security is mainly rejected because it requires pre-configuration (of course it has many other problems but this operational one is as far as I know the most blocking one). - 1 page 3: I'd like to see anti-replay and authorization issues at least mentioned here. - 3 a page 3: ownership doesn't protect against fake, it protects against impersonation, i.e., with CGAs a fake server can launch an attack but nobody can impersonate the legimate server. So either the description of the attack is wrong or the protection mechanism is not the right one. - 3 b page 4: i.e. -> i.e., - 3 c page 4 (comment): in fact the reason IPsec is rarely used to protect relay/server communication is not because IPsec is hard but because usually this communication is inside the ISP internal infrastructure so is not subject to easy attacks. With other words the vulnerable part is the client/agent communication over a very unprotected LAN, a wireless LAN for instance, where of course IPsec is not applicable. - 4 page 4: abovementioned -> above mentioned or above-mentioned? - 4 page 5: replay protection is mentioned, there is a timestamp field in the signature option but nothing about how to use it... - 4.2 page 5: IMHO the text about collision could be removed: it is well known collisions are not a problem in this case. And algo agility is something one wants a priori, so it doesn't need a bad argument to support it. BTW if you can't find a general IETF document explaining why algo agility is good we can ask the security directorate to make a formal statement. In anycase you should get something to reference... - 5.2 page 8: in the signature please put the tag value in its own line (so implementors can more easily cut and paste it). - 5.2 page 9: I am not sure the wording of the padding is very correct... - 5.4 page 10: section 5.1 and 5.2 -> sections - 6.2 page 12: where is the text about timestamps? With the current processing rules a relay attack is trivial (so either you remove anti-replay from the threats the proposal deals with, or you complete the proposal). - 6.2 page 12: someone suggested for DNSSEC to avoid silly large RSA exponents too. (comment (as you wrote prudent practice...)) - 7 pages 14 and 15: I have nothing against this security considerations but unfortunately as they are well written they kill most of the interests in the proposal: - anti-spoofing provided by pre-configuration (i.e., you can also pre-configured shared secrets for authentication/integrity) - no downgrade protection when compatibility is kept. - another text about collisions (please keep this one and remove the section 4.2 one) - 9 page 17: IMHO Dorms -> Droms ... 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-laurie-pki-sunlight-07.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-laurie-pki-sunlight-07.txt Reviewer: Francis Dupont Review Date: 20130208 IETF LC End Date: 20130226 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: - section 2 is not enough accurate, for instance: * the critical [k1:k2] notation is introduced after its first use, IMHO it is the primary one, i.e., [n] is a short hand for [0:n] * the largest power of two must be strictly smaller, not just smaller. Without this critical detail recursion rules don't work for n = 2^m Unfortunately there is no wikipedia or equivalent web page where to refer to so the document is the place where all gory details have to be... - the Maximum Merge Delay (MMD) is an important parameter but I can't find where is the way users get its value, nor any recommendation for it. Nits/editorial comments: - 1 page 4: CA is not a well known abbrev so please introduce it (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) - 1 page 4: it is a general mechanism but what are its constraints at the exception of the intended usage. For instance is the mechanism applicable to any end entity public key certificate? or larger?? - 1 page 5: misbehaviours -> misbehaviors (and 3.3 page 16, and others too) - 1 page 5: e.g. -> e.g., - 2.1.1 page 6: i.e. -> i.e., - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list" is IMHO a bit uncommon even I can understand it. - 2.1.4 page 10: using a key of at least 2048 bits. -> using a public key of at least 2048 bits. (or a modulus as it is for RSA?) - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not ASN.1 itself, nor C? - 3.1 page 12: accomodate -> accommodate - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they are insipid and stupid :-) - 3.1 page 13: submmited -> submitted - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';' - 4.6 page 22: honour -> honor - 4.6 page 22: convering -> covering? BTW if the document creates new OID perhaps they should be put in an annex? Regards francis.dup...@fdupont.fr PS: I noted there are still some LC comments in the ML. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-eman-requirements-10.txt
In your previous mail you wrote: > > - ToC page 3 and 11 page 23: Acknowledgements -? Acknowledgments > > Well, both is possible. I changed it as suggested. => it is a standard US vs UK English... > > - 1 page 4 and others: why Power State and not power state? I believe it > > comes from a document where you imported the term from? > > The capitalized term is defined in the terminology section. Is this OK? => it is OK (and a point for the RFC Editor): I just wanted to understand. 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-ietf-eman-requirements-10.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-eman-requirements-10.txt Reviewer: Francis Dupont Review Date: 20130125 IETF LC End Date: 20120125 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2: very inconsistent use of caps: I propose to put the first letter of all words in upper cases. And of course apply this to titles (in the very unlikely case the ToC is not auto generated) - ToC page 3 and 11 page 23: Acknowledgements -? Acknowledgments - 1 page 4: IT -> Information Technology - 1 page 4 and others: why Power State and not power state? I believe it comes from a document where you imported the term from? - 12 pages 23 and 24: Telcommunication -> Telecommunication (twice) - Authors' Addresses: please use the full names of countries (surface mail was not yet converted to ISO IS 3166 as far as I know :), so: DE -> Germany IN -> India (or Republic of India?) BE -> Belgium Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] postponed review of draft-laurie-pki-sunlight-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-laurie-pki-sunlight-05.txt Reviewer: Francis Dupont Review Date: 201301xx IETF LC End Date: 20130124 IESG Telechat date: unknown Summary: Not Ready Major issues: None but according to LC comments in the IETF mailing list I believe a new version is very likely, so I propose to wait for it and review only the new/next version (if you disagree please answer, I have still the printed version 05 available and plenty of time next week...) 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-sipclf-format-09.txt
It seems I forgot to send this before Christmas... I apologize.
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sipclf-format-09.txt (applies to -11.txt too)
Reviewer: Francis Dupont
Review Date: 20121220
IETF LC End Date: 20121217
IESG Telechat date: 20121220
Summary: Almost Ready
Major issues: None
Minor issues: the encoding of the BEB is inconsistent: one part of the text
specifies 0x00 or 0x01 values, another the hexadecimal of these, i.e.,
the two characters 00 or 01. IMHO they are many good reasons to take the
second but it requires to fix the text, for instance to put the BEB field
in figure 5 section 4.4 page 16 on 2 octets (vs only one) with the mention
"(Hex)".
Nits/editorial comments: (with version 11 page numbers)
- ToC page 2 and 10 page 28: Acknowledgements -> Acknowledgments
- 2 page 4: inconsistent use of article in:
This document uses the term "SIP Server" that is defined to include
the following SIP entities: user agent server, registrar, redirect
server, a SIP proxy in the role of user agent server, and a B2BUA in
the role of a user agent server.
(IMHO the best is to removed it in the second "the role of a user")
- 4 page 7: it should be reader friendly to decode the separators
(i.e., to say 0x2C == ',', etc)
- 4.2 page 11: i.e. -> i.e.,
- 4.2 page 12: Encrytped -> Encrypted
- 4.2 page 13: I have a small concern about the two "(if present)" for
"To Tag" and "From Tag" because the way it has to be encoded if not
present is explained after in 4.3. IMHO a reference with a short
indication ("-") should be wellcome.
- 4.4 pages 15 and 16: place where BEB is specified.
- 4.4 page 18: e.g. -> e.g.,
- 4.4 (1) page 18: first example where the BEB is clearly encoded in
hexadecimal into 2 octets/characters.
- Authors' Addresses page 30: (3 times) US -> USA
Regards (and as it is a bit late for Christmas, Happy New Year!)
francis.dup...@fdupont.fr
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] postpone draft-ietf-v6ops-ra-guard-implementation review
A new version was published some hours ago and already received comments in the mailing list... so I decided to postpone the review of the last version (or the next one? :-) and to downgrade the status from Ready (there were only editiorial comments about 04 version (last is 07)) to On the right track to get some time (including for the IESG). 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-dhc-client-id-06.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-client-id-06.txt Reviewer: Francis Dupont Review Date: 20121018 IETF LC End Date: 20121017 IESG Telechat date: 20121025 Summary: Ready Major issues: None Minor issues: None (even some questions below could be promoted to issues) Nits/editorial comments: There is no real justification: I had to read the first WGLC text to find the reason behind: there was a bug in RFC 2131. - Abstract page 1 and 1 page 4: return client identifier' option -> return 'client identifier' option - ToC page 3 and 6 page 6: Acknowledgements -> Acknowledgments - 1 page 4: DHCP server allocate -> DHCP servers allocate ? - 2 page 4: a combination of ... and ... constitute ... and are ... -> constitutes ... is (i.e., combination is the subject)? - 2 page 4: need not be unique -> are not required to be unique? - 3 page 5: the draft proposed to change "MUST NOT" into "MUST", perhaps it is enough to change them into "SHOULD"? (note this question comes from the lack of justification, and the use of loose terms as "update" or (worse) "clarify" in place of "fix" or "errata"... I.e., if you are convinced there was a bug the right fix is "MUST") - 7 page 6: RFC 3315 should IMHO be an informative reference - Authors' Addresses pages 6 and 7: extra spaces before ZIP codes? 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-v6ops-ivi-icmp-address-06.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-ivi-icmp-address-06.txt Reviewer: Francis Dupont Review Date: 20120920 IETF LC End Date: 20120925 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: In general the language itself could be improved even there is nothing which is hard to understand (i.e., it is a comment only on the form). I suggest to get some help from English native authors or to leave this to the RFC Editor... - 3 page 3: an non-IPv4- -> a non-IPv4- - 3 page 3: (style) bound for to (I suggest "sent to") - 3.1 page 3: uRPF -> unicast reverse path forwarding (uRPF) (note: uRPF is in the RFC Editor abbrev list but not as "well known") - 3.1 page 3: (style) origination (I suggest "origin" or "source") - 3.2 page 4: a question (vs a comment): is RFC 5837 widely supported? - 8 page 5: Henrik Levkowetz is included twice - 9.1 page 5: BCP 84 is included as a normative reference? (I have no concern but I'd like to warn this point is questionable) - 9.2 page 6: I am not sure ISO IS 3166 codes are appropriate in postal addresses, so CN -> China? 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-mptcp-multiaddressed-09.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mptcp-multiaddressed-09.txt Reviewer: Francis Dupont Review Date: 20120828 IETF LC End Date: 20120815 IESG Telechat date: 20120830 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - the topic is not very well introduced but it is a member (and not the first one) of a group of documents so IMHO this can be really assessed only by reading all documents (in order)... - the language is English, not US English (I leave this to the RFC Editor, it just made my speller (configured for the US English) a bit fussy. - Abstract page 1 and many other places: i.e. -> i.e., (and e.g. -> e.g.,) - ToC pages 2 and 3, section 7 page 51: Acknowledgements -> Acknowledgments - 2.3 page 10: implictly -> implicitly - 2.4 pages 10 (3) and 11 (2): acknowledgements -> acknowledgments - same 3 page 13 and 3.3.2 page 26 - 3.2 page 19: in "Doing the MAC exchange at this stage allow" allow -> allows? - 3.2 page 21: Deumultiplexing -> Demultiplexing - 3.3.1 page 24: neogiated -> negotiated ? - 3.3.2 page 27: restransmited -> restransmitted - 3.3.3 page 28: permissable -> permissible && oustanding -> outstanding - 3.3.4 page 29 and 3.4 page 34: succesfully -> successfully - 6 page 48: illustred -> illustrated - 6 page 48 figure 16: get the whole figure on the same page (more a warning for the RFC Editor BTW :-) - 8 pages 51 and 52: by [21]) Assignments _> by [21]). Assignments ?? - A page 55: accomodate -> accommodate - English vs US English from my speller (other than acknowledgement): behaviour utilisation signalled labelled optimisations maximise whilst learnt minimise specialised emphasised analyse 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-sparks-genarea-mailarch-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-sparks-genarea-mailarch-05.txt Reviewer: Francis Dupont Review Date: 20120810 IETF LC End Date: 20120813 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - a very minor question: why in the search syntax is there no "NOT" operator, only "AND" and "OR"? - annoying edition bug in 2.6 Nits/editorial comments: - ToC page 2 and 6 page 7: Acknowledgements -> Acknowledgments - 1 page 3 and 2.1 page 4: capabilites -> capabilities - 2.1 page 4: occuring -> occurring - 2.6 page 7: please remove the last item, i.e.: o The system must allow the administrator to delete messages from an archived list which is already specified by the previous one, i.e.: o The system must allow the administrator to add messages to and delete messages from an archived list. The system should log such actions. 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-dnsext-dnssec-algo-imp-status-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsext-dnssec-algo-imp-status-03.txt Reviewer: Francis Dupont Review Date: 20120704 IETF LC End Date: 20120711 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None (but I have a private question) Nits/editorial comments: - ToC page 2 and 2.1 (title) page 3: my (US) dictionary prefers Assignement -> Assignment - 2.1 page 3: e.g. -> e.g., - 2.1 page 3: precieved -> percieved Regards francis.dup...@fdupont.fr PS: I have a private (i.e., not as a gen-art reviewer) question: what is the exact meaning of "MUST NOT IMPLEMENT"? Is it for instance acceptable to disable by default RSAMD5 in a current implementation to keep it "compliant"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-farrell-decade-ni-07/08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-farrell-decade-ni-07/08.txt Reviewer: Francis Dupont Review Date: 20120704 IETF LC End Date: 20120702 IESG Telechat date: unknown Summary: Ready Major issues: there were some issues raised in the mailing list but solved (?) in the last version (I reviewed an intermediate 07-08 version, last is 09 today). Minor issues: (not technical) more than 5 authors Nits/editorial comments: - Toc and 11 page 18: Acknowledgements -> Acknowledgments (i.e., American English vs. GB one) - 1 page 4, 3 page 8, 9.4 page 15: e.g. -> e.g., - 4 page 9, 7 page 11: i.e. -> i.e., 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-v6ops-ra-guard-implementation-04.txt (full)
(this message was stuck by the problems of the art.tools.ietf.org box but without too much trouble as the summary went through in time) I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-ra-guard-implementation-04.txt Reviewer: Francis Dupont Review Date: 20120606 IETF LC End Date: 20120612 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC Page 2: RA Guard -> RA-Guard - ToC page 2: Acknowledgements -> Acknowledgments - 1 page 3: a funny fact is DHCPv4 (which IMHO is not really over IP) is not sensible to this attack, at the opposite of DHCPv6... - 2 page 4, title: RA Guard -> RA-Guard - 3 page 9, point 6: in fact IPsec has its own issue with fragmentation... Nevertheless I agree with the proposed text. - 6 page 13: i.e. -> i.e., and e.g. -> e.g., - 7 page 14: Acknowledgements -> Acknowledgments - B page 18: organisations -> organizations 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-ietf-v6ops-ra-guard-implementation-04.txt (summary)
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-ra-guard-implementation-04.txt Reviewer: Francis Dupont Review Date: 20120606 IETF LC End Date: 20120612 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I am currently at a conference so I have not the time to type the few comments now. 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-ietf-appsawg-media-type-regs-10.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-appsawg-media-type-regs-10.txt Reviewer: Francis Dupont Review Date: 20120523 IETF LC End Date: 20120521 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 3: Acknowledgements -> Acknowledgments - 4.2.5 page 12: missing "." in: understood by implementors The ^ - 4.6 page 17: servies -> services - 7 page 26: suffx -> suffix - 8 page 27: Registions -> Registrations and mutiple -> multiple - 9 page 27: Acknowledgements -> Acknowledgments Regards francis.dup...@fdupont.fr PS: I want to signal the high quality of this document, for instance I got the idea to check where the types are case-insensitive and I found it in 10 seconds from the printed version (i.e., no grep :-)! ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-avtcore-feedback-supression-rtp-16.txt
In your previous mail you wrote: > I would like to point out that feedback implosion actually can be > seen as an implosion event. All the feedback traffic generated are > concentrated at the target for the feedback. Thus causing an > implosion of the feedback target under the "weight" of all the > feedback. > > But, seriously "Feedback Implosion" is an established expression > within computer science. Thus although it may not be all correct we > shouldn't change it. I would recommend that you google "Feedback > Implosion" all the hits on the first page are related to computer > science, at least for me. => hum, it seems the incorrect use of the term implosion is well established. IMHO it should be like the use of the incorrect term encrypted, so should be handled the same way: to fix it is the right way in French, in English it is pedantic so in general should not be fixed (and this is a real example for RFCs). So I give up on it... Thanks 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-avtcore-feedback-supression-rtp-16.txt
In your previous mail you wrote: > [Qin]:I can understand it is more sensitive to use "explosion" than > "implosion" in France.:-) => both words exist in both language with the same spelling and meaning. Perhaps do you mean we are more attached to use the right term in France (:-)? > However my understanding is implosion seems to mean feedback > messages overwhelm the network capacity. => this is the definition of explosion. > If we change "implosion" into "explosion", we seems to change the > meaning of "feedback implosion", that is to say, "feedback > explosion " means feedback message has already paralyzed the > network. The Network dies :-). I am aware that RFC4585 also use > "feedback implosion". Since this draft references RFC4585, Isn't > draft-ietf-avtcore-feedback-supression-rtp in accordance with > RFC4585? => you have the choice between using the correct term or keeping the wrong term because some did the error in referenced documents. You know my opinion. Regards francis.dup...@fdupont.fr PS: perhaps we should ask the RFC Editor to produce a collective Errata to fix this misuse of implosion for explosion? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-avtcore-feedback-supression-rtp-16.txt
In your previous mail you wrote: > > - Abstract page 1: implosion -> explosion (things which can implode are > rare :-) > > [Qin]: RFC4588 referenced by this document is using "implosion". So > I think it should be fine to use the same term in this document.:-) => RFC 2887 too. IMHO it is time to stop this "implosion" madness and to return to a correct language (BTW we have the same problem in French, for an unknown reason the word implosion is often used in place of explosion when it has the exact opposite meaning...). > [Qin]: Okay. > > > > - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very > correct. => the real problem is what is the SSRC. No spec is very clear, so the assumption it is not an IPv4 address is right IMHO. (i.e., I withdraw this comment) > Also it is easy to cause SSRC collision if IPv4 address can be > choose as 0.0.0.0 which is broadcast address. => BTW 0.0.0.0 is *never* a broadcast address (it could be the only address in this case :-). 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-avtcore-feedback-supression-rtp-16.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-avtcore-feedback-supression-16.txt Reviewer: Francis Dupont Review Date: 20120323 IETF LC End Date: 20120326 IESG Telechat date: 20120412 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: These are about the -15 version updated to -16 - I-D name: supression -> suppression - Abstract page 1: implosion -> explosion (things which can implode are rare :-) - Abstract page 1: signalling -> signaling - Toc page 2 and 9 page 12: Acknowledgement -> Acknowledgment - Introduction page 4: RTCP is not a well known abbrev: as it is first you have to introduce it. - Introduction page 4: same for SSM: please introduce the abbrev - Introduction page 4: implosion -> explosion - Introduction page 4 and other places: e.g. -> e.g., - 3 page 6: ,which -> , which - 4 page 6: missing characters/words in "the PT, FMT,length SSRC" - 4.1 page 7: all caps in "transport layer third-party loss" - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very correct. - 4.2 page 7: media Source -> media source - 4.2 page 8: :32 -> : 32 - 6.1 page 9: source- specific -> source-specific - 6.1 page 9: reason( -> reason ( & a RTCP -> an RTCP & NACK)and -> NACK) and - 6.2 page 10: Sources(BRS) -> Sources (BRS) - 6.2 page 10: a RTCP -> an RTCP - 6.4 page 10: receivers. e.g., -> receivers: e.g., - 6.4 page 10: a RTCP -> an RTCP - 6.5 page 11: a RTCP -> an RTCP (with a line break in the middle :-) - 7 page 11: supression -> suppression - 9 page 12: Acknowledgement -> Acknowledgment, VAN CAENEGEM -> van Caenegem, Johansson S -> Johansson - 10.2 page 14: please give the names of I-Ds - Appendix A page 14: usually the change log is in the reverse order (?) - A.8 page 16: ,Security -> , Security - A.14 page 17: refereces -> references 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
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-emu-chbind-14.txt Reviewer: Francis Dupont Review Date: 20120407 IETF LC End Date: 20120412 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Abstract page 1: NAS -> Network Access Server (BTW NAS has two meanings so this is really needed) - ToC page 3 and many other places: Radius -> RADIUS - Toc page 3 and 12 page 27: Acknowledgements -> Acknowledgments - Introduction page 5 (twice) and many other places: e.g. -> e.g., - Introduction page 5: advertized -> advertised - 3 page 6: I don't understand (i.e., wording problem): ... the EAP server can be far removed from the authenticator. ^^^ - 3 page 6: Lads -> LANs - 3 page 7 and other places: adversarial -> adversarious??? (BTW if my dictionary can't find it I have no problem to understand it) - 4 page 8: I really appreciated this section! - 4.1 page 9: a universal or an universal? - 4.3 page 12: I don't know the expression "pockets of trust"? - 5.2 page 15 (3 times) and at other places: i.e. -> i.e., - 5.3 page 16: IMHO the text should explain before the Figure 2 than the format can includes multiple ( Length, NSID, NS-Specific... ) triples (in fact one per attribute type) - 5.3 page 17: of 1 . -> of 1. (or of "1". if 1. is ambiguous) - 7.2 page 21: missing space in the figure? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | - 9.1 page 23: interesting conclusion (:-)! - 11.1 page 26: what is the size (or range) of this new parameter? IMHO the best should be to add a 10-XXX Unassigned line at the end (as it is done for eap-numbers). Note I believe IANA will have the same request... - 12 page 27: Sam hartman -> Sam Hartman - A.5 page 30: make the peer believe -> to believe? - A.5 page 30: from the on the -> from the one the? 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-ietf-dhc-dhcpv6-reconfigure-rebind-09.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dhc-dhcpv6-reconfigure-rebind-09.txt Reviewer: Francis Dupont Review Date: 20120407 IETF LC End Date: 20120412 IESG Telechat date: 20120412 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: Note I know very well DHCPv6 so some details could have been too obvious for me... - Abstract page 1: RFC 3315 -> RFC 3315 (DHCPv6) - Introduction page 4: msg-type -> message type - Introduction page 4: I'd like to get a better name for T1 but as far as I know it has no name, so I propose: T1 -> the timer T1. - 5 page 6: I don't understand (i.e., wording problem) "ignores" in: ... If the client does not receive a response from the server by the end of the retransmission process, the client ignores and discards the Reconfigure message. - 7 page 6: IMHO the fake Reconfigure message is already a known threat (but I have no concern to see it explained again) Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] (summary) review of draft-ietf-multimob-igmp-mld-tuning-05.txt
I am sorry but I missed the new version. I'll read it before sending the full review (anyway it will return in the processing queue). Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (summary) review of draft-ietf-avtcore-feedback-supression-rtp-15.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avtcore-feedback-supression-rtp-15.txt Reviewer: Francis Dupont Review Date: 20120323 IETF LC End Date: 20120326 IESG Telechat date: unknown Summary: Ready Major/Minor issues: None Regards francis.dup...@fdupont.fr PS: I'll send the full review as soon as I have the time to type it. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (summary) review of draft-ietf-multimob-igmp-mld-tuning-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-multimob-igmp-mld-tuning-05.txt Reviewer: Francis Dupont Review Date: 20120321 IETF LC End Date: 20120320 IESG Telechat date: unknown Summary: Not Ready Major issues: the wording of the document is too poor and can lead to confusion. The use of RFC 2119 key words is bad, in particular for MAYs. Regards francis.dup...@fdupont.fr PS: I'll send the full review as soon as I have the time. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] (quick) review of draft-ietf-rmt-flute-revised-13.txt
In your previous mail you wrote: > > Minor issues: not a real one (it was inherited from RFC 5775) but > > in the security considerations there is nothing about IPsec/AH > > (BTW people who didn't implement it didn't implement the transport > > mode (for IPsec/ESP) too :-). > > Yes, this is done deliberately. We do not mention IPsec/AH at all > and our minimum security requirements are aligned with that of > RFC 5775. For instance RFC5775, Section 5.1.1, says: > >"The ALC sender SHALL use an IPsec SA configured for Encapsulating > Security Payload (ESP) protocol [RFC4303] operation with the option > for data origination authentication enabled." > > I think the situation is clear enough. => yes: even I still like to get IPsec/AH I understand the mistake (if it is a mistake) was done with the RFC 5775 so it is far too late. > > - 1 page 6: please add a reference to RFC2357 (or make it an > > explicit reference) > > I don't understant. We already have a reference to that RFC in section > 1, p6: >"This specification contains part of the definitions necessary to > fully specify a Reliable Multicast Transport protocol in accordance > with [RFC2357]." > What is the point? => I have in the .txt version: This specification contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357. ^^^ and it is the only occurrence of 2357. BTW I am fine of course with your personal (?) version of the document (:-)! > I've clarified what a TSI looks like as follows: > > NEW: > One of the fields carried in the ALC/LCT header is the Transport > Session Identifier (TSI), an integer carried in a field of size 16, > 32, or 48 bits (note that the TSI may be carried by other means in > which case it is absent from the LCT header [RFC5651]). => fine! > > - 7.2.2 page 30: this is the place I am surprised to not get > > IPsec/AH [RFC4302] as an alternative to IPsec/ESP [RFC4303] > > when integrity and sender authentication is wanted. > > An interesting reference: > "A Cryptographic Evaluation of IPsec" > Niels Ferguson and Bruce Schneier > http://www.schneier.com/paper-ipsec.pdf > Section 3.1: > "Recommendation 2: Eliminate the AH protocol." > > Another reference on the same topic: > "Avoiding Authentication Header (AH)" > draft-bhatia-ipsecme-avoiding-ah-00 > > I don't follow the IPSECME WG and therefore I cannot > say whether there is consensus or not on the topic. => there is not and IMHO there won't be... AH will be withdrawn because people are tired to explain how it can be used, not because people are convinced it is useless. > However it seems to me it's not worth adding a reference > to AH. We can do without, using the functionalities already > provided in the "minimum security requirements". => this was addressed with the (previous) minor issue: IPsec/AH is not in RFC 5775 so there is no reason it should be in draft-ietf-rmt-flute-revised. Thanks francis.dup...@fdupont.fr PS: I still wait for a new version. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (quick) review of draft-ietf-rmt-flute-revised-13.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rmt-flute-revised-13.txt Reviewer: Francis Dupont Review Date: 20120229 IETF LC End Date: 20120224 IESG Telechat date: 20120301 Summary: Almost Ready Important note: due to last comments from the Last Call it seems there will be a -14 version... Major issues: None Minor issues: not a real one (it was inherited from RFC 5775) but in the security considerations there is nothing about IPsec/AH (BTW people who didn't implement it didn't implement the transport mode (for IPsec/ESP) too :-). Nits/editorial comments: - ToC page 3 and 9 page 36: Acknowledgements -> Acknowledgments - 1 page 6: please add a reference to RFC2357 (or make it an explicit reference) - 1.1.3 page 7: I suggest to add the "diode" in the environment where FLUTE can be used (diodes are more common than you can believe :-) - 3 page 9 (and other places): e.g. -> , e.g., and i.e. -> , i.e., - 3.1 page 9: I'd like to get the type (e.g., integer) of fields, for instance I have no idea of what a TSI really looks like. - 6 page 27: session ; -> session; and at the next line session. -> session; (only the last item gets a dot) - 7.2.2 page 30: this is the place I am surprised to not get IPsec/AH [RFC4302] as an alternative to IPsec/ESP [RFC4303] when integrity and sender authentication is wanted. - 10 page 36: 52134 Herzogenrath, Germany -> 52134 Herzogenrath Germany - Authors' Addresses page 45: US -> USA (note: the Innovallee; is dubious too) Regards francis.dup...@fdupont.fr PS: I expect to get the new version so to have more time to read (more) carefully the body of the document (i.e., 3 - 6). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-mcgrew-tls-aes-ccm-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-mcgrew-tls-aes-ccm-03.txt Reviewer: Francis Dupont Review Date: 20120224 IETF LC End Date: 20120313 IESG Telechat date: known Summary: Ready Major issues: None Minor issues: None but please check my comment about 8.2 Nits/editorial comments: - ToC page 2 and 6.2 page 6: a 8-octet -> an 8-octet - ToC page 2 and 9 page 6: Acknowledgements -> Acknowledgments - 3 page 4: the wording about authentication tags is a bit strange: the first line uses singular and the next plural? - 3 page 4: the Nonce layout is not ambiguous for me but it doesn't use a common / easy to recognize programming language - 8.2 page 6: as the counter reuse is really critical I'd like to get a review by a cryptographer of 8.2 and 3. 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-decade-problem-statement-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-decade-problem-statement-05.txt Reviewer: Francis Dupont Review Date: 20120224 IETF LC End Date: 20120306 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 1 page 3: P2P and CDN are not in the list of well known abbrevs (IMHO for the first one because P2P means Point-to-Point too) so should be introduced at the first use in the body (and for CDN IMHO as soon as possible, this is why I put this in 1) - 1 page 3: in the networks. -> in networks. ? - 3.1 page 4: IMHO [Internet Study 2008/2009] should be removed to leave only the reference, i.e., [Internet_Study_2008-2009] - 4.1 page 7: 'nor can they manage access' is a wording which could (so should) be improved a bit, IMHO 'nor access' is enough - A pages 11 and 12: e.g. -> e.g., (also at end of line but it is in an appendix 'to be removed by the RFC Editor'...) Regards francis.dup...@fdupont.fr PS: my dictionary dislikes 'infrastructural'? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (re)review of draft-weil-shared-transition-space-request-14.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-weil-shared-transition-space-request-14.txt Reviewer: Francis Dupont Review Date: 20120208 IETF LC End Date: 20120216 IESG Telechat date: 20120216 Summary: Ready Major issues: None Minor issues: None (but with proposed changes agreed during the (last) last call applied) Nits/editorial comments: - 1 page 4: the CPE abbrev is not well known so should be introduced (or marked as well known as there are more and more documents in this area) - 4 page 7: my dictionary says the word proscription exists only singular, i.e., proscriptions -> proscription Personal comments: - I am in favor of this document (as explained by some in the IETF ML, other solutions are worse) - I have no illusion about how it will be applied in the real world - this document and many others about CGN/LSN make the dangerous assumption there will be only one level of CGN/LSN - to delay the application of the document (i.e., the allocation of the shared address space) long enough there will be no /10 available should be a very unfair way to (not) solve the problem (:-) 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-dnsext-xnamercode-00.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsext-xnamercode-00.txt Reviewer: Francis Dupont Review Date: 20120202 IETF LC End Date: 20120206 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - no Acknowledgments? - Author's Address page 8: please add the country (USA) in the postal address - Change History page 8 (BTW will be removed by the RFC Editor :-): opion -> option Thanks 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-os-ietf-sshfp-ecdsa-sha2-04.txt
In your previous mail you wrote: > > Minor issues: not a real issue but I am not convinced there is a real > > crypto reason to give up SHA-1. At the first view the attack against > > SSHFP is a pre-image one, but: > > - I leave the question to cryptographers of the security directorate > > - there are many not-crypto reasons to move from SHA-1 to SHA-256 > > Hi, > > I have added some text there: > >ECDSA public key fingerprints MUST use the SHA-256 algorithm >for the fingerprint as using the SHA-1 algorithm would >weaken the security of the key, which itself can use only >SHA-2 family of algorithms RFC 5656 (Section 3.1.1). => I am afraid it is another not-crypto reason... > But I am also not a cryptographer, => I am not a cryptographer too (I just worked with cryptographers, military cryptographers exactly, i.e., the worst kind of cryptographers :-) > so it's just my guts telling me > that if a key is allowed to use only SHA-2, we should keep it in sync > here. => the 2 ideas are: - keep the requirement (i.e., it is the right one and even there could be no good crypto reasons) - get a wording for the justification which doesn't make cryptographers too unhappy (they won't be really happy anyway: this is a part of being cryptographers :-) Of course for the second part the best should be to get a feedback from the crypto (oops, the security) directorate. 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-ietf-pcn-signaling-requirements-07.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-signaling-requirements-07.txt Reviewer: Francis Dupont Review Date: 20120106 IETF LC End Date: 20120113 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in the whole document: behaviour -> behavior and signalling -> signaling (note the spelling of collocated is dubious too) - Abstract page 1: in the latter case -> in the first case - Abstract page 1: the usage is to not refer to RFC in the Abstract - ToC page 2: Acknowledgements -> Acknowledgments - 2 page 3: measures- -> measures (in general the document is at the limit of abuse of '-' character, here it is clearly a typo) - 6 page 6: Acknowledgements -> Acknowledgments - 6 page 6: I don't like the term 'generated', IMHO you can easily find a better/nicer term. - 7.2 page 7: C. Le Faucher, -> C., Le Faucheur, ^ ^ 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-os-ietf-sshfp-ecdsa-sha2-04.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-os-ietf-sshfp-ecdsa-sha2-04.txt Reviewer: Francis Dupont Review Date: 20111210 IETF LC End Date: 20120103 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: not a real issue but I am not convinced there is a real crypto reason to give up SHA-1. At the first view the attack against SSHFP is a pre-image one, but: - I leave the question to cryptographers of the security directorate - there are many not-crypto reasons to move from SHA-1 to SHA-256 Nits/editorial comments: - I'd like to get only the SHA-256 name and no variants, in particular no SHA256 (my idea is to always use the same name) - IMHO the 'OpenSSH' format is just the PEM format - IMHO the multi-line fingerprint in text RRs must be enclosed by parenthesis to be correctly parsed - 1 page 3: the abbrev RR should be introduced as soon as the term 'resource record' is used - 1 page 3: ; and -> ; - 3.2.1 page 4: this is the MUST I am not convinced by the justification (BTW I suggest to fix the justification if it is too wrong, and to keep the MUST) - 7 page 7: software implementations -> implementations - 7 page 8: BTW I like the disclaimer: ... Regardless of whether or not the attacks on SHA-1 will affect SSHFP, it is believed (at the time of this writing) that SHA- 256 is the better choice for use in SSHFP records. - 8.2 page 9: Di!erential -> Differential - Author's Address: CZ -> Czech Republic 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-ppsp-problem-statement-07.txt
Oops, I missed to include two spelling errors: requsted (4 page 11) and Procotol (in figures, multiple occurrences). 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-ppsp-problem-statement-07.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ppsp-problem-statement-07.txt Reviewer: Francis Dupont Review Date: 2024 IETF LC End Date: 2030 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None (at the exception of the space character isuse) Nits/editorial comments: First there is a real issue with the space character (a zillion of them are mssing in place they are required) in the document. I'll put a list in PS... - Header page 1: seng -> Seng - 1 page 4: .. -> . or ... - 1 page 4: open, standard -> open standard (or standard, open if 'open standard' is not the intended meaning) - 1 page 4: Multiple, similar -> Multiple similar - 1 page 4: in theory the CDN abbrev should be introduced - 1 page 5: and streaming control -> streaming control - 2 page 6: e.g. -> e.g., - 3.2 page 9 and 5.2 page 15: 3rd -> third - 3.3 page 9: for fixed Internet -> for the fixed Internet and to fixed Internet -> to the fixed Internet - 3.3 page 10: In the mobile networks -> In mobile networks - 3.3 pahe 10: Third, mobility issue. -> Third, mobility issue: - 3.4 page 10: settop boxes -> set-top boxes - 5.1 page 14: I don't like the term normalized - 5.3 page 16: setbox -> set-top box (or STB?) - 5.3 page 16 figure 4: STB -> set-top box (BTW there is enough place!) - 5.4 page 17: I can't understand the difference between super-nodes and super-peers - 5.4 page 17: as the peer in this section are phones and there is no phone-phone protocol for not technical reasons, of course there is no use case for the peer-peer protocol. - 5.5 page 17: When -> when - 5.5 page 17: in "To do this, it requests..." I don't know what is the "it" so I can't understand the paragraph (BTW cache nodes are in plural so they can be "they", not "it") - 5.5 page 17: needn't -> do not need Regards francis.dup...@fdupont.fr PS: missing spaces: - Header: between initial and name, at the exception of the first author - Abstract: Peer_(P2P and Protocol_(PPSP) - Toc page 3 and 4 page 11: PPSP:_Standard - 1 page 4: * 2014_[Cisco] * PPstream [PPStream],_UUSee [UUSee]_and CNTV_[CNTV] * (e.g.,_AkamaiNetSession [Akamai], ChinaCache_[ChinaCache]) - 3.1 page 8: points._P2P - 3.2 page 8: vastly_the - 3.2 page 9: * UUSee_[UUSee], * RayV_[RayV] and Forcetech_[Forcetech]. * [RFC 5693]._However, * providers._On - 3.3 page 9: transmission_(esp. (BTW esp. -> especially) - 3.3 page 10: which_may - 4 page 11: peer-list_(potentially - 4 page 12: Figure 1._The - 5.3 page 16: With PPSP,_peers - 5.4 page 17 (extra space): P2Pstreaming ) is -> P2Pstreaming) is - 9 pages 22 and 23: * [VoD] Yan Huang et al,_Challenges, * applications,_http://labs.adobe.com/technologies/cirrus/ * Communications of the ACM,_Vol. 53,_No. 10, Pages 72-82. * Yong Liu et al,_"A survey * Applications,_Volume 1, * Number 1,_18-28,_Springer,_2008. * H. Jiang et al,_"Efficient * distribution services,_http://www.3gpp... * Network,_Jeonghun Noh et al,_MOBIMEDIA '09. * J. Peltotaloet al.,_"A real-time * (misplaced) Y. Huang et al,_"Challenges, * Communication Review,_38(4):375-388, 2008. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-krb-wg-gss-cb-hash-agility-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-krb-wg-gss-cb-hash-agility-08.txt Reviewer: Francis Dupont Review Date: 2005 IETF LC End Date: 2007 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2: please get a rule about caps and keep it (i.e., either put a cap only in the first word or to all words, and avoid considerations and Considerations in two following lines :-) - Toc page 2 and 6 page 10: Acknowledgements -> Acknowledgments - 3 page 7: ecryption -> encryption - Author's Address page 11: US -> USA BTW if you find a way (or someone) to improve the general wording style, please do it (a document of this length should be more pleasant to read IMHO...) 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-salter-rfc5430bis-01.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-salter-rfc5430bis-01.txt Reviewer: Francis Dupont Review Date: 20111022 IETF LC End Date: 20111031 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Status page 1: This Internet-Draft will expire on 2 April 2011. -> 2012 (don't fix the draft but the tool which gives this wrong date :-) - Toc page 2 and 6 page 9: Acknowledgements -> Acknowledgments - 4 page 7: ClientHellomessage -> ClientHello message - 9 page 12: extra white line in: A Transitional Suite B TLS system configured at a minimum level of security of 128 bits, MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite and/or the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite is preferred, and if it is offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite (if present). - 9 page 13 (twice, last occurrences): TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA -> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 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-jdfalk-maawg-cfblbcp-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-jdfalk-maawg-cfblbcp-02.txt Reviewer: Francis Dupont Review Date: 20111020 IETF LC End Date: 20111020 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 3 and 6 page 28: Acknowledgements -> Acknowledgments - 1 page 4: usually the introduction goes first (i.e., it is not an ISO document so usages could be different). Note I have no concern about this, please take it as a comment. - 1 page 7 (Reverse DNS): an A record -> an A or record - 2 page 8: figure 1 is not aligned, I suggest to add a space after the word 'Spam' - 4.1 page 19 item 3: the RPKI provides a secured proof of address owning, better than Reverse DNS and WHOIS. And if the RPKI is not really deployed today one can expect it will be soon (ask sidr WG chairs to propose a text?) - 7 page 29: the security considerations don't follow the required style. I propose to add a short abstract with the main points of referenced sections. - 8 page 30: references should be split into normative and informative references, as the document itself is informative I suggest to add the word "Informative" in the section title (and to update the ToC if not done automagically :-). - Author's Address page 36: US -> USA 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-payload-rfc3189bis-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-payload-rfc3189bis-02.txt Reviewer: Francis Dupont Review Date: 20111014 IETF LC End Date: 20110926 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I've seen some comments during the last call, perhaps this is why the current version is 03 but I reviewed (and forgot to send the review) the version 02. Comments: - 3.3.1 page 14: I suggest m=* in place of m=?? - 4 page 15 (comment): in general encryption is done after compression for crypto reasons and common sense: encryption gives a perfectly random result, i.e., something impossible to compress... - Authors' Addresses page 19: United States -> USA Regards (and sorry for the delay, but my comments could (should!) be handled by the RFC Editor) 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-weil-shared-transition-space-request-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-weil-shared-transition-space-request-03.txt Reviewer: Francis Dupont Review Date: 20110827 IETF LC End Date: 20110916 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: None (but need feed back from IANA) Nits/editorial comments: - the text uses both assignment and allocation terms, they are not really equivalent so I recommend to ask IANA to check and if needed to fix the use of these terms. Anyway this document is for IANA! - authors' list page 1: LILJENSTOLPE -> Liljenstolpe - ToC page 2 and Appendix A page 10: Acknowledgements -> Acknowledgments - 4 page 6: Infrastructure provider use -> Infrastructure Provider use - 4 page 6: e.g. -> e.g., - 7 page 9: I don't like to get RFC 2119 in informative references - Authors' Addresses pages 11 and 12: * AU -> Australia * please remove empty Fax and URI * US -> USA (if it is really the other Vancouver :-) Regards francis.dup...@fdupont.fr PS: IMHO this prefix could be a great help in NAT444 and similar device operation, so I support it. PPS: the Almost before Ready doesn't mean the document needs to be changed now, just the IANA should provide her comments first. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-kivinen-ipsecme-secure-password-framework-01.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-kivinen-ipsecme-secure-password-framework-01.txt Reviewer: Francis Dupont Review Date: 20110806 IETF LC End Date: 20110824 IESG Telechat date: known Summary: Ready (but see below) Major issues: there is one not about the document itself but about the goal of the document. Unfortunately only the IESG can solve the mess introduced by 3 different proposals to do the same thing... Minor issues: None Nits/editorial comments: - 1 page 3: I.e. -> I.e., - 1 page 4: adminstrator -> administrator - 1 page 4 (dubious wording): shared secret (\n) shared - 1 page 4: adminstrative -> administrative - 1 page 4 (twice): i.e. -> i.e., - 2 page 6 (4 times); preprosessing -> preprocessing - 2 page 6: preprossing -> preprocessing - 3 page 8: passwod -> password - 4 page 9: unnecessarely -> unnecessarily - Author's Address page 14: FI -> Finland Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (full/final) review of draft-ietf-opsawg-oam-overview-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-oam-overview-05.txt Reviewer: Francis Dupont Review Date: 20110804 IETF LC End Date: 20110811 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: as I explained in the previous review, I deeply disagree with the presentation of "ICMP Ping" for traceroute. If traceroute (and its path MTU discovery variants) is included in the document, IMHO it must be the UDP version (the historical, documented in an RFC and most reliable one). Nits/editorial comments: - 3.2.2 page 10 (twice), 4.2.1 page 14 and 4.10.3.4 page 27: e.g. -> e.g., - 4.2.2 page 14 and 4.10.1 page 25 (twice): i.e. -> i.e., - 4.5.3 page 18: acknowledgement -> acknowledgment (for spelling consistency) - 5 page 31: IMHO the Security Considerations should be argumented (and IMHO it is not true that OAM and security are really orthogonal) Regards francis.dup...@fdupont.fr PS: I've downgraded the ICMP traceroute point to minor. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] (partial) review of draft-ietf-opsawg-oam-overview-05.txt
In your previous mail you wrote: Since Traceroute is not a standard, but rather an application, it has several implementations. Indeed, the UNIX implementation uses UDP messages - this is also described in RFC 2151 (informational). The windows implementation of Traceroute, on the other hand, uses ICMP Echo messages, see: http://technet.microsoft.com/en-us/library/bb491018.aspx => perhaps I over interpreted the first case of RFC 1812 4.3.2.7 but as there is no real and stable definition of what is an ICMP error message (something fixed in ICMPv6) I am afraid there are some router implementations which just never send an ICMP error message at the result of receiving a ICMP Echo Request with TTL=1 (if you believe this should have been noticed there are so many reasons to get partial results from traceroute/tracert...) So I think maybe the draft should explain that Traceroute is an application that has more than one implementation, and that it can be implemented with either UDP or ICMP messages. Does this make sense? => yes but if you detail the mechanism I really suggest to describe the UDP version. Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (partial) review of draft-ietf-opsawg-oam-overview-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-oam-overview-05.txt Reviewer: Francis Dupont Review Date: 20110723 IETF LC End Date: 20110720 IESG Telechat date: unknown Summary: Not Ready Major issues: 4.1 page 13 explains the use of ICMP in Traceroute: this is plainly wrong: ICMP can't be used in this way because no ICMP error can be triggered by an ICMP. BTW: - traceroute uses UDP probes just for this reason - I put this as a major issue because this must not be published in a document from the IETF Regards francis.dup...@fdupont.fr PS: I stopped the review at this point but I'll resume and send a full review ASAP (I like the document, OAM is something really useful and to try to organize it a great idea). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dkim-rfc4871bis-12.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dkim-rfc4871bis-12.txt Reviewer: Francis Dupont Review Date: 20110720 IETF LC End Date: 20110630 IESG Telechat date: known Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 4 and appendix F page 77: Acknowledgements -> Acknowledgments - Authors' Addresses page 78: please consider to add the zip code to all addresses in the USA? Regards francis.dup...@fdupont.fr PS: I apologize to be a bit late but the document is big and has no critical issue which needs a quick fix. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-mpls-mldp-recurs-fec-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-mldp-recurs-fec-03.txt Reviewer: Francis Dupont Review Date: 20110720 IETF LC End Date: 20110711 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: None 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-forte-lost-extensions-06.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-forte-lost-extensions-06.txt Reviewer: Francis Dupont Review Date: 20110710 IETF LC End Date: 20110721 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 5.2 page 10 (comment): the comment explaining the default value is true for backward compatibility is a bit far, i.e., I had the question before reading the answer... (PS: the explaination is 53 page 11) - 5.4 page 11: consinstent -> consistent - 9.2 page 20: -> Regards francis.dup...@fdupont.fr PS: I haven't tried the whole suite of relax NG checkers: I believe you already used them. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] (not yet) review of draft-ietf-dkim-rfc4871bis-12.txt
It seems there is a debate about the draft-ietf-dkim-rfc4871bis-12.txt document so I differ a bit the review (I am the assigned gen-art reviewer) for the case a new version could be published soon... If I am wrong and I should review it ASAP please signal it to me at my other Email (less spam and I read it at least once per day) at fdup...@isc.org. 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-ietf-netlmm-pmipv6-mib-05.txt (resent???)
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netlmm-pmipv6-mib-05.txt Reviewer: Francis Dupont Review Date: 20110527 IETF LC End Date: 20110512 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Toc page 2 and 9 page 67: Acknowledgements -> Acknowledgments - 5 page 7: incoherent zip/country order for Japan - 5 page 9: pmip6Stats:pmip6BindingRegcounters -> ^ pmip6Stats:pmip6BindingRegcounters (fortunately it is in a comment, but an ASN.1 comment :-) - 5 page 16: reindent pmip6MagProxyCOATable description (same pages 39 and 40 for pmip6LmaMinDelayBeforeBCEDelete) - 5 page 22 (pmip6MagBLlMnIdentifier): bad wording (the two is for the length, not the value). same page 28 for pmip6BindingMnLlIdentifier - 5 page 24: reformat pmip6MagBLAccessTechnologyType description - 5 page 24 (pmip6MagBLTimeRecentlyAccepted): acknowledgement -> acknowledgment (same page 29 for pmip6BindingMagLinkLocalAddress, page 30 for pmip6MissingMnIdentifierOption, page 31 for pmip6NotLMAForThisMobileNode, etc) - 5 page 31 (pmip6MissingMnIdentifierOption): router. -> router, - 5 page 37 (pmip6CounterDiscontinuityTime): viz. ??? - 5 page 41 (pmip6LmaTimestampValidityWindow): bad wording: length of time ??? - 5 page 50 (pmip6CoreReadOnlyCompliance): missing final '.' in description - 6 page 63: extra space in 'pmip6MobileNodeGeneratedTimestampInUse :' - 6 page 63: IPSec -> IPsec - 10 page 67: presentation should be uniformized. Regards francis.dup...@fdupont.fr PS: I don't remember if I sent this review, so anyway I resend it. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt Reviewer: Francis Dupont Review Date: 20110618 IETF LC End Date: 20110623 IESG Telechat date: unknown Summary: Not Ready Major issues: the "DNS resolver" selection problem is not a DNS problem: it comes from a common use of the DNS which is not in the DNS model. I agree it is a real world problem but its origin IMHO requires more care about its explaination. I suggest to ask the DNSOP WG about what to do (and to get the correct terminology, IMHO resolver -> caching server). BTW DNSSEC could change this: it makes views of not local domains more coherent and the different kinds of DNSSEC aware resolvers (*not* caching servers) are host software. Minor issues: - I don't understand why the notion (and well known term) of ingress filtering is not used... - I have a mixed feeling about the whole document: IMHO it is more in the scope of the mif WG, and I am not convinced by it at the exception of the negative points (i.e., multi-homing in IPv6 still doesn't work at it should...). So what is its real goal? Nits/editorial comments: - 1 page 3: missing comma? in "Whenever a host or small network (which does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks IPv6 ^ , address is assigned by each respective service provider resulting in hosts with more than one active IPv6 addresses." - 1 page 3: definced -> defined? - 1 page 4: in its standard model, the DNS is location independent so any caching servers should return the same thing... (cf major issue) - 1 page 4: resolvers -> caching servers - 1 page 4: introduce thee uRPF abbrev (or better use 'ingress filtering') - 3.1 page 6 (comment): the explaination of scenario 2 strongly suggests the use of DHCPv6! - 3.3 page 8: another place where 'ingress filtering' is better - 3.3 page 8 (and further): there are hosts which manages multiple default routers (BTW this doesn't solve the problem at all, the text is just not accurate as it assumes no such host exists) - 3.3 page 9: ie, -> i.e., - 3.3 page 9: policy routing (Cisco term, Juniper has the same thing with a different name) allows a router to determine which traffic should be sent to which network (i.e., the text is false). - 7.2 page 15: coexistence -> co-existence (i.e., I believe the title is right) - 8 page 16: his -> its (the policy distributor is a device) 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-pcn-sm-edge-behaviour-05.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-sm-edge-behaviour-05.txt Reviewer: Francis Dupont Review Date: 201106017 IETF LC End Date: 20110610 IESG Telechat date: unknown Summary: Ready with nits Major issues: None Minor issues: - more than 5 authors - the American spelling for behaviour is behavior - there is a problem with security considerations (5.8 page 16 and 6 page 17) Nits/editorial comments: - Toc page 2 and 8 page 17: Acknowledgements -> Acknowledgements - 1.1 page 6, 3.2.3 page 8, and etc: signalling -> signaling - 3.1 page 7, 4 page 13, and etc: collocated -> co-located? - 5.2.1 page 14: tunnelled -> tunneled, signalled -> signaled - Authors' Addresses page 19: add missing Country 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-savi-fcfs-09.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-savi-fcfs-09.txt Reviewer: Francis Dupont Review Date: 20110530 IETF LC End Date: 20110526 IESG Telechat date: unknown Summary: Ready with nits Major issues: None Minor issues: - the main issue is the name of the draft, fortunately it should be solved with the publication as an RFC (the name doesn't suggest what the document is about, in particular the fact it is based on IPv6 ND snooping). Nits/editorial comments: - many, many occurrences: i.e. -> i.e., and e.g. -> e.g., (IMHO in the middle ' i.e. ' -> ', i.e.,' but ask the RFC Editor) - Abstract page 1: please avoid abbrevs in the abstract (FCFS and SAVI) even there are in the title. - ToC 3 and Appendix A page 24: behaviour -> behavior (and 2.3 page 5, 3.2.3 pages 13 and 14, etc) - Introduction page 4: same comment about the Introduction (BTW abbrevs must be introduced here even they already are in the Abstract) - 2.3 page 5: my speller complains about Neighbour (English vs American), IMHO we can ignore it. - 2.6 page 9 (figure): SWICTH-B -> SWITCH-B - 3.2.3 page 13: millisconds -> milliseconds (and pages 14 and 16 millisecs -> milliseconds) - 6 page 23: Add missing countries (USA and Spain) - A.1.1 page 25: 802.1x -> 802.1X - A.1.1 page 26: Access Node(DSLAM) -> Access Node (DSLAM) - A.1.1.1 page 26: sub-case:SAVI -> sub-case: SAVI 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-haleplidis-forces-implementation-experience-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-haleplidis-forces-implementation-experience-02.txt Reviewer: Francis Dupont Review Date: 20110509 IETF LC End Date: 20110503 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - Abstract page 1: forwarding -> Forwarding - ToC page 2 (English -> US spelling): Developement -> Development Acknowledgements -> Acknowledgments - 2 page 4: even with the section 1 just before I am not convinced it is useless to introduce FE and CE abbrevs. - 2 page 4: inconsitent singular/plural in "[RFC5812] presents a formal way to define FE Logical Functional Blocks (LFBs) using XML. LFB configuration components, capabilities, and associated events are defined when the LFB is formally created. The LFBs within the Forwarding Element (FE) are accordingly controlled in a standardized way by the ForCES protocol." I suggest "when LFBs are formally created." - 2 page 4: etc. -> etc, ??? - 2.1 page 4 (bad wording): protocol and model and its main goal -> protocol and model, and its main goal ? - 3.2 page 7: IPSec -> IPsec - 3.3 page 7: develeper -> developer - 3.3 page 7: new components etc -> new components, etc - 3.3.1 page 8: deconstructor -> destructor - 3.3.1 page 9: difficulty lie -> difficulty lies - 3.4.2 pages 14 and 15 (multiple): "Do this" is not wellcome in a formal description, it should be a goto X IMHO. - 3.4.2 page 14: mainheader -> main header ??? - 3.4.2 page 14 (comment): as a previous Lisp/functional language programmer I am not very happy with an explanation about difficulty from recursion. - 3.4.2 page 15 (twice): it must have inside -> it must include - 4 page 17 (title): Developement -> Development - 5 page 18 (title): Acknowledgements -> Acknowledgments - 7 page 20: IPSec -> IPsec Regards francis.dup...@fdupont.fr PS: I forgot to send this in time, I apologize. BTW all the comments and suggestions fall typically in the scope of 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-sidr-rpki-manifests-09.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sidr-rpki-manifests-09.txt Reviewer: Francis Dupont Review Date: 20110323 IETF LC End Date: 20110324 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2 and 10 page 16: Acknowledgements -> Acknowledgments - 1 page 3: EE -> End Entity (EE) - 3 page 4: SIA -> SubjectInfoAccess (SIA) (but OID is a well-known abbrev according to the RFC Editor) - 4.2.1: I don't know if the document should be more accurate about the filename syntax? - 4.2.1 pages 5 and 6: modelled -> modeled - 5.1 page 8: IMHO the key point for the security is the 3, isn't it? - 5.2 pahe 9: RPs who -> RPs which ?? - 5.2 page 9: intot he -> into the - 6.1 2 page 10: completness -> completeness - 6.3 page 12: I have a concern about this wording: An invalid manifest MUST never be used even if the manifestNumber is greater than that of other valid manifests. ^^^ - 6.6 page 14: endeavour -> endeavor - 10 page 16: behaviour -> behavior 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-intarea-server-logging-recommendations-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-intarea-server-logging-recommendations-03.txt Reviewer: Francis Dupont Review Date: 20110305 IETF LC End Date: 20110311 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 1 page 3: "... will diminish but this is a years long perhaps decades long process." I had a concern about the plural (years/decades) but I consulted someone with a better English than me who answered the whole construct was pretty bad... - 1 page 3: this documents. -> document - 2 page 4: e.g. -> e.g., - 2 page 4: preffered -> preferred (about this statement, should the document explain a localtime only is not enough (it is ambiguous during one hour per year, unfortunately it is trivial to know which one :-)?) 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-xcon-examples-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-xcon-examples-08.txt Reviewer: Francis Dupont Review Date: 20110305 IETF LC End Date: 20110304 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in general there are some pagination issues but they should be solved by the RFC Editor. - ToC page 2 and 12 page 81: Acknowledgements -> Acknowledgments - 2 page 3, 5.2 page 16, 5.3 page 24, 6 page 32, 6.2 page 37 and 7.4 page 70: i.e. -> i.e., - 5 page 11, 5.1 page 13, 6.1 page 34, 6.2 page 36, 6.3 page 40, 6.4 page 44, 6.5 page 44, 7.2 page 59 and 8.1 page 76: e.g. -> e.g., - 5.2 page 19 '6.': conference . -> conference. - 5.3 page 23 and 7.2 page 57: e.g, -> e.g., - 5.3 page 24: flavour -> flavor - 6.2 page 37: "revconly" -> "recvonly" - 6.3 page 42: i. e. -> i.e., - 7.2 page 59: mantained -> maintained - 7.3 page 63: partecipants -> participants - 7.3 page 64: comnpletely -> completely - 8.1 page 75 figure 27: to Bob | -> to Bob | - 8.2 page 77: disconnetting -> disconnecting - 11 page 80: thw -> the (note: it is in a to-be-removed section) - 11 page 80 and 13.2 page 81: RFC2606 reference is used in this to-be-removed-before-publication section and *only* in it (warning). - Authors' addresses page 82: US -> USA Regards francis.dup...@fdupont.fr PS: I can see you use scenarios in place of scenarii but as there are some from Italy in authors if this is fine for them this is fine for me. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-sidr-cp-16.txt
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sidr-cp-16.txt
Reviewer: Francis Dupont
Review Date: 20110224
IETF LC End Date: 20110221
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- the document uses RFC{[wxyz]}4 as references in place of short
titles of references, this is not good because:
- it makes the reference hard to follow, i.e., the reader has
to solve the indirection each time
- it strongly binds the document livetimes to references'
- 1 page 7: IMHO the document should clearly state it is about
public key certificates (vs attribute certificates)
- 1 page 7: in
"In the interest of keeping the document as short as
reasonable, a number of sections contained in the template are
^^^
were/have been?
omitted from this policy because they did not apply to this PKI."
^^^ do?
- 1.3.2 page 9: please check the 1.4.1 pointer
(could be 1.5.1?)
- 2.4 page 14 (and at other places): I learnt Latin so I have
a concern with 'data is' (as data is the plural of datum).
I leave this point to the RFC Editor who will fix or won't fix this...
- 3.2.2 page 16: bedescribed -> be described
- 3.2.4 page 16: please extend the SIA abbrev
(it is its first occurrence)
- 4.3.2 page 20:
"The means by which a subscriber is notified is defined..."
^^ are?
- 4.5.2 page 21: TA -> Trust Anchor (it is its only occurrence)
- 13 page 40 (many times): ," -> ",
(to conform to RFC standard style)
- Authors' Addresses: +1 (617) xxx is not in an E.123 format,
why not +1 617 xxx?
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-herzog-setkey-03.txt (resent)
In your previous mail you wrote:
> Minor issues: I have an ASN.1 question related to implicit tagging:
> this can lead to encoding ambiguity with nested CHOICEs for instance,
> it is something which could be addressed in specs, is the extension
> mechanism an issue (i.e., the spec can be correct now but become
> incorrect whene extended) and BTW is there a known tool to check
> the syntax against this particular issue?
Actually, I don't have any changes to propose in response to this, yet
and I'm not sure I understand your question. I am not aware of any
issues regarding extension, nor am I aware of any tools for checking for
it. But I am not an ASN.1 expert. Can you expand a little more on this
issue for me?
=> this is something I got working on an interim version of SCVP
(RFC 5055):
with implicit tagging:
CHOICE {
foo [0] Foo,
... }
Foo ::= CHOICE {
bar [0] Bar,
...}
the tag 0 in a BER encoded value doesn't help you to know if it is for
Foo or Bar. BTW in the RFC 5055 you have for instance PKCReference and
ACReference CHOICEs (section 3.2.1) using different tag ranges for
IMHO this kind of reasons.
Side note: I used IMPLICIT TAGS in this spec only because that is what
is used in the main CMS ANS.1 specification (see RFC 5652). I would be
happy to use another sort of tagging instead-- do you request/recommend
explicit or automatic tagging instead?
=> I expected to get an answer from an ASN.1 expert. If we get
nothing this should be considered as a not justified fear.
Regards
francis.dup...@fdupont.fr
PS: I do the implicit assumption there are ASN.1 experts
(or people knowing ASN.1 experts) in the gen-art list (:-).
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-intarea-shared-addressing-issues-03.txt
Note: the previous version was partially reviewed. I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-intarea-shared-addressing-issues-03.txt Reviewer: Francis Dupont Review Date: 2011-02-16 IETF LC End Date: 2011-02-01 IESG Telechat date: 2011-02-17 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: (PS: this means they can be handled by the RFC Editor) - 5.2.1 page 11: I have a concern about the word 'relay' in 'a UPnP or NAT-PMP relay' as it can be interpreted as a protocol relay when obviously the service is relayed. Perhaps changing 'relay' by 'proxy' is better? - 6 page 13: ICMP is not an application, I suggest 'ICMP echo' or (for me it is the name of the application but I don't know for any OS users) 'ping' - 7 page 14, 13.2 page 18: e.g. -> e.g., - 13.5 page 19: please take the opportunity to introduce the 'IKE' abbrev - 26.[12] page 24: spurious spaces after citations. i.e., '[ref...] ,' -> '[ref...].' (IMHO it is a side effect of the xml style, so something to be fixed by the RFC Editor, i.e., just warn him about this) - in many places the English spelling is used when RFCs use more the American spelling (another item for the RFC Editor). Here is the list from my ispell: Randomisation, Behaviour, organisation, randomisation, realise, customised, centralised, randomisation, Randomisation, randomisation, randomisation, Behaviour, optimisation, optimisation, utilise, utilise - real spelling errors: Feburary, tunnelled (one 'l' please), demuxing, signalling (twice, one 'l' again). Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
