Summary: basically ready with nits
I strongly recommend to convert the document to a tool like xml2rfc
before to send it to the RFC editor!
Other concerns:
- the document should specify which kind of namespace registration is
asked for (I've assume formal)
- so there must be an IANA
I am the assigned Gen-ART reviewer for draft-FOOBAR.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: ready
Thanks
[EMAIL PROTECTED]
PS:
I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: Ready with nits
Some
In your previous mail you wrote:
I am the assigned Gen-ART reviewer for draft-ietf-dnsext-mdns-46.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments
I am the assigned Gen-ART reviewer for draft-ietf-rddp-ddp-06.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: not Ready
I have two main
I am the assigned Gen-ART reviewer for draft-ietf-rddp-rdmap-06.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: not Ready
I have the same
I am the assigned Gen-ART reviewer for draft-ietf-sieve-spamtestbis-05.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: Ready
Two
In your previous mail you wrote:
As you suggested, I did contact the IESG, specifically the Security
ADs, about IKEv1 vs. IKEv2, and the verdict is to stick with IKEv1 as
profiled by RFC 3723 for iSCSI so that iSCSI and RDDP use the same
profile of IPsec. If/when RFC 3723 is
For IETF Last Call reviews:
I am the assigned Gen-ART reviewer for draft-ietf-mmusic-fec-grouping-05.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may
I am the assigned Gen-ART reviewer for
draft-ietf-dnsext-dnssec-experiments-03.txt
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Please resolve these comments along with any other
Last Call comments you may receive.
Summary: Ready
Minor
About draft-ietf-tsvwg-quickstart-06.txt, the summary will be:
Not Ready
There is no real problem (yet :-) with the document but my comments won't
be fixed without some editing...
Of course, I'll try to send comments (at least the first comments) ASAP,
and including to the authors.
Regards
Thanks, I'll be happy to read the new version as soon as it'll be
available.
[EMAIL PROTECTED]
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
In your previous mail you wrote:
We have one detail still to address from your review, and that is to
add a citation about deleting IP options being forbidden, or
supposed to be forbidden, for IPv6.
Do you have a citation to suggest for that?
= there is nothing very clear about
-behave-multicast-03.txt
Reviewer: Francis Dupont
Review Date: 3 oct 2006
IETF LC Date: 2 oct 2006
IESG Telechat date: not known yet
Summary: Ready
Comments: I have two very minor suggestions:
- 2.1 page 4: in as if it was a host was - is (or were)?
(I propose to let the RFC editor decide)
- some
In your previous mail you wrote:
I just submitted a revised version of the draft, and put a copy at:
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-07.txt
Let me know what you think. After you are done, then we can
think about who to ask to read it from the ipv6
In your previous mail you wrote:
I have not included anything about deleting IP options being forbidden
in IPv6. It seems sufficient to me just to have the document say that
the router, when it denies a Quick-Start request, SHOULD either delete
the option or zero the relevant fields
-caps-06.txt
Reviewer: Francis Dupont
Review Date: 27 october 2006
IETF LC Date: 19 october 2006
IESG Telechat date: (if known)
Summary: Ready with nits
Comments: there are some little details which should be fixed (nothing
critical and nothing which cannot be fixed by the RFC editor) :
- 1 page
I have some unfilled reports in gen-art-by-reviewer.html:
- draft-ietf-isis-caps-06.txt: done after the last update
(summary: Ready with nits)
- draft-ietf-behave-multicast-03.txt: summary: Ready
- draft-ietf-rddp-rdmap-07.txt: updated after the review,
the main issue, reference to the
-terminology-06.txt
Reviewer: Francis Dupont
Review Date: 2006/12/1
IETF LC End Date:
IESG Telechat date: 2006/11/30
Summary: Ready with nits
Comments: I have many comments about language/wording, some have
a technical impact but none is really critical:
- in 1 page 4, 3.2 page 10, 4 page 11
In your previous mail you wrote:
The definitions reads:
2.8. Correspondent Node (CN)
Any node that is communicating with one or more MNNs. A CN could be
either located within a fixed network or within another mobile network,
and could be either fixed or mobile.
So,
-rfc3095bis-framework-04.txt
Reviewer: Francis Dupont
Review Date: 2006-12-08
IETF LC End Date: 2006-11-28
IESG Telechat date: 2006-12-14
Summary: Ready
Comments: none (it is a rereview of a document which was already ready).
Regards
[EMAIL PROTECTED
-smime-escertid-04.txt
Reviewer: Francis Dupont
Review Date: 2007-01-30
IETF LC End Date: 2007-01-31
IESG Telechat date: 2007-02-02?
Summary: Not Ready
Comments:
- a security consideration section is mandatory.
- the introduction fails to explain how the hash is used even the idea
is very simple
-uri-mib-02.txt
Reviewer: Francis Dupont
Review Date: 2007-02-11
IETF LC End Date: 2007-03-08
IESG Telechat date: (if known)
Summary: Almost Ready
Comments: as already signaled this document has a real issue with its title.
I recommend to take a model, for instance RFC 2851.
Some minor details
-ulp-21.txt
Reviewer: Francis Dupont
Review Date: 2007-03-15
IETF LC End Date: 2007-04-03
IESG Telechat date: unknown
Summary: Ready
Comments: I have only a few minor editorial comments (which should be handled
by the RFC editor):
- 5 page 8 (section title): the usage is to put no space before
: draft-ietf-hip-mm-05.txt
Reviewer: Francis Dupont
Review Date: 03 April 2007
IESG Telechat date: 05 April 2007
Summary: Not Ready
Comments: I'll send full comments in some hours (with a better network
connection) but I have a real issue (so the summary) with the Abstract
which IMHO is not coherent
: draft-ietf-hip-mm-05.txt
Reviewer: Francis Dupont
Review Date: 03 April 2007
IESG Telechat date: 05 April 2007
Summary: Not Ready
Comments:
- as I wrote in the summary message, IMHO the abstract needs a
full rewrite
- in 5.4 page 31, I have a real concern with the new SPI value
SHOULD
In your previous mail you wrote:
I discussed briefly with the authors. Your comment is consistent with
some other recent comments that the draft does not fully specify a
mobility and multihoming solution but only the readdressing mechanisms.
= note that the only issue here is the
: draft-shacham-sipping-session-mobility-03.txt
Reviewer: Francis Dupont
Review Date: 17 April 2007
IESG Telechat date: 10 May 2007?
Summary: Ready
Comments: some details which should be handled by the RFC editor:
- 2 page 4: expand PSTN abbrev at its first use.
- I don't really like the last
-addip-sctp-20.txt
Reviewer: Francis Dupont
Review Date: 2007-05-16
IETF LC End Date: 2007-05-18
IESG Telechat date: unknown
Summary: Almost Ready
Comments: I have only one major comment: the abstract doesn't reach the
requirements for abstracts, in particular it is too short. I have no
strong
: draft-ietf-dhc-dhcpv6-ero-01.txt
Reviewer: Francis Dupont
Review Date: 21 May 2007
IETF LC End Date: 28 May 2007
IESG Telechat date: unknown
Summary: Ready
Comments: only editorial (i.e., to be handled by the RFC editor) comments:
- 4 page 4 last sentence: either the wording is poor
-fmipv4-07.txt
Reviewer: Francis Dupont
Review Date: 2007/06/01
IETF LC End Date: 2007/06/01
Summary: Ready
Comments: some editorial (i.e., to be handled by the RFC editor) comments:
at page 6 section 4.2:
- in FA COA mode - in FA-COA mode
- for the FSU field, I propose to add a MUST somewhere
-rfc3682bis-09.txt
Reviewer: Francis Dupont
Review Date: 2007/06/10
IETF LC End Date: 2007/06/15
IESG Telechat date: not known
Summary: Almost Ready
Comments: I have only one major comment: the document does not explain
it is a revision of RFC 3682, I propose to add a sentence at the
beginning
In your previous mail you wrote:
= I reply here because there is a common misconception in this comment.
I have been selected as the General Area Review Team (Gen-ART)
An important requirement for IPsec-based protection of Mobile IPv6 route
optimization is that the IPsec security
In your previous mail you wrote:
= in fact the home address impersonation attack exists only in the mobile
node - home agent case, not in the mobile node - correspondent case. If a
node can use the address of another node to communicate with the
correspondent, establish some
In your previous mail you wrote:
an attacker can not do significantly more damage with a fake home address
than with just a fake address.
With IPsec alone, an attacker wouldn't be reachable if it used a fake IP
address. This is different when you add Mobile IPv6 because the
In your previous mail you wrote:
unless you bind the IPsec security association to the home address, an
attacker could send a Binding Update message with a spoofed home address
using its own IPsec SA. The correspondent node's IPsec instance would
accept that message and hand it
-sipping-session-mobility-04.txt
Reviewer: Francis Dupont
Review Date: 2007-09-20
IETF LC End Date: done
IESG Telechat date: on next agenda
Summary: Ready
Comments: I have a few editorial comments:
- ToC page 2 and 11 page 32: s/Acknowledgements/Acknowledgments/
- 1 page 4: s/teh/the/
- 3 page 5
-bb-fec-rs-03.txt
Reviewer: Francis Dupont
Review Date: 2007-09-26
IETF LC End Date: 2007-10-04
IESG Telechat date: unknown
Summary: Ready
Comments: I have only editorial (i.e., for the RFC editor) comments:
- abstract page 2: s/FEC/Forward Error Correction (FEC)/
(IMHO it is needed even
-nfsv4-nfsdirect-06.txt
Reviewer: Francis Dupont
Review Date: 2007-10-10
IETF LC End Date: 2007-10-12
IESG Telechat date: unknown
Summary: Almost ready
Comments: I maintain my concern about the abbrevs in the Abstract even
I recognize it is more from the way the nfsv4 stuff is cut out in several
-simple-partial-publish-06.txt
Reviewer: Francis Dupont
Review Date: 2007-10-16
IETF LC End Date: none
IESG Telechat date: unknown
Summary: Ready
Comments: only minor editorial stuff which should be handled by the RFC
editor (i.e., please don't rush to your keyboard :-):
- Abstract page 2: to constitue
-pwe3-pw-tc-mib-12.txt
Reviewer: Francis Dupont
Review Date: 2007-11-06
IETF LC Date: 2007-11-09
IESG Telechat date: unknown
Summary: Ready
Comments: I have to run MIB doctor co on the document but IMHO there
are only minor editorial concerns (i.e., things which should be handled
by the RFC editor
In your previous mail you wrote:
Comments: the comments are editorial, i.e., they enter in the kind of
things which can be handled by the RFC Editor:
- 2 page 3: according to the Introduction the REFER-recipient should
be a server, not a user agent, i.e., either I've
-ipdvb-ule-ext-06.txt
Reviewer: Francis Dupont
Review Date: 2007-12-13
IETF LC End Date: 2007-12-17
IESG Telechat date: unknown
Summary: Almost Ready
Comments: I have many editorial comments so even they can be handled by
the RFC Editor IMHO you could publish a new version of the document.
In details
-ccamp-mpls-gmpls-interwork-reqts-03.txt
Reviewer: Francis Dupont
Review Date: 2007-12-21
IETF LC End Date:
IESG Telechat date: unknown
Summary: Ready
Comments: some editorial comments to leasve to the RFC Editor:
- Abstract page 1: A MPLS-TE - An MPLS-TE
- 1 page 3: the top of the page 3 has
-rfc2716bis-12.txt
Reviewer: Francis Dupont
Review Date: 2008-01-09
IETF LC Date: 2007-12-27
IESG Telechat date: 2008-01-10
Summary: Ready
Comments: I have some editorial comments (editorial means they should be
handled by the RFC Editor):
- 2.1 page 4: s/backend security server/backend
-imap-annotatemore-12.txt
Reviewer: Francis Dupont
Review Date: 2008-01-14
IETF LC End Date: 2008-01-30
IESG Telechat date: unknown
Summary: Ready
Comments: Some editorial (i.e., to be handled by the RFC Editor) comments:
- Abstract page 1: add (IMAP) after Internet Message Access Protocol
- 3.3
-hiopt-10.txt
Reviewer: Francis Dupont
Review Date: 2008-01-30
IETF LC End Date: 2008-02-04
IESG Telechat date: unknown
Summary: Not ready
Comments: I have three series of comments: editorial (which should be
handled by the RFC editor but you may fix them if (and only if) you
publish a new version
The preceeding version, draft-ietf-ipdvb-ule-ext-06.txt, was reviewed
last year with the Almost Ready summary because of the large number
of editorial comments. As the remaining/missed editorial issues should
be handled by the RFC Editor, IMHO the document is now Ready.
Thanks
[EMAIL PROTECTED]
-sipping-served-user-04.txt
Reviewer: Francis Dupont
Review Date: 2008-02-12
IETF LC End Date: 2008-02-04
IESG Telechat date: unknown
Summary: Almost Ready
Comments: I have many editorial comments so it is perhaps a good idea
to publish a new version and not to rely on the RFC Editor:
- TOC page
-nfsv4-nfsdirect-07.txt
Reviewer: Francis Dupont
Review Date: 2008-03-21
IETF LC End Date: 2008-03-26
IESG Telechat date: unknown
Summary: Ready
Comments: some editorial comments (editorial == to be handled by the
RFC Editor by default) and 3 questions (with positive answers):
- first question
In your previous mail you wrote:
At 11:57 AM 3/21/2008, Francis Dupont wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft
...
Editorial:
- 3 page 3, etc: about the case of read/write: operations should get
all uppercase, list
-atompub-bidi-06.txt
Reviewer: Francis Dupont
Review Date: 2008-04-22
IETF LC End Date: 2008-05-09
IESG Telechat date: unknown
Summary: Ready
Comments: one comment and two questions, all are editorial so have to
be handled by the RFC Editor:
- in ToC (page 2) and Appendix (page 6): Acknowledgements
In your previous mail you wrote:
Francis:
-08 is on the Telechat for this week. Please check if your concerns
were resolved.
= they were (BTW they were editorial) so I keep the Ready summary.
Thanks
[EMAIL PROTECTED]
PS: I copy my answer to the gen-art list for the
In your previous mail you wrote:
Francis:
Does -05 resolve your concerns?
Russ
= yes, they are editorial comments... I change the summary to Ready.
Thansk
[EMAIL PROTECTED]
At 06:59 PM 2/12/2008, Francis Dupont wrote:
Document: draft-vanelburg-sipping-served
-lasthop-threats-04.txt
Reviewer: Francis Dupont
Review Date: 2008-05-19
IETF LC End Date: 2008-05-23
IESG Telechat date: unknown
Summary: Ready
Comments: mainly editorial comments, i.e., should be handled by the RFC Editor:
- ToC and section 5 page 11: Acknowledgements - Acknowledgments
-ipsec-camellia-modes-07.txt
Reviewer: Francis Dupont
Review Date: 2008-05-23
IETF LC End Date: 2008-06-10
IESG Telechat date: unknown
Summary: Not ready
Comments: my main concern is about the organization of the different
camellia mode/ipsec documents, for instance why the CTR and CCM modes
: draft-ietf-bfd-multihop-06.txt
Reviewer: Francis Dupont
Review Date: 2008-06-03
IESG Telechat date: 05 June 2008
Summary: Almost ready
Comments: my concerns are editorial but as one is about the structure of
the document I can't assume you can leave them to the RFC Editor:
- 3.2 page 3
-pw-atm-mib-05.txt
Reviewer: Francis Dupont
Review Date: 2008-06-24
IETF LC End Date: 2008-06-24
IESG Telechat date: unknown
Summary: Not Ready
Comments: I have (too) many editorial concerns. Even the MIB part is
to be processed by machines (vs. humans) it should be written with a
minimal care
-rfc2763bis-00.txt
Reviewer: Francis Dupont
Review Date: 2008-06-25
IETF LC End Date: 2008-06-23
IESG Telechat date: unknown
Summary: Almost Ready
Comments: I have some editorial concerns:
- first, as it is an update it should be fine to provided a temporary
(i.e., marked as to be removed before
-capwap-dhc-ac-option-01.txt
Reviewer: Francis Dupont
Review Date: 2008-07-10
IETF LC End Date: 2008-07-14
IESG Telechat date: unknown
Summary: Ready with nits
Comments: I have two general questions and the usual editioral things
(here editorial means they can be handled by the RFC Editor
In your previous mail you wrote:
- in TOC and section 6: Acknowledgements - Acknowledgments
PRC I think perhaps your version is the queen's english, while mine is
the one accepted in the US :(
= there is no (not yet?) gen-art review FAQ but if the two spelling
exist the RFC Editor
-interas-pcecp-reqs-06.txt
Reviewer: Francis Dupont
Review Date: 2008-07-24
IETF LC End Date: 2008-07-31
IESG Telechat date: unknown
Summary: Ready
Comments: some edtorial problems and suggestions (editorial means they
can be handled my the RFC Editor):
- 1 page 2: the LSP abbrev should
-pw-tc-mib-14.txt
Reviewer: Francis Dupont
Review Date: 2008-08-19
IETF LC End Date: 2008-08-14
IESG Telechat date: 2008-08-14
Summary: Almost Ready
Comments: I apologize for this late review (I lost the disk of my laptop).
I share the concern about the naming of some textual conventions:
- extra
-diameter-api-07.txt
Reviewer: Francis Dupont
Review Date: 2008-08-20
IETF LC End Date: 2008-08-08
IESG Telechat date: unknown
Summary: Not Ready
Comments: my main concern is the API as it is described up to section 3.7
is clearly impossible to implement so I strongly suggest to add soon
I reviewed for the gen-art the version 05 of this document.
My main concern, the missing ASN.1 summary, was addressed and no more
stands for an informational document (but please keep it :-).
Almost all other comments were editorial, BTW the last one (add USA
in Author's Addresses page 34) still
-ldp-igp-sync-03.txt
Reviewer: Francis Dupont
Review Date: 2008-11-12
IETF LC End Date: 2008-11-18
IESG Telechat date: unknown
Summary: Almost Ready
Comments: I have many editorial concerns:
- Abstract page 1: use of abbrevs (LSP, LDP, VPN, IGP). IMHO only IP
and MPLS are supposed to be known
In your previous mail you wrote:
I checked with some people on renaming the receipentKeyId field to
recipientKeyid, and it's a no go. That name is used by compilers to name C
code and changing it is going to cause problems. It's also been mispelled
since about 1999 and nobody has
-admitted-realtime-dscp-05.txt
Reviewer: Francis Dupont
Review Date: 2008-11-19
IETF LC End Date: 2008-11-27
IESG Telechat date: unknown
Summary: Ready
Comments: I have minor editorial (== to be handled by default by the RFC
Editor) concerns and proposals (ending by '?'):
- ToC page 2
: draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
Reviewer: Francis Dupont
Review Date: 2008-12-03
IETF LC End Date: 2008-12-09
IESG Telechat date: 1008-12-18
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- the Abstract mentions RFC 3279 when the body of the document uses
I have no reason to change my review (of the -15 version) summary
from Ready to something else. BTW I maintain my *minor* editorial concerns
in 4.1 page 7 (spurious minimum words) and 4.2.2 page 10 (e.g. without
the mandatory ',').
Regards
[EMAIL PROTECTED]
In your previous mail you wrote:
the document is very unpleasant to read
That would have to be regarded as a comment which is not actionable ;-)
= if you find a magical way to improve the wording it should be very great
(as a not native English writer I understand the issue but
-andreasen-sipping-rfc3603bis-07.txt
Reviewer: Francis Dupont
Review Date: 2008-12-24
IETF LC End Date: 2009-01-10
IESG Telechat date: unknown
Summary: Ready
Comments: some minor editorial concerns (i.e, to be fixed bt the RFC Editor):
- Abstract page 2: please remove (SIP) [RFC3261] (the Abstract
-ccamp-gr-description-03.txt
Reviewer: Francis Dupont
Review Date: 2009-01-15
IETF LC End Date: 2009-01-20
IESG Telechat date: unknown
Summary: Ready
Major issues: none
Minor issues: there are 4 authors in 11 (Authors' Addresses) but 3 only
in front (first page). I am afraid Snigdho Bardalai
-ccamp-path-key-ero-03.txt
Reviewer: Francis Dupont
Review Date: 2009-01-27
IETF LC End Date: 2009-02-03
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: IMHO it is just a typo but in 4 page 9: DNS - DoS
Nits/editorial comments:
- 7.1 page 12: Singlaling - Siglaling
-mmusic-sdp-source-attributes-02.txt
Reviewer: Francis Dupont
Review Date: 2009-02-05
IETF LC End Date: 2009-02-09
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- Abstract page 1: The Session Description Protocol - ... (SDP)
- 3 page
All (minor/editorial) comments about the previous version were solved.
I maintain the Ready summary.
Regards
francis.dup...@fdupont.fr
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
-rfc3330bis-06.txt
Reviewer: Francis Dupont
Review Date: 2009-04-03
IETF LC End Date: 2009-04-18
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
I have two concerns about the Abstract:
- the first sentence This document obsoletes RFC
I reviewed the version 03, I keep the Ready summary.
Regards
francis.dup...@fdupont.fr
PS: the spelling error in 7.1 page 12 only changed, correct spelling
(checked twice as it seems really hard to type :-) is: signaling
(leave it to the RFC Editor...)
-mpls-p2mp-te-mib-08.txt
Reviewer: Francis Dupont
Review Date: 2009-04-16
IETF LC End Date: 2009-04-17
IESG Telechat date: unknown
Summary: Ready
Regards
francis.dup...@fdupont.fr
PS: I'll send full comments tomorrow morning.
___
Gen-art mailing list
-mpls-p2mp-te-mib-08.txt
Reviewer: Francis Dupont
Review Date: 2009-04-16
IETF LC End Date: 2009-04-17
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- Abstract: add '(MIB)' as it is done in the introduction
- Abstract: if you need
-pce-monitoring-04.txt
Reviewer: Francis Dupont
Review Date: 2009-04-22
IETF LC End Date: 2009-04-27
IESG Telechat date: unknown
Summary: Not Ready
Major issues: none but some minor issues which should need another cycle.
Minor issues:
- 1 page 5: as the PCReq/PCReq seem to come from nowhere
-sipping-update-pai-09.txt
Reviewer: Francis Dupont
Review Date: 2009-05-06
IETF LC End Date: 2009-05-11
IESG Telechat date: unknown
Summary: Ready
Major issues: none
Minor issues:
IMHO the Abstract should be reworded a bit before publication
(RFC Editor could handle this)
Nits/editorial comments
-sipping-update-pai-09.txt
Reviewer: Francis Dupont
Review Date: 2009-05-06
IETF LC End Date: 2009-05-11
IESG Telechat date: unknown
Summary: Ready
Major issues: none
Minor issues:
IMHO the Abstract should be reworded a bit before publication
(RFC Editor could handle this)
Nits/editorial comments
: draft-ietf-isms-secshell-16.txt
Reviewer: Francis Dupont
Review Date: 2009-05-07
IESG Telechat date: 07 May 2009
Summary: none as draft-ietf-isms-secshell-17.txt was published before
I finished the review... Comments are about the not-MIB part (i.e.,
not the section 7) and of course about
-sip-eku-05.txt
Reviewer: Francis Dupont
Review Date: 2009-06-02
IETF LC End Date: 2009-06-05
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
(I apologize to have been late to send this review)
- 1.2 page 3: X.680 [5],X.690 [6]. - X.680
-sipping-cc-framework-11.txt
Reviewer: Francis Dupont
Review Date: 2009-06-09
IETF LC End Date: 2009-06-09
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- in Abstract page 2: SIP - Session Initiation Protocol (SIP)
- ToC page 3: Far
In your previous mail you wrote:
- 3 page 4:
the application need not recognize - needs???
(BTW the spelling error, if it is an error, is in RFC 5280)
I believe that in this context, need is grammatically
correct -- needs not recognize... does not seem to read very
-rfc3330bis-07.txt
Reviewer: Francis Dupont
Review Date: 2009-07-06
IETF LC End Date: 2009-07-22
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
I have still (cf review of the 06 version) two concerns about the Abstract:
- the first
-simple-xcap-diff-13.txt
Reviewer: Francis Dupont
Review Date: 2009-07-15
IETF LC End Date: 3009-07-22
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- 3 page 6: i.e. - i.e.,
- 3 pages 7 and 8: endoced - encoded
- 4 pages 8-10: I am
-hokey-key-mgm-08.txt
Reviewer: Francis Dupont
Review Date: 2009-07-30
IETF LC End Date: 2009-08-03
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues:
I understand this specification is very abstract about on wire entities
(for instance there is nothing about encoding
In your previous mail you wrote:
Minor issues:
- IMHO a transition paragraph is needed at the end of the Introduction
in order to introduce technical dependencies:
* clearance attribute is in fact from 3281bis (this is obvious when
one reads the ASN.1 module appendix
comments
you may receive.
Document: draft-ietf-mpls-gmpls-lsp-reroute-04.txt
Reviewer: Francis Dupont
Review Date: 2009-08-31
IETF LC End Date: 2009-08-31
IESG Telechat date: unknown
Summary: Ready
Major issues: none
Minor issues: none
Nits/editorial comments:
- ToC page 2 and 8 page 12: Author's
In your previous mail you wrote:
= oops, catching an old message.
- 2.2 page 6 and 2.3 page 6: conformant - compliant
Why?
= just because conformant is not in my dictionary, compliant is
and is supposed to mean the same thing... Now my dictionary is
not universal and is
-roll-building-routing-reqs-07.txt
Reviewer: Francis Dupont
Review Date: 2009-09-29
IETF LC End Date: 2009-09-24
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues:
- IMHO the document is a bit USA centric (but it is not a problem
if it is stated in the document
-mmusic-connectivity-precon-06.txt
Reviewer: Francis Dupont
Review Date: 2009-10-12
IETF LC End Date: 2009-10-14
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- 3.1 page 4: the precondition types don't include sec which is
mentioned
-6man-overlap-fragment-03.txt
Reviewer: Francis Dupont
Review Date: 2009-10-29
IETF LC End Date: 2009-11-02
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Personal comment as a IPv6 implementor: overlapping fragments have no
utility in IPv6 so I never added code
-pkix-authorityclearanceconstraints-03.txt
Reviewer: Francis Dupont
Review Date: 2009-08-10/2009-11-30
IETF LC End Date: 2009-08-14
IESG Telechat date: unknown
Summary: Almost Ready
Comments: the previous major issue was the I-D is too hard to read.
All minor issues and NITs were addressed but I
-lsp-dppm-10.txt
Reviewer: Francis Dupont
Review Date: 2009-11-28
IETF LC End Date: 2009-11-23
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: too many authors in Authors' Addresses (see below)
Nits/editorial comments:
- the document is heavily cut paste between
In your previous mail you wrote:
Now I see what gave you a pain... A series of unfamiliar abbreviations
may hamper readability. Please take a look at the following style. The
key words below are spelled out:
= BTW I am familiar with most of these abbrevs (I worked a lot in Mobile
-versioning-link-relations-05.txt
Reviewer: Francis Dupont
Review Date: 2009-12-23
IETF LC End Date: 2010-01-11
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- A.1 page 10: I don't know if it is by design or an unexpected side
effect
1 - 100 of 314 matches
Mail list logo
