Hi Lucy,
thank you for the review. Please find comments below.
I snipped those typos/grammar issues which I completely agree with.
On 24 Sep 2016, at 00:28, Lucy yong <lucy.y...@huawei.com> wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART)
reviews all IETF documents being processed by the IESG for the IETF Chair.
Please treat these comments just like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-ipsecme-ddos-protection-09
Multi-Path Time Synchronization
Reviewer: Lucy Yong
Review Date: 23-Sept-2016
IETF LC End Date: 28-Sept-2016
IESG Telechat date: 29-Sept-2016
Summary: This document is nearly ready for publication as a standard track RFC. Some minor comments. Some nits need to
be corrected.
PS: comment for IESG. The document specifies puzzles approach and related protocol to boost the difficulty for DDoS
attacks.
The protocol description is simple and short; however it spends many pages
(section 7) to describe the processes
at the Initiator and the Responder. Maybe in future IETF can consider accepting
protocol software code in a RFC.
This will be easier for author and no need for programmers to read the description and program it (sure they will not
come out the same program logic).
Major issues: N/A
Minor issues:
Section 1: 2nd paragraph, bot-nets,
Comment: what is the bot-nets?
We meant botnets. The term is rather new, so I'm not sure which spelling
is more common. If we use "botnets" instead will it be OK?
Section 7.1.1.2, 1st paragraph
Comment: “that must be used”, should it be “that MUST be used” or “that is
used”?
Actually “that MUST be used” is correct. However, section 8.1 contains
description of
PUZZLE notification format and this MUST is more appropriate there.
So, I think it is possible to use “that is used” here and an uppercase MUST
in 8.1 to not duplicate same requirements. Is it OK?
Nits/editorial comments:
Section 6:
s/the puzzle difficulty should/the puzzle difficulty SHOULD/
OK.
Section 7.1
s/the IKE Responder should/the IKE Responder SHOULD/
OK.
Section 7.1.1.1
s/the level should/the level SHOULD/
OK.
Section 7.1.1.2
s/this type must/this type MUST/
I disagree here. It is IKEv2 core specification that imposes
this MUST, we are just use this feature. This lowercase
must means that if the parties follow RFC7296, then
at least one PRF transform will always be in SA payload.
What about the following?
s/this type must always be present/this type is always present/
Section 7.1.1.3
s/should/SHOULD/ (3 places)
OK.
s/blob/block/
OK, but is there any difference?
s/may continue to generate/MAY continually generate/
I partially disagree here. From my understanding "continually"
means constantly. The idea of the sentence is that
the Responder may generate cookie as suggested
in RFC 7296 instead of using method described above.
I don't see how "continually" fits here.
What about the following?
s/may continue to generate/MAY generate/
Section 7.1.4
s/must/MUST/ (2 places)
There are more than 2 lowercase must. I guess you mean:
s/it must be processed according/it MUST be processed according/
s/The Responder must take the smallest number/The Responder MUST take the
smallest number/
If I guessed correctly, then OK.
Section 7.2
s/The Responder should/The Responder SHOULD/
OK.
Section 8.1
s/PRF must/PRF MUST/
OK.
Section 9
s/Initiators should/Initiators SHOULD/
OK.
Section 10
s/Care must/Care MUST/
I'm hesitating. In my opinion uppercase MUST is not applicable here,
because it is an introductory sentence and MUST here is too vague.
There are more detailed RECOMMENDED below.
Regards,
Valery Smyslov.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
