[Gen-art] A *new* batch of IETF LC reviews - 22 April 2010
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-100422-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-opsawg-smi-datatypes-in-xsd-06
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-opsawg-smi-datatypes-in-xsd-06
Reviewer: Vijay K. Gurbani
Review Date: April 23, 2010
IESG Telechat date: Unknown
Summary: This draft is ready for publication as a Proposed Standard.
It has 0 major issues, 0 minor issues and 0 nits.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] gen-art review of draft-moriarty-post-inch-rid-transport-02.txt
I'm just sending this internally. This draft is for "Transport of Real-time Inter-network Defense (RID) Messages", over XML over HTTP/TLS with a new TCP port number. I have two thoughts: (1) "I guess it works", and "Can't we do better than this?" but I don't know much about ops/mgmt so I can't say "this idea is painful to think about, you should do it this other way instead". So, - This draft is ready for publication as an informational RFC. - Maybe one of you can say something more erudite. - Is this typical? It feels so top heavy. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review: draft-ietf-avt-rtp-rfc3984bis-10.txt
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-avt-rtp-rfc3984bis-10.txt
RTP Payload Format for H.264 Video
Reviewer: Joel M. Halpern
Review Date: 23-april-2010
IETF LC End Date: 2010-04-28
IESG Telechat date: N/A
Summary: This document is ready for publication as a Proposed Standard.
Note: While there are some interesting SDP usages, such as having
certain items declare the senders transmitting capability
("sprop-deint-buf-req", "sprop-interleaving-depth",
"sprop-max-don-diff", and "sprop-init-buf-time") instead of the
receivers receive capabilitiy, it seems that this was deliberate,
documented, and deemed acceptable by AVT. As such, I presume it works.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt
Brian, Thank you for your review (attached). This email is a response to the issue that you raised regarding cryptographic algorithms. Please let me know whether there is something I missed, as I want to ensure that we fully address your comment in the next update of the draft. Rather than have one document for the protocol and another for algorithms, we have relied on versioning the protocol. I propose making the following changes to the document: 1. Change Section 1.2 on "Versions" to read: "There is a provision made in the syntax for an explicit version number. Only version "1.0" is currently specified. The purpose for versioning the protocol is to provide a mechanism by which changes to required cryptographic algorithms (e.g., SHA-256) and attributes (e.g., key size) can be deployed without disrupting existing implementations; likewise out-dated implementations can be de-commissioned without disrupting operations involving newer protocol versions." 2. Add the following to the Security Considerations Section 10.6 on "Miscellaneous Considerations" "Many protocols need to be algorithm agile. One reason for this is that in the past many protocols had fixed sized fields for information such as hash outputs, keys, etc. This is not the case for DSKPP, except for the key size in the computation of DSKPP-PRF. Another reason was that protocols did not support algorithm negotiation. This is also not the case for DSKPP, except for the use of SHA-256 in the MAC confirmation message. Updating the key size for DSKPP-PRF or the MAC confirmation message algorithm will require a new version of the protocol, which is supported with the Version attribute." Andrea Doherty P.S. We will also address the Nits that you raised in the next update of the draft. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Wednesday, April 21, 2010 8:57 PM To: draft-ietf-keyprov-dskpp@tools.ietf.org; General Area Review Team Subject: Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt 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-keyprov-dskpp-10.txt Reviewer: Brian Carpenter Review Date: 2010-04-22 IETF LC End Date: 2010-04-26 IESG Telechat date: Summary: Almost ready, one issue about algorithms. Note: This is a long draft and I am not a cryptography or XML expert. I do not claim to have reviewed the draft in detail. Major issue: "3.4.3. The DSKPP Message Hash Algorithm When sending its last message in a protocol run, the DSKPP server generates a MAC that is used by the client for key confirmation. ... d. The resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA]." I am concerned that this is rigidly bound to SHA-256. What happens when SHA-256 goes the way of MD-5? Shouldn't this be a pluggable algorithm? In fact there's another similar issue a few lines earlier: "For the purposes of this document, the secret key k MUST be at least 16 octets long." What would happen if that minimum needs to be raised? Looking at Section 9 (Conformance Requirements), which BTW seems to be extremely useful to implementors, I get the feeling that the point I'm raising is a bit more general. What is the method for adding and deprecating crypto algorithms in DSKPP? If the only method is by bumping up the DSKPP version number, is that going to be a blocking problem in years to come? Maybe Section 1.2 (Versions) should say something about the intent and methodology for versioning the protocol and its range of algorithms. (Full disclosure: I'm exercised about this as an author of draft-iab-extension-recs, in particular because of a pertinent recent comment that it "should specifically note that any protocol using cryptography needs to be designed to be algorithm-independent.") Nit: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If keys generated in DSKPP will be associated with a particular... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt
Andrea, That would help a lot, in my opinion. The one remaining question is whether anything can be said about backwards compatibility. But as we know from (e.g.) SSL/TLS experience, allowing negotiation down to deprecated algorithms can be viewed as a weakness. Maybe there is nothing useful you can say in Version 1 about backwards compatibility for Version 2. Thanks Brian On 2010-04-24 08:48, andrea.dohe...@rsa.com wrote: > Brian, > > Thank you for your review (attached). > > This email is a response to the issue that you raised regarding cryptographic > algorithms. Please let me know whether there is something I missed, as I > want to ensure that we fully address your comment in the next update of the > draft. > > Rather than have one document for the protocol and another for algorithms, we > have relied on versioning the protocol. I propose making the following > changes to the document: > > 1. Change Section 1.2 on "Versions" to read: > > "There is a provision made in the syntax for an explicit version number. > Only version "1.0" is currently specified. > > The purpose for versioning the protocol is to provide a mechanism by which > changes to required cryptographic algorithms (e.g., SHA-256) and attributes > (e.g., key size) can be deployed without disrupting existing implementations; > likewise out-dated implementations can be de-commissioned without disrupting > operations involving newer protocol versions." > > 2. Add the following to the Security Considerations Section 10.6 on > "Miscellaneous Considerations" > > "Many protocols need to be algorithm agile. One reason for this is that in > the past many protocols had fixed sized fields for information such as hash > outputs, keys, etc. This is not the case for DSKPP, except for the key size > in the computation of DSKPP-PRF. Another reason was that protocols did not > support algorithm negotiation. This is also not the case for DSKPP, except > for the use of SHA-256 in the MAC confirmation message. Updating the key > size for DSKPP-PRF or the MAC confirmation message algorithm will require a > new version of the protocol, which is supported with the Version attribute." > > Andrea Doherty > P.S. We will also address the Nits that you raised in the next update of the > draft. > > -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Wednesday, April 21, 2010 8:57 PM > To: draft-ietf-keyprov-dskpp@tools.ietf.org; General Area Review Team > Subject: Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
