Hi Miguel,
Thank you for your careful review. We'll address comment 1) by adding
a paragraph containing guidance, as you suggest. Both comments will
be addressed in the next draft.
Brian
On Nov 22, 2007, at 4:12 AM, Miguel Garcia wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-msec-ipsec-extensions-06.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
Review Date: 2007-11-22
IETF LC End Date: 2007-11-23
Summary: The document s ready fr publication is a standards track RFC
Comments: The document is very well written. I have a comment and a
nit. Treat them at your own discretion.
1) Section 4.2.1 the leading edge IPsec SA. There is a paragraph
that describes how to send the RKE multicast with new keying
material. The text says:
- After waiting a sufficiently long enough period such that all of
the Group Members have processed the RKE multicast, the Group
Sender begins to transmit using the leading edge IPsec SA with
its data encrypted by the new keying material. Only authorized
Group Members can decrypt these IPsec SA multicast transmissions.
The time delay that a Group Sender waits before starting its
first leading edge SA transmission is a GKM/IPsec policy
parameter. This value SHOULD be configurable at the Group Owner
management interface on a per group basis.
The comment is: I think the draft should provide guidelines with
respect the duration of "long enough period" that it refers. Are we
speaking about seconds, minutes, hours, or days? What are the input
variables that this value depends on? Does the value depend on the
number of group members, the distance among them, or something
else? I can see what are the implications of selecting a short
value for this period of time, but I don't know what are the
implications for selecting a very high value. I think this is
important to provide these guidelines, otherwise, if the value is
short and a host has not received the new keying material when the
first packet arrives, it will be hard, if not impossible to trace
the error.
The recommendation is to add some discussion that can help people
to select either the default or actual values. The discussion
should answer the questions I indicated above.
2) According to the RFC Editor, an abstract should not contain
citations:
Source: http://www.rfc-editor.org/policy.html#policy.abstract
"An Abstract should be complete in itself; it should not contain
citations unless they are completely defined within the Abstract. "
This applies to the occurrence of "[RFC4301]" in the abstract.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
--
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [EMAIL PROTECTED]
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
