Re: [Gen-art] review of draft-moriarty-pkcs12v1-1-03.txt
Thanks for your review, Francis, and for your edits, Kathleen. Do you Kathleen or Sean think that Francis' comment on strengthening the security considerations would be something that you should address? jari On Jan 13, 2014, at 6:02 PM, Moriarty, Kathleen kathleen.moria...@emc.com wrote: Hi Francis, I went to update your comments in my draft version and in thinking about it more, I agree with the current text on the public/private order. As I read it, the referenced keys are discussed for the keys that validate and I assume you read it as the creation of a signature or to encrypt. I'm going to leave that as-is. Thanks, Kathleen -Original Message- From: Moriarty, Kathleen Sent: Monday, January 13, 2014 9:42 AM To: 'francis.dup...@fdupont.fr'; gen-art@ietf.org Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org Subject: RE: review of draft-moriarty-pkcs12v1-1-03.txt Thank you for the review, Francis. Once this version is published, change control and copyright is transferred to the IETF. The next version of this document will work to improve known issues. I will make the change from public/private to private/public as noted, that makes sense. I would imagine it was only written that way as the key pairs are typically referred to in that order as opposed to the original author thinking through the sentence as you had done. I have a few other edits to include and will have this ready before the end of the week. Thank you, Kathleen -Original Message- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Monday, January 13, 2014 8:56 AM To: gen-art@ietf.org Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org Subject: review of draft-moriarty-pkcs12v1-1-03.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-moriarty-pkcs12v1-1-03.txt Reviewer: Francis Dupont Review Date: 20130104 IETF LC End Date: 20130110 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: (not really technical) PKCS#12 was subject to concerns from teh cryptography community, in particular from Peter Gutmann, based on: - its (too) high complexity (BTW IMHO it is a legitimate concern: complexity is not wellcome for a security device) - (related to the previous item) its possible misuse with private key, summarized by this famous warning in OpenSSL FAQ: Occasionally someone suggests using a command such as: openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose. Unfortunately I can't see how we can address these concerns in the document. Perhaps with a stronger security considerations section? Nits/editorial comments: - TOC page 3 and F page 29: Acknowledgements - Acknowledgments - 1 page 4 in: The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. respectively suggests the same order but the private key is used to sign and the public key to encrypt. I propose to swap keys, i.e., to use private/public key pairs. - 5.1 5 B page 16: i.e. - i.e., - a full example should have been wellcome but IMHO it is far too late (and there are a lot of tools able to produce examples if needed :-). Regards francis.dup...@fdupont.fr ___ 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] review of draft-moriarty-pkcs12v1-1-03.txt
Hi Jari, Since this document is meant to transfer change control to the IETF, RSA would prefer to leave the document in-tact to match their published version as much as possible. There is IETF interest in starting a draft as soon as this is published to correct the well-known issues. We would prefer to take that approach and I am working to make sure we have at least one resource to edit the new document who has the background to make the changes and there may be others. Thank you, Kathleen -Original Message- From: Jari Arkko [mailto:jari.ar...@piuha.net] Sent: Tuesday, January 21, 2014 10:31 AM To: Moriarty, Kathleen; Sean P. Turner Cc: francis.dup...@fdupont.fr; gen-art@ietf.org; draft-moriarty-pkcs12v1-1@tools.ietf.org Subject: Re: [Gen-art] review of draft-moriarty-pkcs12v1-1-03.txt Thanks for your review, Francis, and for your edits, Kathleen. Do you Kathleen or Sean think that Francis' comment on strengthening the security considerations would be something that you should address? jari On Jan 13, 2014, at 6:02 PM, Moriarty, Kathleen kathleen.moria...@emc.com wrote: Hi Francis, I went to update your comments in my draft version and in thinking about it more, I agree with the current text on the public/private order. As I read it, the referenced keys are discussed for the keys that validate and I assume you read it as the creation of a signature or to encrypt. I'm going to leave that as-is. Thanks, Kathleen -Original Message- From: Moriarty, Kathleen Sent: Monday, January 13, 2014 9:42 AM To: 'francis.dup...@fdupont.fr'; gen-art@ietf.org Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org Subject: RE: review of draft-moriarty-pkcs12v1-1-03.txt Thank you for the review, Francis. Once this version is published, change control and copyright is transferred to the IETF. The next version of this document will work to improve known issues. I will make the change from public/private to private/public as noted, that makes sense. I would imagine it was only written that way as the key pairs are typically referred to in that order as opposed to the original author thinking through the sentence as you had done. I have a few other edits to include and will have this ready before the end of the week. Thank you, Kathleen -Original Message- From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Sent: Monday, January 13, 2014 8:56 AM To: gen-art@ietf.org Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org Subject: review of draft-moriarty-pkcs12v1-1-03.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-moriarty-pkcs12v1-1-03.txt Reviewer: Francis Dupont Review Date: 20130104 IETF LC End Date: 20130110 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: (not really technical) PKCS#12 was subject to concerns from teh cryptography community, in particular from Peter Gutmann, based on: - its (too) high complexity (BTW IMHO it is a legitimate concern: complexity is not wellcome for a security device) - (related to the previous item) its possible misuse with private key, summarized by this famous warning in OpenSSL FAQ: Occasionally someone suggests using a command such as: openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose. Unfortunately I can't see how we can address these concerns in the document. Perhaps with a stronger security considerations section? Nits/editorial comments: - TOC page 3 and F page 29: Acknowledgements - Acknowledgments - 1 page 4 in: The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. respectively suggests the same order but the private key is used to sign and the public key to encrypt. I propose to swap keys, i.e., to use private/public key pairs. - 5.1 5 B page 16: i.e. - i.e., - a full example should have been wellcome but IMHO it is far too late (and there are a lot of tools able to produce examples if needed :-). Regards francis.dup...@fdupont.fr ___ 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] Gen-ART LC review of draft-ietf-mpls-multipath-use-03
Many thanks for your (once again) detailed review, Peter! And thank you Curtis for making the fixes. One comment below: Make all references to the expansion of ECMP read Equal-Cost Multipath for consistency with RFC 2991. ECMP is expanded on first use in compliance with RFC Editor quidelines for abbreviations. ECMP is also expanded on first use within each section where it is used with the exception of one place where ECMP is contained in a verbatim excerpt in a quote from RFC6374. I thought Peter was referring to the fact that your draft has some variation on the way the term is expanded, even outside verbatim examples: % grep -i 'equal' draft-ietf-mpls-multipath-use-03.txt draft-ietf-mpls-multipath-use-03.txt:94: than parallel links includes Equal Cost MultiPath (ECMP) as applied draft-ietf-mpls-multipath-use-03.txt:148: Equal Cost Multipath (ECMP) draft-ietf-mpls-multipath-use-03.txt:149: Equal Cost Multipath (ECMP) is a specific form of multipath in draft-ietf-mpls-multipath-use-03.txt:229: Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed draft-ietf-mpls-multipath-use-03.txt:288: following paragraph in Section 2.9.4 Equal Cost Multipath gives the … % grep -i equal rfc2991.txt rfc2991.txt: allow Equal-Cost Multipath (ECMP) routing. Some router … I think you could align other instances than those relating to verbatim text from RFC 5960 or 6374. Anyway, minor things. I have balloted no-objection for this draft for the Thursday's IESG telechat. Thanks for your hard work, all. Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-shore-icmp-aup-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-shore-icmp-aup-09
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 0
This document is ready as a BCP.
I had reviewed -06 for Gen-ART and all of my comments in -06 have been
addressed. I have no further comments.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-l2vpn-evpn-req-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-evpn-req-06
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 2
This document is ready for publication as an Informational.
The document is ready, most of the nits in the nit-list I had have
been addressed by the IESG during balloting. That said, the remaining
nits on my list are:
- The requirements in the Security Considerations section (R13 and R14)
are better put in Section 6 (Ease of Provisioning Requirements), no?
Is there something intrinsic to do with security on R13 and R14 that
they are put in the Security Considerations section? If there is, it
is not apparent to me.
- Grammar/language: Section 7, Requirement 9:
s/This gives rise to two/This results in two/
(Reason: gives rise to is probably best left to works of
fiction :-) )
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
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-6man-stable-privacy-addresses-16
Ben: thanks for your review re-review. Jari On Dec 24, 2013, at 4:31 AM, Ben Campbell b...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-stable-privacy-addresses-16 Reviewer: Ben Campbell Review Date: 2013-12-23 IETF LC End Date: 2013-12-25 Summary: Ready for publication as a standards track RFC. Note: I performed a Gen-ART review on version 06 of this draft at a previous IETF LC. While the draft has evolved quite a bit since then, this review is mostly incremental to that one. All of my comments from that review have been addressed. Major issues: None Minor issues: None Nits/editorial comments: None ___ 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] Gen-ART review of draft-ietf-isis-rfc6326bis-01
Thanks for your review, Alexey! And thank you Donald for considering the comments. I have placed a no-obj position on the ballot for this Thursday's IESG telechat. But I do think Alexey raised valid points and I expect the draft to be revised. Will you take care of that, Donald? Jari On Jan 20, 2014, at 8:11 PM, Alexey Melnikov alexey.melni...@isode.com wrote: Hi Donald, On 20/01/2014 16:45, Donald Eastlake wrote: Hi Alexey, Thanks for your review, see below: On Mon, Jan 20, 2014 at 6:12 AM, Alexey Melnikov alexey.melni...@isode.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isis-rfc6326bis-01 Reviewer: Alexey Melnikov Review Date: 2014-01-20 IETF LC End Date: 2014-01-22 IESG Telechat date: 2014-01-23 Summary: This draft is nearly ready for publication as a standard track RFC. Major issues: None Minor issues: o Label: This carries the fine-grained label identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no label is specified. I fully admit ignorance of the topic, but what is exactly fine-grained label and where is the exact format defined? If it is defined later in the document, can you please add a forward reference. If it is defined in another document, can you please add a reference to that. Fine grained labels are specified in draft-ietf-trill-fine-labeling-07, which is an approved standard track draft in the RFC Editor's queue. Adding a reference to it here would be good. Sounds great. Thanks. In Sections 2.2.4 and 2.3.1: What are the requirements on backward compatibility between different versions of TRILL. Are TLVs formats supported for a version N also valid for version N+M? If you have any implied assumptions, please state them in the document. There are no explicit requirements. Incremental changes and improvements are generally handed with capability bits or the presence/absence of data strucutres in control messages. A version change would probably indicate a pretty major modification but, since these version numbers are within IS-IS TLVs, I would say that implicitly the intent is to stay with the IS-IS PDU structure for the control plane. I think the document should state that. Also, if you want any messages to be unchanged (fully or partially) irrespectively of version numbers, you should state that too. Best Regards, Alexey ___ 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] Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-12
Thanks for your review re-review, David! I have balloted no-obj, for this Thursday's IESG telechat. Jari On Jan 17, 2014, at 1:30 AM, Black, David david.bl...@emc.com wrote: The -12 version of this draft addresses the nits and editorial items noted in the Gen-ART review of the -11 version. It's ready for RFC publication. Thanks, --David -Original Message- From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Black, David Sent: Sunday, December 29, 2013 9:51 PM To: General Area Review Team (gen-art@ietf.org); attila.tak...@ericsson.com; donald.fe...@alcatel-lucent.com; he...@huawei.com Cc: adr...@olddog.co.uk; cc...@ietf.org; i...@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ccamp-oam-configuration- fwk-11 One additional nit - Don Fedyk's email address listed in the draft does not work. Thanks, --David -Original Message- From: Black, David Sent: Sunday, December 29, 2013 9:46 PM To: General Area Review Team (gen-art@ietf.org); attila.tak...@ericsson.com; donald.fe...@alcatel-lucent.com; he...@huawei.com Cc: Black, David; adr...@olddog.co.uk; cc...@ietf.org; i...@ietf.org Subject: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-oam-configuration-fwk-11 Reviewer: David L. Black Review Date: December 29, 2013 IETF LC End Date: January 5, 2014 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes the GMPLS framework for signaling OAM configuration, and specifies additional RSVP elements to support that signaling. Knowledge of RSVP, and specifically RSVP-TE is assumed; beyond that, the draft is complete, although it is very detailed - see editorial comment below on Section 3. Nits/editorial comments: Sections 3.1-3.3 dive into the details very quickly. They would be easier to understand if there was an overview paragraph near the start of Section 3 that describes the roles of the two ADMIN_STATUS flags and the two LSP Attributes flags in OAM configuration (establishment, change/adjustment, deletion) before the current text that contains the details of RSVP message processing. There are a number of instances of (IANA to assign) in section 4 that the RFC Editor will need to remove - an RFC Editor note to that effect should be inserted at the start of Section 4. Section 4.5 is necessarily incomplete on P2MP considerations, because (as it says) P2MP OAM mechanisms are very specific to the data plane technology. It would be helpful if section 4.5 contained language indicating what a specific data plane specification should include to completely specify P2MP OAM configuration for that data plane. idnits 2.13.01 didn't find anything that needs attention. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.comMobile: +1 (978) 394-7754 ___ 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 ___ 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-mpls-multipath-use-03
In message e736f946-88d0-4262-b2dd-c62fc461a...@piuha.net Jari Arkko writes: Many thanks for your (once again) detailed review, Peter! And thank you Curtis for making the fixes. One comment below: Make all references to the expansion of ECMP read Equal-Cost Multipath for consistency with RFC 2991. ECMP is expanded on first use in compliance with RFC Editor quidelines for abbreviations. ECMP is also expanded on first use within each section where it is used with the exception of one place where ECMP is contained in a verbatim excerpt in a quote from RFC6374. I thought Peter was referring to the fact that your draft has some variation on the way the term is expanded, even outside verbatim examples: % grep -i 'equal' draft-ietf-mpls-multipath-use-03.txt draft-ietf-mpls-multipath-use-03.txt:94: than parallel links includes Equal Cost MultiPath (ECMP) as applied draft-ietf-mpls-multipath-use-03.txt:148: Equal Cost Multipath (ECMP) draft-ietf-mpls-multipath-use-03.txt:149: Equal Cost Multipath (ECMP) is a specific form of multipath in draft-ietf-mpls-multipath-use-03.txt:229: Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed draft-ietf-mpls-multipath-use-03.txt:288: following paragraph in Section 2.9.4 Equal Cost Multipath gives the % grep -i equal rfc2991.txt rfc2991.txt: allow Equal-Cost Multipath (ECMP) routing. Some router I think you could align other instances than those relating to verbatim text from RFC 5960 or 6374. Anyway, minor things. I have balloted no-objection for this draft for the Thursday's IESG telechat. Thanks for your hard work, all. Jari Jari, Thanks for the no-objection. There doesn't seem to be much consistency on ECMP expansion. Checking abstracts in rfc-index: RFC2992 (same authors as RFC2991) uses: Equal-Cost Multi-Path- in the title Equal-cost multi-path (ECMP) - in the abstract RFC4928 uses: Equal Cost Multipath (ECMP) RFC5640 uses: equal cost multiple paths (ECMPs) RFC6391 uses: Equal Cost Multiple Paths (ECMPs) RFC6754 in the title uses: Equal-Cost Multipath (ECMP) You'll get a few more combinations of hyphenation and capitalization if you try: grep -i 'equal[- ]cost' rfc.txt | grep ECMP The total count for space vs hyphen (up to rfc7052) are: grep -i 'equal cost multi' rfc.txt | grep ECMP | wc -l 47 grep -i 'equal-cost multi' rfc.txt | grep ECMP | wc -l 26 grep -i 'equal cost multi' rfc.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 34 grep -i 'equal-cost multi' rfc.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 18 The hyphen form is used less often recently (May 2008 - Oct 2013). grep -i 'equal cost multi' rfc[567]???.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 27 grep -i 'equal-cost multi' rfc[567]???.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 10 grep -i 'equal cost multi' rfc[67]???.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 15 grep -i 'equal-cost multi' rfc[67]???.txt | grep ECMP \ | sed 's/:.*//' | uniq | wc -l 8 I prefer the RFC4928 flavor of this acronym and the above greps show that it is more widely used in the RFC series. Curtis ___ 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-mpls-moving-iana-registries
Thanks for your review, Robert. These reviews are important for helping me to determine whether a document needs further review or if there are issues that I'd need to pay special attention to. I have balloted no-obj for this document on the upcoming IESG telechat. Jari On Jan 16, 2014, at 8:57 PM, Robert Sparks rjspa...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-moving-iana-registries Reviewer: Robert Sparks Review Date: 16-Jan-2014 IETF LC End Date: 17-Jan-2014 IESG Telechat date: 23-Jan-2014 Summary: This document is ready for publication as Proposed Standard ___ 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] Gen-ART review of draft-shore-icmp-aup-09
Thank you for the review and re-review, and for the changes that occurred in
between. I have balloted no-obj…
Jari
On Jan 21, 2014, at 6:41 PM, Vijay K. Gurbani v...@bell-labs.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-shore-icmp-aup-09
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 0
This document is ready as a BCP.
I had reviewed -06 for Gen-ART and all of my comments in -06 have been
addressed. I have no further comments.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
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] Gen-ART review of draft-ietf-l2vpn-evpn-req-06
Thanks for your review and re-review, Vijay. And thanks for the authors for the
changes that occurred between the two reviews.
I do agree with Vijay's point about R13 and R14.
Jari
On Jan 21, 2014, at 6:32 PM, Vijay K. Gurbani v...@bell-labs.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-evpn-req-06
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 2
This document is ready for publication as an Informational.
The document is ready, most of the nits in the nit-list I had have
been addressed by the IESG during balloting. That said, the remaining
nits on my list are:
- The requirements in the Security Considerations section (R13 and R14)
are better put in Section 6 (Ease of Provisioning Requirements), no?
Is there something intrinsic to do with security on R13 and R14 that
they are put in the Security Considerations section? If there is, it
is not apparent to me.
- Grammar/language: Section 7, Requirement 9:
s/This gives rise to two/This results in two/
(Reason: gives rise to is probably best left to works of
fiction :-) )
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-Art telechat review of draft-farrell-perpass-attack-04
Sam: I believe that all you ask is still there. We will consider PM at architecture time, and anyone can contribute. We'll take it seriously. What's missing is the requirement to demonstrate that you have covered all the issues, to an unknown level. Essentially this is how we work already. Scott ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-Art telechat review of draft-farrell-perpass-attack-04
On 1/21/2014 1:38 PM, Sam Hartman wrote: I think that consideration of perpass at the architectural level, being prepared to justify decisions, and seeking adequate review of those decision ... I value integrity and honesty very highly and am feel sick when I think about claiming to the world that we're going to address perpass mitigations without being willing to commit to ourselves to do the architectural work. Sam, Consider the level of activity on this topic that is already happening in the IETF, as well as the nature of this initial document. I'll suggest that that's the most important demonstration of organizational commitment. The document in question marks that commitment, but it needs to be careful not to mark it beyond our current capabilities. In particular please point me/us to established consensus documents that define the problem space, the solution space and the architectural choices appropriate to this topic. I'm not aware of any, but perhaps I missed them. Absent established documents on this topic, justifying is only reasonable in terms of demonstrating thoughtfulness, not demonstrating that the choices are correct. Yet a term like justify encourages this latter expectations. the view that we have far more community clue about this topic than we currently have. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04
Thanks for your detailed review, Martin! And thank you Victor for a very useful document! Much of the discussion in this thread is important but also partly editorial. I'll leave it to sort out between yourselves. However, I do think Section 6 last sentence: Should a provide choose to use non-assigned IP address space within their translation realms, then considerations may apply. gives an odd impression. We already have shared address space (as the document notes elsewhere), so it is not clear to me what the above might entail, particularly when (a) regular address space assignments go through the RIR system not IANA (b) use of unassigned address space is probably not something that we want to recommend and (c) if we need to do something beyond the existing shared address space allocation, then that probably deserves its own document. I can see that Victor you've already agreed to make a change wrt Section 6. I just wanted to check that this is indeed the plan, so that we can move on to approving the document :-) Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-isis-rfc6326bis-01
Hi Jari, On Tue, Jan 21, 2014 at 5:01 PM, Jari Arkko jari.ar...@piuha.net wrote: Thanks for your review, Alexey! And thank you Donald for considering the comments. I have placed a no-obj position on the ballot for this Thursday's IESG telechat. But I do think Alexey raised valid points and I expect the draft to be revised. Will you take care of that, Donald? I have a version ready to post with some minor editorial fixes and the like and would be happy to include the missing reference to draft-ietf-trill-fine-labeling; however, I would prefer not to include the somewhat hand-waving text I wrote about TRILL protocol version number and I am not sure how long it would take to come up with a good statement on that... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Jari On Jan 20, 2014, at 8:11 PM, Alexey Melnikov alexey.melni...@isode.com wrote: Hi Donald, On 20/01/2014 16:45, Donald Eastlake wrote: Hi Alexey, Thanks for your review, see below: On Mon, Jan 20, 2014 at 6:12 AM, Alexey Melnikov alexey.melni...@isode.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isis-rfc6326bis-01 Reviewer: Alexey Melnikov Review Date: 2014-01-20 IETF LC End Date: 2014-01-22 IESG Telechat date: 2014-01-23 Summary: This draft is nearly ready for publication as a standard track RFC. Major issues: None Minor issues: o Label: This carries the fine-grained label identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no label is specified. I fully admit ignorance of the topic, but what is exactly fine-grained label and where is the exact format defined? If it is defined later in the document, can you please add a forward reference. If it is defined in another document, can you please add a reference to that. Fine grained labels are specified in draft-ietf-trill-fine-labeling-07, which is an approved standard track draft in the RFC Editor's queue. Adding a reference to it here would be good. Sounds great. Thanks. In Sections 2.2.4 and 2.3.1: What are the requirements on backward compatibility between different versions of TRILL. Are TLVs formats supported for a version N also valid for version N+M? If you have any implied assumptions, please state them in the document. There are no explicit requirements. Incremental changes and improvements are generally handed with capability bits or the presence/absence of data strucutres in control messages. A version change would probably indicate a pretty major modification but, since these version numbers are within IS-IS TLVs, I would say that implicitly the intent is to stay with the IS-IS PDU structure for the control plane. I think the document should state that. Also, if you want any messages to be unchanged (fully or partially) irrespectively of version numbers, you should state that too. Best Regards, Alexey ___ 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] Gen-ART review of draft-ietf-isis-rfc6326bis-01
On Jan 22, 2014, at 1:21 AM, Donald Eastlake d3e...@gmail.com wrote: Hi Jari, On Tue, Jan 21, 2014 at 5:01 PM, Jari Arkko jari.ar...@piuha.net wrote: Thanks for your review, Alexey! And thank you Donald for considering the comments. I have placed a no-obj position on the ballot for this Thursday's IESG telechat. But I do think Alexey raised valid points and I expect the draft to be revised. Will you take care of that, Donald? I have a version ready to post with some minor editorial fixes and the like and would be happy to include the missing reference to draft-ietf-trill-fine-labeling; Great! however, I would prefer not to include the somewhat hand-waving text I wrote about TRILL protocol version number and I am not sure how long it would take to come up with a good statement on that… Ok Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04
Jari/Martin, With respect to section 6, I agree we can remove the odd text and I will follow Martin's suggestion. The inclusion of that text was a bit historical as the document was actual first drafted before RFC6598. I would agree that (as this point) that text, as I have in the document, servers little value - so it will be removed. I will also respond to Martins last email and confirm some of the editorial changes. Jari, Please let me know if I need if you need to see a new draft spun before approvals or if confirmation of the changes is sufficient (I am ok with either). I was trying to capture all final adjustments for a -05 version before publishing. regards, Victor K On Tue, Jan 21, 2014 at 6:06 PM, Jari Arkko jari.ar...@piuha.net wrote: Thanks for your detailed review, Martin! And thank you Victor for a very useful document! Much of the discussion in this thread is important but also partly editorial. I'll leave it to sort out between yourselves. However, I do think Section 6 last sentence: Should a provide choose to use non-assigned IP address space within their translation realms, then considerations may apply. gives an odd impression. We already have shared address space (as the document notes elsewhere), so it is not clear to me what the above might entail, particularly when (a) regular address space assignments go through the RIR system not IANA (b) use of unassigned address space is probably not something that we want to recommend and (c) if we need to do something beyond the existing shared address space allocation, then that probably deserves its own document. I can see that Victor you've already agreed to make a change wrt Section 6. I just wanted to check that this is indeed the plan, so that we can move on to approving the document :-) Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
