[Gen-art] Gen-ART review of draft-ietf-krb-wg-cross-problem-statement-04.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-krb-wg-cross-problem-statement-04.txt Reviewer: Brian Carpenter Review Date: 2008-08-04 IETF LC End Date: 2009-08-11 IESG Telechat date: 2009-10-08 Summary: This draft is on the right track, but has open issues, described in the review. Note - no response from authors to Gen-ART LC review of this version. Also one of the authors' addresses fails: 550 550 #5.1.0 Address rejected zre...@jaist.ac.jp (state 14). Major issues: - 1) About 5.5. Client's performance > It > takes 195 milliseconds to perform a TGS exchange with the on-board > H/W crypto engine. Indeed, this result seems reasonable to the > requirement of the response time for the control network. ... > Also, the delays > can grow to unacceptable delays when the number of intermediary > realms increases. This analysis seems incomplete. How do we know that 195 ms is OK and that an unspecified time using intermediary KDCs is too big? There are certainly some SCADA environments where 195 ms is like infinity, and others where 20 seconds would be just fine. In fact, shouldn't timing constraints be defined in Section 4 as external requirements? The existing requirements R-6 (device performance) and R-7 (link capacity) are rather imprecise, and do not mention network latency. 2) About 5.6. Pre-authentication problem in roaming scenarios There seems to be a rather strange assumption here which is not discussed: that different realms of a SCADA system will be interconnected by the public Internet. Well, when I was working on control systems, I would never have dreamt of such a thing! Surely interconnections between sites and contractors, whether roaming or fixed, must be based 100% on a VPN approach, where the access control could be tuned perfectly to avoid a pre-authentication problem. Typically I'd expect a truly roaming user to connect into the VPN and her home realm using an IPSec tunnel, and then have exactly the same trust model as any fixed host in the same realm. In any case, use of the public network with arbitrary authentication seems to be a false assumption. In fact, in one of the Shell examples, you say: > They are connected each other by a private ATM WAN. so any roaming user would have to VPN herself right into that WAN. Minor issues: - This is basically a grammatical problem but the authors need to confirm what the sentence means before it can be edited (last paragraph of section 2.2): > However, because the inter-realm trust model > is not necessarily constructing the hierarchic approach anytime, the > trust path must be specified manually. Does this mean ", because the inter-realm trust model may or may not follow the hierarchical model,"? If not, what does it mean? Editorial issues: - Just to note that the RFC Editor will have to make many grammatical corrections to this draft.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mboned-lightweight-igmpv3-mldv2-05.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mboned-lightweight-igmpv3-mldv2-05.txt Reviewer: Brian Carpenter Review Date: 2008-09-01 IETF LC End Date: 2009-09-04 IESG Telechat date: 2009-10-08 Summary: Almost ready Minor issues: - (I don't consider this a blocking comment, but I don't seem to have seen any response from the authors after Last Call review.) > 1. Introduction ... > Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full > version of these protocols (i.e., the standard IGMPv3 and MLDv2), > hosts or routers that have implemented the full version do not need > to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 > hosts or routers. I assume this also means that LW-IGMPv3 and LW-MLDv2 are strict subsets of IGMPv3 and MLDv2. If so, it would be useful to say so explicitly. Editorial issues: - No IANA Considerations section. IDnits says: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? There is a trivial cut-and-paste error, I think. ** Obsolete normative reference: RFC 2236 (ref. '5') (Obsoleted by RFC 3376) Intentional? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-tcpm-tcpsecure-12.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-tcpsecure-12.txt Reviewer: Brian Carpenter Review Date: 2009-10-03 IETF LC End Date: 2009-04-16 IESG Telechat date: 2009-10-08 Summary: Ready Comments: - My editorial comments have been fixed, thanks.___ 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-sasl-scram-07
On Fri, Oct 02, 2009 at 01:17:26PM -0500, Nicolas Williams wrote: > On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: > > On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell wrote: > > > I'm no crypto expert, so please forgive me if this is silly--but isn't > > > there > > > a movement to phase out sha-1? If so, should that be the default "must > > > implement" hash for a new mechanism? > > > > My understanding is that use of SHA-1 under HMAC is still considered > > reasonable. > > The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided > > to proceed with SHA-1, because it is more frequently implemented in > > libraries > > and hardware. > > This matter has come up elsewhere, such as in the KRB-WG. NIST has not > obsoleted the use of HMAC-SHA-1, though I don't have a reference handy > at the moment (but a quick search of the KRB-WG mailing list and, maybe, > the krb...@mit.edu list should yield one). http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html "After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols." Nico -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)
On Oct 2, 2009, at 3:25 PM, Ahmad Muhanna wrote: Thank you Ben for reviewing and taking the time to go through the document once more! Agreed; Sorry, I missed that one. I will make sure it is included in the next revision. I am sure you are okay not to spin another revision unless this is the only outstanding comment. Yes, no problem. That one could be done as an editor note (or not at all, really--it's pretty minor.) Thanks again! Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Friday, October 02, 2009 2:47 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; kchowdh...@starentnetworks.com; pyeg...@juniper.net; General Area Review Team; IETF-Discussion list; Jari Arkko; marc...@it.uc3m.es; Julien Laganier Subject: Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10) Hi, This is a followup of my Gen-ART review of draft-ietf-mext-binding- revocation, updated based on revision 13 of that draft. This revision addresses all of my substantive issues, and most of the editorial issues. I had one outstanding minor editorial comment where the author proposed a specific change, but that change did not make it into revision 13 as far as I can tell: -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. Revision 13 still appears to have the old text. Thanks! Ben. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)
Thank you Ben for reviewing and taking the time to go through the document once more! Agreed; Sorry, I missed that one. I will make sure it is included in the next revision. I am sure you are okay not to spin another revision unless this is the only outstanding comment. Thanks again! Regards, Ahmad > -Original Message- > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: Friday, October 02, 2009 2:47 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; > kchowdh...@starentnetworks.com; pyeg...@juniper.net; General > Area Review Team; IETF-Discussion list; Jari Arkko; > marc...@it.uc3m.es; Julien Laganier > Subject: Followup on Gen-ART review of > draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and > Telechat Review of draft-ietf-mext-binding-revocation-10) > > Hi, > > This is a followup of my Gen-ART review of > draft-ietf-mext-binding- revocation, updated based on > revision 13 of that draft. > > This revision addresses all of my substantive issues, and > most of the editorial issues. I had one outstanding minor > editorial comment where the author proposed a specific > change, but that change did not make it into revision 13 as > far as I can tell: > > >> > >> -- Section 11, (InitMINDelayBRIs) (I think I commented on > this, but > >> can't find the resolution) > >> > >> Did you intend for the _default_ to be a range (between .5 and 1 > >> sec), or did you mean to say the default was 1 second, and it must > >> not be configured to less than .5 seconds? I suspect the > latter, but > >> it's not clear from the text. > > > > [Ahmad] > > Sure, will fix this as follows: > > > > Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) > > > > This variable specifies the initial delay timeout in seconds > > before the revoking mobility entity retransmits a BRI message. > > The default is 1 second but not to be configured less than 0.5 > > seconds. > > Revision 13 still appears to have the old text. > > > Thanks! > > Ben. > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)
Hi, This is a followup of my Gen-ART review of draft-ietf-mext-binding- revocation, updated based on revision 13 of that draft. This revision addresses all of my substantive issues, and most of the editorial issues. I had one outstanding minor editorial comment where the author proposed a specific change, but that change did not make it into revision 13 as far as I can tell: -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. Revision 13 still appears to have the old text. Thanks! Ben. ___ 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-sasl-scram-07
On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote: > -- 2nd paragraph: " ...increase the iteration count over time." > > Can you elaborate on how this helps, and possibly offer guidance on > how implementations should use it? Good point. With SCRAM as specified, a server cannot increase the iteration count without somehow getting access to the cleartext password. If the server were to store SaltedPassword _and_ U_iteration_count (from Hi()'s internals), then the server could compute a new SaltedPassword and U_iteration_count with a higher iteration count. However, the server isn't intended to store SaltedPassword, rather, the server stores StoredKey and ServerKey, and there's a reason for this: a server that's never authenticated a given user before cannot impersonate that user, but if the server were to store SaltedPassword, then the server could impersonate the user. Thus, to "increase the iteration count over time" requires, effectively, changing the user's password. This is probably worth pointing out. Nico -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] RE review of draft-ietf-roll-building-routing-reqs-07.txt
Hi Nicolas, I believe this comment has already been mitigated. Peter was nice enough to review the draft quickly and noted HVAC, K-12 and Elevator as US centric terminology. Adrian discussed this and I believe resolved the comment. I have received some other comments in other areas of the draft that I will be working on with the commenters shortly. If Francis has any other areas of concern, let me know and I will add them into the comment resolutions. Thanks for the help. Ciao, Jerry nicolas.r...@fr.schneider-electric.com 10/02/2009 12:13 PM To Francis Dupont cc adrian.far...@huawei.com, francis.dup...@fdupont.fr, gen-art@ietf.org, jerald.p.marto...@jci.com, pieter.de...@intec.ugent.be, wou...@vooruit.be Subject RE review of draft-ietf-roll-building-routing-reqs-07.txt Hi Francis, Can you precise a little bit more why you think draft 07 is USA centric? Mainly because of section 8.2 and section 9.1.2? other sections? Regarding section 8.2, I don't fully understand your expectation... Do you expect a few words on LON / Echelon, ASHRAE... for instance? Have a nice week-end & Best regards, Nicolas Francis Dupont Envoyé par : francis.dup...@fdupont.fr 02/10/2009 10:45 A gen-art@ietf.org cc jerald.p.marto...@jci.com, Nicolas Riou/FR/schnei...@europe, pieter.de...@intec.ugent.be, wou...@vooruit.be, adrian.far...@huawei.com Objet review of draft-ietf-roll-building-routing-reqs-07.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-roll-building-routing-reqs-07.txt Reviewer: Francis Dupont Review Date: 2009-09-29 IETF LC End Date: 2009-09-24 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - IMHO the document is a bit USA centric (but it is not a problem if it is stated in the document, for instance with a reference from the (US) building automation community, cf 8.2 comment below) Nits/editorial comments: - the language of the document is not at the usual level (but at it should be considered as better it is not a concern) - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14. 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20: e.g. -> e.g., - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e., add "(MS)" after "facility management system" - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous: it can stand for point and the point-to-point term usually refers to link topology. I propose: P2P -> (peer-to-peer, P2P) (MP2P) -> (multi-peers-to-peer, MP2P) (P2MP) -> (peer-to-multi-peers, P2MP) - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment (for uniformity with the section title where this spelling is enforced) (multiple occurrences) - 5.1 page 11: no network knowledge -> no communication network knowledge - 5.2.2 page 13: even it is also overloaded: point-to-point -> end-to-end - 5.4 page 14: i.e. -> i.e., - 5.4.3 page 14: 2000mah -> 2000mAh - 5.7.6 page 17: msec -> ms - 7 page 19: J. P. -> JP. - 8.2 page 19: I'd really like to get a reference from the building automation community: explaining networking to them or an introduction for us (networking community) or both. I expect there are at least some framework standards. - 9.1.2 page 19: 2.4Ghz -> 2.4GHz (BTW the ISM band text is very USA centric :-) - 9.3.1 page 20: missing final '.' - Authors' Addresses page 22: unfinished (???), add +1 for USA phone number, -- -> - (and BTW try to use the same separator) Regards francis.dup...@fdupont.fr __ This email has been scanned by the MessageLabs Email Security System. __ <>___ 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-sasl-scram-07
On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: > On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell wrote: > > I'm no crypto expert, so please forgive me if this is silly--but isn't there > > a movement to phase out sha-1? If so, should that be the default "must > > implement" hash for a new mechanism? > > My understanding is that use of SHA-1 under HMAC is still considered > reasonable. > The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided > to proceed with SHA-1, because it is more frequently implemented in libraries > and hardware. This matter has come up elsewhere, such as in the KRB-WG. NIST has not obsoleted the use of HMAC-SHA-1, though I don't have a reference handy at the moment (but a quick search of the KRB-WG mailing list and, maybe, the krb...@mit.edu list should yield one). > > -- 1.2, last bullet: > > > > What is the referent for "this"? Is there perhaps a missing word(s), or > > maybe this paragraph belongs with the previous bullet? > > The latter. (This == Hi()) Incidentally, Hi() should be shown as taking the iteration count as an argument. Nico -- ___ 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-sasl-scram-07
Hi Alexey, Your responses in this and your other email address all of my comments. Thanks! Ben. On Oct 2, 2009, at 12:31 PM, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell wrote: [...] Minor issues: [...] -- section 4, first paragraph: "...as long as this alternative name doesn’t conflict with any other hash function name from the IANA "Hash Function Textual Names" registry." What prevents future conflicts if someone registers a name that conflicts with the short name? Good point. Should the short-names be IANA registered to prevent this? This is a good idea. I've added: Such alternative name SHOULD be registered in the IANA "Hash Function Textual Names" registry. (Should future names be limited to 9 chars?) I would rather not put extra restrictions on another registry due to limitations on SASL mechanism names. I would also note that the likelyhood of registering another SCRAM mechanism name is quite low, and the likelyhood of the conflict described above is even lower, so I wouldn't worry too much about this case anyway. ___ 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-sasl-scram-07
On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell wrote: [...] > Minor issues: [...] > -- section 4, first paragraph: "...as long as this alternative name doesn’t > conflict with any other hash function name from the IANA "Hash Function > Textual Names" registry." > > What prevents future conflicts if someone registers a name that conflicts > with the short name? Good point. > Should the short-names be IANA registered to prevent > this? This is a good idea. I've added: Such alternative name SHOULD be registered in the IANA "Hash Function Textual Names" registry. > (Should future names be limited to 9 chars?) I would rather not put extra restrictions on another registry due to limitations on SASL mechanism names. I would also note that the likelyhood of registering another SCRAM mechanism name is quite low, and the likelyhood of the conflict described above is even lower, so I wouldn't worry too much about this case anyway. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] RE review of draft-ietf-roll-building-routing-reqs-07.txt
Hi Francis, Can you precise a little bit more why you think draft 07 is USA centric? Mainly because of section 8.2 and section 9.1.2? other sections? Regarding section 8.2, I don't fully understand your expectation... Do you expect a few words on LON / Echelon, ASHRAE... for instance? Have a nice week-end & Best regards, Nicolas Francis Dupont Envoyé par : francis.dup...@fdupont.fr 02/10/2009 10:45 A gen-art@ietf.org cc jerald.p.marto...@jci.com, Nicolas Riou/FR/schnei...@europe, pieter.de...@intec.ugent.be, wou...@vooruit.be, adrian.far...@huawei.com Objet review of draft-ietf-roll-building-routing-reqs-07.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-roll-building-routing-reqs-07.txt Reviewer: Francis Dupont Review Date: 2009-09-29 IETF LC End Date: 2009-09-24 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - IMHO the document is a bit USA centric (but it is not a problem if it is stated in the document, for instance with a reference from the (US) building automation community, cf 8.2 comment below) Nits/editorial comments: - the language of the document is not at the usual level (but at it should be considered as better it is not a concern) - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14. 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20: e.g. -> e.g., - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e., add "(MS)" after "facility management system" - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous: it can stand for point and the point-to-point term usually refers to link topology. I propose: P2P -> (peer-to-peer, P2P) (MP2P) -> (multi-peers-to-peer, MP2P) (P2MP) -> (peer-to-multi-peers, P2MP) - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment (for uniformity with the section title where this spelling is enforced) (multiple occurrences) - 5.1 page 11: no network knowledge -> no communication network knowledge - 5.2.2 page 13: even it is also overloaded: point-to-point -> end-to-end - 5.4 page 14: i.e. -> i.e., - 5.4.3 page 14: 2000mah -> 2000mAh - 5.7.6 page 17: msec -> ms - 7 page 19: J. P. -> JP. - 8.2 page 19: I'd really like to get a reference from the building automation community: explaining networking to them or an introduction for us (networking community) or both. I expect there are at least some framework standards. - 9.1.2 page 19: 2.4Ghz -> 2.4GHz (BTW the ISM band text is very USA centric :-) - 9.3.1 page 20: missing final '.' - Authors' Addresses page 22: unfinished (???), add +1 for USA phone number, -- -> - (and BTW try to use the same separator) Regards francis.dup...@fdupont.fr __ This email has been scanned by the MessageLabs Email Security System. __ ___ 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-sasl-scram-07
Hi Ben, Thank you for your comments. Responding to most of them below (I will respond to the rest in a separate message). On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell 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-sasl-scram-07 > Reviewer: Ben Campbell > Review Date: 2009-08-23 > IETF LC End Date: 2009-08-28 > IESG Telechat date: (if known) > > Summary: > > This draft is almost ready for publication as a proposed standard. I have a > few questions and editorial comments that might be worth considering prior > to publication. > > Major issues: > > None. > > > Minor issues: > > - Section 2, 1st paragraph: "...addresses the requirements necessary to > deploy a challenge- response mechanism more widely than past attempts." > > What are these requirements? Are they documented somewhere? Do you mean for > appendix A or B to express them? Yes. I've added forward references. [...] > I'm no crypto expert, so please forgive me if this is silly--but isn't there > a movement to phase out sha-1? If so, should that be the default "must > implement" hash for a new mechanism? My understanding is that use of SHA-1 under HMAC is still considered reasonable. The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided to proceed with SHA-1, because it is more frequently implemented in libraries and hardware. > -- section 5.1, definition of "r:", "It is important that this value be > different for each authentication." > > Are there any best practices for nonce generation that can be mentioned or > referenced? The reference to RFC 4086 is already present elsewhere in the document, but I added it here. > -- Section 9, 1st paragraph: > > Can you describe the required properties expected from a "strong security > layer"? (i.e. confidentiality, integrity protection, etc.) I've added "(such as TLS with data confidentiality)". I hope this is clearer. [...] > --3rd paragraph: > > I gather you are saying that there are techniques that mitigate the damage > of a stolen authorization database, but the work group chose not to use > them. Can you elaborate on the wg motivation for not doing so? IPR claims on authentication mechanisms such as SRP. Text commenting on IPR was removed as per Pasi's request. > Nits/editorial comments: > > -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS? Added. > -- 1.2, last bullet: > > What is the referent for "this"? Is there perhaps a missing word(s), or > maybe this paragraph belongs with the previous bullet? The latter. (This == Hi()) > -- 2, last paragraph: > > Do you plan for this paragraph to stay in the RFC? Is the work group mail > list permanent enough to be published in the RFC? Deleted. > -- 5.1, definition of "c:", 2nd bullet: "(recall: a channel binding flag and > an optional authzid.) > > I'm not sure I follow the sentence. Do you mean to say something like > "Recall the G2 header contains a..." Yes. Changed. > -- IDNits reports the following: > > == Outdated reference: A later version (-03) exists of > draft-melnikov-sasl-scram-ldap-02 The two documents would be published simultaneously, so this will go away during editing by the RFC Editor. > It also reports a number of false errors about undefined references. I think > it's confused by your non-standard reference sections, which I think make > sense under the circumstances. Right. Regards, Alexey ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-roll-building-routing-reqs-07.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-roll-building-routing-reqs-07.txt Reviewer: Francis Dupont Review Date: 2009-09-29 IETF LC End Date: 2009-09-24 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - IMHO the document is a bit USA centric (but it is not a problem if it is stated in the document, for instance with a reference from the (US) building automation community, cf 8.2 comment below) Nits/editorial comments: - the language of the document is not at the usual level (but at it should be considered as better it is not a concern) - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14. 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20: e.g. -> e.g., - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e., add "(MS)" after "facility management system" - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous: it can stand for point and the point-to-point term usually refers to link topology. I propose: P2P -> (peer-to-peer, P2P) (MP2P) -> (multi-peers-to-peer, MP2P) (P2MP) -> (peer-to-multi-peers, P2MP) - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment (for uniformity with the section title where this spelling is enforced) (multiple occurrences) - 5.1 page 11: no network knowledge -> no communication network knowledge - 5.2.2 page 13: even it is also overloaded: point-to-point -> end-to-end - 5.4 page 14: i.e. -> i.e., - 5.4.3 page 14: 2000mah -> 2000mAh - 5.7.6 page 17: msec -> ms - 7 page 19: J. P. -> JP. - 8.2 page 19: I'd really like to get a reference from the building automation community: explaining networking to them or an introduction for us (networking community) or both. I expect there are at least some framework standards. - 9.1.2 page 19: 2.4Ghz -> 2.4GHz (BTW the ISM band text is very USA centric :-) - 9.3.1 page 20: missing final '.' - Authors' Addresses page 22: unfinished (???), add +1 for USA phone number, -- -> - (and BTW try to use the same separator) Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
