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
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 fdup...@isc.org
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
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
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
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
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
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
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
-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
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
: 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
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
: 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
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
.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
: 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
.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
: 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
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
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
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
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
-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
: 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
: 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
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
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
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
: 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
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
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
-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
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
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
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
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
-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
.
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
-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
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
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
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
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
-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
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
.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
-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
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
-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
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
-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
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
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
-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
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
.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
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
-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
: 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
-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
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
-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
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
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
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
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
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
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
: 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
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
-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
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
-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
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
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
-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
: 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
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
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
-herzog-setkey-03.txt
Reviewer: Francis Dupont
Review Date: 20110203
IETF LC End Date: 20110222
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: I have an ASN.1 question related to implicit tagging:
this can lead to encoding ambiguity with nested CHOICEs for instance
-issues-02.txt
Reviewer: Francis Dupont
Review Date: 2011-02-01
IETF LC End Date: 2011-02-01
IESG Telechat date: unknown
Summary: Not Ready (a new version should be published)
Major issues: None
Minor issues: None but there are some comments from AD review
and many from TSVDIR review so I really
://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-turner-md5-seccon-update-08.txt
Reviewer: Francis Dupont
Review Date: 20110117
IETF LC End Date: 20110106
IESG Telechat date: unknown
Summary: Ready
Major
I maintain the Ready summary for this new version.
Regards
francis.dup...@fdupont.fr
PS: BTW now IESG Telechat date: 20110120
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
: Francis Dupont
Review Date: 20110113
IETF LC End Date: 20110118
IESG Telechat date: unknown
Summary: Ready
Major issues: Almost Ready
Minor issues:
- The signature length in 3.3 is 2N+4 when computation and examples
give 4N+1?
- There is no justification that if s' is too big to fit within
and N
In your previous mail you wrote:
francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] writes:
...
Nits/editorial comments:
Technical:
- 13 page 147: I have a concern about 'TLS or IPsec handshake' because
there is no such thing like 'IPsec
Before sending the review of draft-ietf-tcpm-tcp-timestamps-01.txt
I detected a new version...
francis.dup...@fdupont.fr
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-tcpm-tcp-timestamps-02.txt
Reviewer: Francis Dupont
Review Date: 2010-12-06 / 2010-12-10
IETF LC End Date: 2010-12-07
IESG Telechat date: unknown
Summary: Ready with Nits
Major issues: None
Minor
Reviewer: Francis Dupont
Review Date: 2010-12-06
IETF LC End Date: 2010-12-22
IESG Telechat date: unknown
Summary: Not Ready
Major issues:
- IANA action is to change a field which doesn't exist
- there is no consensus if the document should stress not-security uses
of MD5 are perfectly fine
Oops, a more recent/complete review from Stephane
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
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Document: draft-ietf-avt-rapid-acquisition-for-rtp-16.txt
Reviewer: Francis Dupont
Review Date: 20101103
Summary: Ready
I already reviewed
: Francis Dupont
Review Date: 2010-10-27
IETF LC End Date: 2010-10-25
IESG Telechat date: unknown
Summary: Ready
Regards
francis.dup...@fdupont.fr
PS: I apologize for being late. I'll send a second message with the
comments (editorial at the exception of a concern about 'TLS or IPsec
handshake
: Francis Dupont
Review Date: 2010-10-27
IETF LC End Date: 2010-10-25
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
Technical:
- 13 page 147: I have a concern about 'TLS or IPsec handshake' because
there is no such thing like
-15.txt
Reviewer: Francis Dupont
Review Date: 20100925
IETF LC End Date: 20100928
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
- Abstract page 1: if RTP is a well known abbrev RTCP is not, but
IMHO if someone reaches it (s)he should
Reviewer: Francis Dupont
Review Date: 2010-08-15
IETF LC End Date: 2010-08-12
IESG Telechat date: unknown
Summary: Ready
Major issues: None
Minor issues: None
Nits/editorial comments:
(I add a question mark for questionable suggestions)
- 1 page 3: perhaps (because it is in the 'well known' list
I already reviewed a previous version (-11) with a 'Ready' Summary.
Comments were editorial (usual acknowledg[e]ment spelling, comma
after i.e., etc, and some [a]esthetic remarks about ASCII arts)
and what addressed after the review.
Regards
francis.dup...@fdupont.fr
In your previous mail you wrote:
Examples where this acronym is used are Clause 57 of IEEE
802.3-2008 [IEEE.802.3-2008] and ITU-T Y.1731 [ITU-T Y.1731].
Is that acceptable, or should I drop the text and have it look like this...
Examples where this acronym is used
Reviewer: Francis Dupont
Review Date: 2010-07-22
IETF LC End Date: 2010-07-26
IESG Telechat date: unknown
Summary: Not Ready
This is the full review, I don't repeat the major issue from
the summary.
Major issues: DHC opinion required...
Minor issues: None
Nits/editorial comments:
- ToC page 2
Reviewer: Francis Dupont
Review Date: 2010-07-22
IETF LC End Date: 2010-07-26
IESG Telechat date: unknown
Summary: Not Ready
I am trying to send this before the v6ops meeting this
afternoon, so it is only a summary, a full review will follow ASAP.
Major issues: I have a concern with the way
: Francis Dupont
Review Date: 2010-07-19
IETF LC End Date: 2010-07-23
IESG Telechat date: unknown
Summary: Ready with one nit
Major issues: None
Minor issues: None
Nits/editorial comments:
- you have 6 authors (maximum is 5, I'd like to get the power to make
an exception in this case :-), i.e
I already reviewed draft-ietf-nsis-tunnel-11.txt (the previous version),
status (Ready) is unchanged and the small number of editiorial comments
I had were addressed (at the exception of the IETF spelling of
acknowledgments :-).
Regards
francis.dup...@fdupont.fr
PS: the document is on the
101 - 200 of 314 matches
Mail list logo
