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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
