Francis,
We've submit draft-08 for response to you and other LC comments.
We think we've already done first case you suggested.
draft-kato-ipsec-camellia-modes-03 was all-in-one document you said. We
got initial review for draft-03 'CTR mode and CCM mode can be used other
protocols without ipsec'. So separated draft-03 to :
(1) a draft that defined both modes, camellia-ctr and camellia-ccm;
(2) a draft that defines how to use camellia-ctr and camellia-ccm in
IPsec.
And we submit two draft to ipsec-ml and cfrg-ml. We did not have strong
objection about this separate.
Regards.
On 2008/05/26 23:59, Francis Dupont 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-kato-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
> are not only in draft-kato-camellia-ctrccm with only the application
> to IPsec in this one? (note: you copied the RFC 3686 so I can understand
> you don't expect my comments :-)
>
> Other comments:
> - title page 1: Its -> Their
> - ToC page 2: Acknowledgements -> Acknowledgments
> - 1 page 3: to -> by (in replacing block)
> - 1 page 3: lisences -> licenses
> - 1 page 3: Openssl -> OpenSSL
> - 1 page 3: Gran Paradiso -> Firefox Gran Paradiso (proposed clarification)
> - 2.3 page 5: i.e. -> i.e.,
> - 2.5 page 5: the padding discussion doesn't apply for the Counter mode.
> I believe the problem is in the wording and is a side-effect of the
> mode + IPsec shaky structure of the document.
> - 3 page 7: there should be nothing about IPsec in this section.
> - 3.1 page 7: there *must* be a MUST about IVs in this section, you can't
> wait for the IPsec use!
> - 3.2 page 7: need not be -> needs not to be (nonce value)
> - 3.2 page 7: that is making use -> using
> - 3.2 pages 7 and 8: remove "academic paper" stuff From "Pipelining is..."
> to "...before the packet arrives."
> - 3.2 page 8: the IKE stuff is not at the right place. BTW how IKE can
> provide the nonce value?
> - 3.2 page 8: the last line (about [12]) just says either 3.2 is not
> normative and should not be there, or there are two competing specs of
> the same thing. Both very bad...
> - 3.3 page 10: same concern about the last sentence.
> - 3 pages 7-10: if there are some limits about the number of blocks
> in a mode, this is the right place.
> - 4.1 page 11: IMHO there should be only one MUST for the IV (and it should
> be "unpredictable" of course).
> - 4.2 page 12: the Authentication Data is not a part of the mode.
> - 4.2.1 page 13: need not be -> needs not to be
> - 4.2.1 page 13 (twice): beginning -> establishment
> - 4.2.2 page 13: this section is not at the right position (move it!)
> - 4.3.4 page 15: same that 4.2.1 (need, beginning (2))
> - 5 page 17: use/using (bad wording)
> - 5 page 17: is camellia usable by IKE itself (if it is not (defined),
> please say it).
> - 5.1 page 17: explain where is the key length
> - 6 page 19: I don't believe it is useful to explain the IV issue,
> a reference should be enough.
> - 8 page 22: Acknowledgements -> Acknowledgments
>
> Regards
>
> [EMAIL PROTECTED]
>
> PS: how to solve my main concern: I believe there are (at least) two
> solutions: either have a mode document and refer to it (with a copy
> of requirements) in an IPsec use separate document; or keep one document
> with both mode and IPsec use specs.
> In the second case, I believe a mode first IPsec details second
> organization for sections 3 and 4 is far better. And don't forget test
> vectors as an all-in-one document should be self contained.
>
--
- KATO Akihiro
+ NTT Software Corporation
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
