RE: [storm] Last Call: draft-ietf-storm-iscsi-sam-06.txt (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard
A number of the documents referenced by this draft are T10 (SCSI) standards that are access-restricted to members of that organization unless a copy is purchased - this requirement has been imposed by the parent organization of T10; please do not complain to T10 about this. As the official liaison from T10 to the IETF, I am authorized to provide copies of these standards to IETF participants for their personal use in IETF activity. Of course, if you work for a company that is a T10 or T11 member, you can get these documents directly, and I'd ask that you do so. This applies to the following documents: - Normative references: -- T10 [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). [SAM4] ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-4). The Committee Drafts of [SAM5] and [SPC4] are public documents. I can help with access to them if there are problems. If you would like copies of any of these standards, please send me an email directly (please *don't* cc: either the IETF or STORM mailing lists) and indicate which standards you would like copies of. Of course, if you work for a company that is a T10 or T11 member, you can obtain these documents directly, and I'd ask that you do so. 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.com Mobile: +1 (978) 394-7754 -Original Message- From: storm-boun...@ietf.org [mailto:storm-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, July 16, 2012 5:20 PM To: IETF-Announce Cc: st...@ietf.org Subject: [storm] Last Call: draft-ietf-storm-iscsi-sam-06.txt (Internet Small Computer Systems Interface (iSCSI) SCSI Features Update) to Proposed Standard The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'Internet Small Computer Systems Interface (iSCSI) SCSI Features Update' draft-ietf-storm-iscsi-sam-06.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Please note the concurrent Last Call for draft-ietf-storm-iscsi-cons, as both drafts should be reviewed together. Abstract Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. This last call explicitly identifies these downrefs in the normative references of this document: [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). [SAM4] ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM- 4). [SAM5] T10/2104D rev r04, SCSI Architecture Model - 5 (SAM- 5), Committee Draft. [SPC4] T10/1731D rev r23, SCSI Primary Commands - 4 (SPC-4), Committee Draft. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ballot/ No IPR declarations have been submitted directly on this I-D. ___ storm mailing list st...@ietf.org https://www.ietf.org/mailman/listinfo/storm
RE: [storm] Last Call: draft-ietf-storm-iscsi-cons-06.txt (iSCSI Protocol (Consolidated)) to Proposed Standard
A number of the documents referenced by this draft are T10 (SCSI) and T11 (FC) standards that are access-restricted to members of those organizations unless a copy is purchased - this requirement has been imposed by the parent organization of T10 and T11; please do not complain to T10 or T11 about this. As the official liaison from both T10 and T11 to the IETF, I am authorized to provide copies of these standards to IETF participants for their personal use in IETF activity. This applies to the following documents: - Normative references: -- T10 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). [SPC3] T10/1416-D, SCSI Primary Commands-3. -- T11 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling Interface (FC-FS). - Informative References -- T10 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). If you would like copies of any of these standards, please send me an email directly (please *don't* cc: either the IETF or STORM mailing lists) and indicate which standards you would like copies of. Of course, if you work for a company that is a T10 or T11 member, you can get these documents directly, and I'd ask that you do so. Thanks, --David -Original Message- From: storm-boun...@ietf.org [mailto:storm-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, July 16, 2012 5:19 PM To: IETF-Announce Cc: st...@ietf.org Subject: [storm] Last Call: draft-ietf-storm-iscsi-cons-06.txt (iSCSI Protocol (Consolidated)) to Proposed Standard The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'iSCSI Protocol (Consolidated)' draft-ietf-storm-iscsi-cons-06.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Please note the concurrent Last Call for draft-ietf-storm-iscsi-sam, as both drafts should be reviewed together. Abstract This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. This last call explicitly identifies these downrefs in the normative references of this document: [EUI] Guidelines for 64-bit Global Identifier (EUI-64), http://standards.ieee.org/regauth/oui/tutorials/EUI64.html [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling Interface (FC-FS). [OUI] IEEE OUI and Company_Id Assignments, http://standards.ieee.org/regauth/oui [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). [SPC3] T10/1416-D, SCSI Primary Commands-3. [UML] ISO/IEC 19501, Unified Modeling Language Specification Version 1.4.2. [UNICODE] Unicode Standard Annex #15, Unicode Normalization Forms, http://www.unicode.org/unicode/reports/tr15 The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ballot/ No IPR declarations have been submitted directly on this I-D. ___ storm mailing list st...@ietf.org https://www.ietf.org/mailman/listinfo/storm
Gen-ART review of draft-ietf-bliss-shared-appearances-12
The -12 version of this draft resolves all of the comments in the Gen-ART review of the -11 version. Thanks, --David -Original Message- From: Black, David Sent: Thursday, June 28, 2012 4:51 PM To: alan.b.johns...@gmail.com; mohsen.soro...@sylantro.com; vvenka...@gmail.com; gen-...@ietf.org Cc: Black, David; Shida Schubert; bl...@ietf.org; IETF Discussion; Robert Sparks Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-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-bliss-shared-appearances-11 Reviewer: David L. Black Review Date: June 28, 2012 IETF LC End Date: June 28, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft describes support for shared appearances in support of multi-line and shared-line telephone often found in businesses. All of the open issues are minor. The draft is well-written and reasonably clear for the most part, although significant SIP expertise is required to completely understand it. Major issues: None. Minor issues: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. 5.3. A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA MUST free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. What happens when that can't be done due to UA or network failure? 5.4. A 400 response is returned if the chosen appearance number is invalid, Is that always a 400 (Bad Request) or is any 4xx response allowed? If it's always 400, add the words Bad Request after 400. If the Appearance Agent policy does not allow this, a 400 response is returned. Same question. In addition, is 403 Forbidden allowed here? If an INVITE is sent by a member of the group to the shared AOR (i.e. they call their own AOR), the Appearance Agent MUST assign two appearance numbers. The first appearance number will be the one selected or assigned to the outgoing INVITE. The second appearance number will be another one assigned by the Appearance Agent for the INVITE as it is forked back to the members of the group. How does that interact with the single appearance UAs in 8.1.1 that won't understand the second appearance number? A warning that such a UA can't pick up its call to its own AOR would suffice, either here or in 8.1.1. 9.1 A UA that has no knowledge of appearances must will only have appearance numbers for outgoing calls if assigned by the Appearance Agent. If the non-shared appearance UA does not support Join or Replaces, all dialogs could be marked exclusive to indicate that these options are not available. Should that could be marked be changed to SHOULD be marked ? Also, analogous questions for could in 9.2 and can in 9.3. All three of these affect interoperability. 12. Security Considerations In general, this section is weak on rationale - the second, third and fourth paragraphs should all explain more about the purpose of and/or rationale for their security requirements (e.g., what does the security mechanism protect against and when/why might that protection be desired and/or required?). NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms. What are the standard mechanisms? List them, and provide references, please. Please ensure that the section 6 XML and Section 7 ABNF are syntax-checked with actual tools. Nits/editorial comments: p.10: The next section discusses the operations used to implement parts of the shared appearance feature. The following list describes the operations ... would be better. 5.3.1. A UA wanting to place a call but not have an appearance number assigned publishes before sending the INVITE without an 'appearance' element but with the 'shared' event package parameter present. I think I understand what was intended here, but this would be clearer if publishes was replaced with language about sending a PUBLISH. It's also not completely clear whether without applies to the INVITE or the PUBLISH, so this sentence probably needs to be reworded. 5.4. - Expand B2BUA acronym on first use. idnits 2.12.13 ran clean. Thanks, --David David L. Black, Distinguished Engineer EMC
RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11
That works for me, Thanks, --David -Original Message- From: Worley, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Friday, June 29, 2012 3:18 PM To: alan.b.johns...@gmail.com Cc: Black, David; mohsen.soro...@sylantro.com; ietf@ietf.org; gen- a...@ietf.org; bl...@ietf.org; vvenka...@gmail.com Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 On Thu, 2012-06-28 at 20:05 -0500, Alan Johnston wrote: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. This requirement is about sending one request that causes both actions to occur. In a PSTN ringdown circuit (a very specialized circuit, used for hotlines), the two operations are the same thing. Besides this statement, is REQ-16 itself not clear? Perhaps I should just remove this statement if it adds confusion rather than clarity to the requirement. IMHO, a good fix is: REQ-16 The mechanism should support a way for a UA to seize a particular appearance number and also send the request at the same time. This is needed when an automatic ringdown feature (a telephone configured to immediately dial a phone number when it goes off hook) is combined with shared appearances - in this case, seizing the line is integrated with dialing. Dale
RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11
Alan, Thank you for the quick response. I have a few comments on the proposed resolutions. Absence of a comment implies that I agree with the proposed resolution. REQ-16 - I understand what's going on here (automatic ringdown), but the language is just slightly off because there is actually a dialing request. Here's all of REQ-16: REQ-16 The mechanism should support a way for a UA to seize a particular appearance number and also send the request at the same time. This is needed when an automatic ringdown feature (a telephone configured to immediately dial a phone number when it goes off hook) is combined with shared appearances - in this case, seizing the line is the same thing as dialing. The language problem is that the line seizing includes a dialing request, so is the same thing as isn't quite correct when applied solely to seizing the line. As you suggest, the simplest fix would be to just remove - in this case ... dialing, or it could be changed to: - in this case, seizing the line is part of dialing. 5.3 - Doing nothing is fine. I'm not a SIP expert, so I assume that the standard PUBLISH behavior (soft-state times out if not refreshed) is well-known to anyone who is, and hence no change is needed. 5.4 - please add (Bad Request) after each of the two instances of 400. 9.1/2/3 - please change to using SHOULD in each of these sections and explain that the SHOULD is motivated by user experience concerns. Thanks, --David -Original Message- From: Alan Johnston [mailto:alan.b.johns...@gmail.com] Sent: Thursday, June 28, 2012 9:05 PM To: Black, David Cc: mohsen.soro...@sylantro.com; vvenka...@gmail.com; gen-...@ietf.org; sh...@ntt-at.com; bl...@ietf.org; ietf@ietf.org; rjspa...@nostrum.com Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 David, Thank you for your review of the document. See below for how I propose to resolve the issues you have raised. Let me know if you have any other issues or concerns. - Alan - On Thu, Jun 28, 2012 at 3:51 PM, david.bl...@emc.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-bliss-shared-appearances-11 Reviewer: David L. Black Review Date: June 28, 2012 IETF LC End Date: June 28, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft describes support for shared appearances in support of multi-line and shared-line telephone often found in businesses. All of the open issues are minor. The draft is well-written and reasonably clear for the most part, although significant SIP expertise is required to completely understand it. Major issues: None. Minor issues: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. This requirement is about sending one request that causes both actions to occur. In a PSTN ringdown circuit (a very specialized circuit, used for hotlines), the two operations are the same thing. Besides this statement, is REQ-16 itself not clear? Perhaps I should just remove this statement if it adds confusion rather than clarity to the requirement. 5.3. A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA MUST free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. What happens when that can't be done due to UA or network failure? A little further down in this section says: This publication state is refreshed as described in [RFC3903] during the early dialog state or the Appearance Agent may reassign the appearance number. So if the removal publish is lost, it will eventually timeout since it is not refreshed. This is standard PUBLISH behavior described in RFC 3903. 5.4. A 400 response is returned if the chosen appearance number is invalid, Is that always a 400 (Bad Request) or is any 4xx response allowed? If it's always 400, add the words Bad Request after 400. We chose 400 in particular, although any 4xx response would have the same result. Bad Request is the reason phrase, and the practice of putting it in () is a convention commonly used in SIP documents. The actual reason phrase can be different, customized (Invalid Appearance) if desired, or in a different language. So in this case we are specifying the 400 response. If the Appearance Agent policy does not allow this, a 400 response is returned.
RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11
understand what was intended here, but this would be clearer if publishes was replaced with language about sending a PUBLISH. It's also not completely clear whether without applies to the INVITE or the PUBLISH, so this sentence probably needs to be reworded. 5.4. - Expand B2BUA acronym on first use. idnits 2.12.13 ran clean. 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.black at emc.comMobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-bliss-shared-appearances-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-bliss-shared-appearances-11 Reviewer: David L. Black Review Date: June 28, 2012 IETF LC End Date: June 28, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft describes support for shared appearances in support of multi-line and shared-line telephone often found in businesses. All of the open issues are minor. The draft is well-written and reasonably clear for the most part, although significant SIP expertise is required to completely understand it. Major issues: None. Minor issues: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. 5.3. A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA MUST free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. What happens when that can't be done due to UA or network failure? 5.4. A 400 response is returned if the chosen appearance number is invalid, Is that always a 400 (Bad Request) or is any 4xx response allowed? If it's always 400, add the words Bad Request after 400. If the Appearance Agent policy does not allow this, a 400 response is returned. Same question. In addition, is 403 Forbidden allowed here? If an INVITE is sent by a member of the group to the shared AOR (i.e. they call their own AOR), the Appearance Agent MUST assign two appearance numbers. The first appearance number will be the one selected or assigned to the outgoing INVITE. The second appearance number will be another one assigned by the Appearance Agent for the INVITE as it is forked back to the members of the group. How does that interact with the single appearance UAs in 8.1.1 that won't understand the second appearance number? A warning that such a UA can't pick up its call to its own AOR would suffice, either here or in 8.1.1. 9.1 A UA that has no knowledge of appearances must will only have appearance numbers for outgoing calls if assigned by the Appearance Agent. If the non-shared appearance UA does not support Join or Replaces, all dialogs could be marked exclusive to indicate that these options are not available. Should that could be marked be changed to SHOULD be marked ? Also, analogous questions for could in 9.2 and can in 9.3. All three of these affect interoperability. 12. Security Considerations In general, this section is weak on rationale - the second, third and fourth paragraphs should all explain more about the purpose of and/or rationale for their security requirements (e.g., what does the security mechanism protect against and when/why might that protection be desired and/or required?). NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms. What are the standard mechanisms? List them, and provide references, please. Please ensure that the section 6 XML and Section 7 ABNF are syntax-checked with actual tools. Nits/editorial comments: p.10: The next section discusses the operations used to implement parts of the shared appearance feature. The following list describes the operations ... would be better. 5.3.1. A UA wanting to place a call but not have an appearance number assigned publishes before sending the INVITE without an 'appearance' element but with the 'shared' event package parameter present. I think I understand what was intended here, but this would be clearer if publishes was replaced with language about sending a PUBLISH. It's also not completely clear whether without applies to the INVITE or the PUBLISH, so this sentence probably needs to be reworded. 5.4. - Expand B2BUA acronym on first use. idnits 2.12.13 ran clean. 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.com Mobile: +1 (978) 394-7754
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Joe and Pat, I'm less concerned about this - I think the words if suitable regarding use of existing IETF protocols are sufficient to support choosing the best solution whether it comes from IETF or elsewhere. As Pat notes: when the time comes, we will debate what is suitable anyway. I agree that such a debate is inevitable. 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.com Mobile: +1 (978) 394-7754 -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Joe Pelissier (jopeliss) Sent: Wednesday, April 25, 2012 7:35 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25- Apr-2012 update I too am uncomfortable with the wording regarding the IETF protocols. It seems that we should be striving to choose the best technical solution regardless of whether its an IETF protocol or that from another SDO. This can, and should, be covered as part of the gap analysis. Also, we should give preference to using existing suitable protocols (IETF or from other SDOs) over development of new protocols. Regards, Joe Pelissier -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Pat Thaler Sent: Wednesday, April 25, 2012 5:55 PM To: Stewart Bryant (stbryant); n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Stewart, The charter is looking pretty good. I'd like to get on to the next phase, but not with this text: Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. There are two issues with this: Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done. Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol. Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. Therefore, at least Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. should be deleted. Regards, Pat -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 25, 2012 2:39 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network.
Re: Last Call: draft-george-travel-faq-03.txt (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
This looks very useful. I have a few suggestions for the -04 version. (1) The addition of non-flight options to 3.1 is a good idea. That should be complemented by adding a sentence to the end of 3.1.1 (Transit between the airport and primary hotels) to say that if non-rail options are included, then corresponding info for them (e.g., how to get to/from the train station) should be included, although train stations are often more convenient to the meeting venue than airports. (2) In 3.1.1.1 to this bullet: o Description of official taxis if appropriate I'd suggest adding and advice on avoiding common taxi scams if appropriate. This is often not appropriate, but there are a (small) number of cities that are notorious for taxi scams; I think it helps to mention that here, even though scams are noted in general in the Health and Safety section (3.3.1). (3) In 3.7 Tourism, it might be good to add a suggestion to mention notable local events occurring during the meeting week that may be of interest - perhaps a local festival, although this suggestion was motivated by the wonderful fireworks in Quebec City. 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-marf-redaction-08
The -08 version is a significant improvement that aligns the draft's recommendations on mechanisms for redaction and anonymization with the situation-dependent levels of security that are appropriate for those purposes. idnits 2.12.13 didn't find anything. The -08 version is ready for publication as a Standards Track RFC. Thanks, --David -Original Message- From: Black, David Sent: Thursday, January 19, 2012 7:10 PM To: i...@cybernothing.org; Murray S. Kucherawy; gen-...@ietf.org; ietf@ietf.org Cc: m...@ietf.org; presn...@qualcomm.com; Black, David Subject: Gen-ART review of draft-ietf-marf-redaction-05 Based on discussion with the authors, the -05 version of this draft resolves the issues raised in the Gen-ART review of the -04 version. An important element of the approach taken to issue [1] has been to explain why the security requirements for redaction are significantly weaker than the strength of the secure hashes that are suggested by the draft. Thanks, --David -Original Message- From: Black, David Sent: Tuesday, January 10, 2012 9:44 PM To: i...@cybernothing.org; Murray S. Kucherawy; gen-...@ietf.org; ietf@ietf.org Cc: Black, David; m...@ietf.org; presn...@qualcomm.com Subject: Gen-ART review of draft-ietf-marf-redaction-04 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-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies a method for redacting information from email abuse reports (e.g., hiding the local part [user] of an email address), while still allowing correlation of the redacted information across related abuse reports from the same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectively hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string (redaction key) consists of a single ASCII character, and a short email local part is being redacted, then the output is highly vulnerable to dictionary and brute force attacks because only 6 bits of entropy are added (the result may look secure, but it's not). Beyond this extreme example, this is a potentially real concern - e.g., applying the rule of thumb that ASCII text contains 4-5 bits of entropy per character, the example in Appendix A uses a redaction key of potatoes that injects at most 40 bits of entropy - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of short input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key.
Gen-ART review of draft-daboo-webdav-sync-07
Hi Peter,
Yes, the new -07 of this draft is fine, as it resolves issues [1] and [2] as
agreed
with the authors, and also resolves issue [3] by changing RFC 5842 from a
normative
reference to an informative reference. That change is fine with me, as the
references
to RFC 5842 are all for examples that explain some of the synchronization
functionality
- it is not necessary to implement any of the requests listed as being
specified in
RFC 5842 in order to implement the synchronization functionality.
Thanks,
--David
-Original Message-
From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
Sent: Thursday, January 19, 2012 11:53 AM
To: Black, David
Cc: cy...@daboo.name; arnaud.quill...@oracle.com; gen-...@ietf.org;
ietf@ietf.org
Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06
Hi David,
The text changes that Cyrus proposed have been incorporated into a
revised I-D:
http://tools.ietf.org/rfcdiff?url2=draft-daboo-webdav-sync-07
Please let us know if the new version accurately reflects your
discussion with the authors.
Thanks!
Peter
On 1/2/12 12:55 PM, david.bl...@emc.com wrote:
Hi Cyrus,
The proposed changes for the two major issues look good to me:
[1] I'm pleased that the concern about adding elements turned out to be a
wording issue.
[2] Your proposed new text is fine - it provides adequate notice/warning
about possible
collection inconsistency, so I'm ok with not providing pseudo-code.
I'll leave the Downref issue ([3]) for you and Peter to work out with the
IESG, and I'm
fine with continued use of your name in the examples if that's common
practice.
Thanks,
--David
-Original Message-
From: Cyrus Daboo [mailto:cy...@daboo.name]
Sent: Monday, January 02, 2012 2:44 PM
To: Black, David; arnaud.quill...@oracle.com; gen-...@ietf.org;
ietf@ietf.org
Cc: stpe...@stpeter.im
Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06
Hi David,
Thank you for your review. Comments inline:
--On December 27, 2011 11:07:49 PM -0500 david.bl...@emc.com wrote:
[1] -Major- Section 3.5 does not appear to cover the case reporting added
elements on a subsequent synchronization. The problem may be that the
word changed as used in Section 3.5.1 is assumed to cover adding an
element - if so, that's not a good assumption, and the addition case
should be explicitly called out in the title and body of Section 3.5.1.
The first sentence of 3.5.1 is:
A member URL MUST be reported as changed if it has been mapped as a
member of the target collection since the request sync-token was
generated.
The term mapped implies creation/addition of a new resource in this case.
That may not be obvious to anyone who is not intimately familiar with
WebDAV terminology here, so I propose changing that to:
A member URL MUST be reported as changed if it has been newly mapped as
a member of the target collection since the request sync-token was
generated (e.g., when a new resource has been created as a child of the
collection).
[2] -Major- The operations to retrieve changed members of a collection
are not atomic wrt the operation that obtains a report on what has
changed; collection changes can occur between retrieving the report and
retrieving the changed elements or while retrieving the changed elements.
For this reason, simply obtaining a change report and then retrieving the
elements that have changed according to the report may not result in a
consistent (e.g., as of a point in time) copy of a collection. I believe
that this absence of atomicity is a WebDAV feature, as opposed to a
bug, but I believe that this behavior and what to do about it should be
discussed in the draft. I suggest the following, possibly to the end of
section 3.1
i) Add a sentence or two to warn that obtaining a change report and then
retrieving the changed elements may not result in a consistent local
version of the collection if nothing else is done because changes may
have occurred in the interim.
ii Add a discussion of how to ensure that a local copy of the collection
is consistent. The basic idea is to re-presented the sync token for that
copy to the server after the changed elements have been retrieved; the
local copy is consistent if the server reports that there have been no
changes. Some pseudo-code may help, e.g.:
GetSyncCollectionReport(in token, out newtoken, out report);
while (ReportHasChangedItems(report) {
GetChangedItems(report)
token = newtoken;
GetSyncCollectionReport(in token, out newtoken, out report);
}
Actual code should include a counter that counts the number of iterations
of the while loop and exits with an error if the number of iterations
exceeds some limit; that error exit implies that the collection is
(currently) changing too rapidly to obtain a
Gen-ART review of draft-ietf-marf-redaction-05
Based on discussion with the authors, the -05 version of this draft resolves the issues raised in the Gen-ART review of the -04 version. An important element of the approach taken to issue [1] has been to explain why the security requirements for redaction are significantly weaker than the strength of the secure hashes that are suggested by the draft. Thanks, --David -Original Message- From: Black, David Sent: Tuesday, January 10, 2012 9:44 PM To: i...@cybernothing.org; Murray S. Kucherawy; gen-...@ietf.org; ietf@ietf.org Cc: Black, David; m...@ietf.org; presn...@qualcomm.com Subject: Gen-ART review of draft-ietf-marf-redaction-04 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-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies a method for redacting information from email abuse reports (e.g., hiding the local part [user] of an email address), while still allowing correlation of the redacted information across related abuse reports from the same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectively hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string (redaction key) consists of a single ASCII character, and a short email local part is being redacted, then the output is highly vulnerable to dictionary and brute force attacks because only 6 bits of entropy are added (the result may look secure, but it's not). Beyond this extreme example, this is a potentially real concern - e.g., applying the rule of thumb that ASCII text contains 4-5 bits of entropy per character, the example in Appendix A uses a redaction key of potatoes that injects at most 40 bits of entropy - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of short input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that anonymization is a better description of what this draft is doing (as opposed to redaction), particularly as the result is intended to be correlatable via string match across reports from the same source. idnits 2.12.13 didn't find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953
RE: Gen-ART review of draft-ietf-marf-redaction-04
Hi, Thanks for the response - I appreciate the perspective. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. At a minimum, I like John Levine's suggestion that the draft explain the level of security required for redaction in practice. Such an explanation could help illuminate whether the secure hash (the example in the draft uses SHA-1) is for obfuscation purposes vs. actual security. Absent such an explanation, I saw the use of a secure hash and inferred the existence of actual security requirements. If that was an incorrect inference, then text should be added to the draft to avoid having other readers make similarly incorrect inferences. Thanks, --David -Original Message- From: SM [mailto:s...@resistor.net] Sent: Wednesday, January 11, 2012 2:50 PM To: Black, David Cc: m...@ietf.org; gen-...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, At 18:44 10-01-2012, david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please I appreciate that you have spent your time and effort in performing the review. I find the review useful. From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-marf-redaction-04
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-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies a method for redacting information from email abuse reports (e.g., hiding the local part [user] of an email address), while still allowing correlation of the redacted information across related abuse reports from the same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectively hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string (redaction key) consists of a single ASCII character, and a short email local part is being redacted, then the output is highly vulnerable to dictionary and brute force attacks because only 6 bits of entropy are added (the result may look secure, but it's not). Beyond this extreme example, this is a potentially real concern - e.g., applying the rule of thumb that ASCII text contains 4-5 bits of entropy per character, the example in Appendix A uses a redaction key of potatoes that injects at most 40 bits of entropy - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of short input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that anonymization is a better description of what this draft is doing (as opposed to redaction), particularly as the result is intended to be correlatable via string match across reports from the same source. idnits 2.12.13 didn't find any nits. 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-marf-redaction-04
Hi Murray, Thanks for the quick response. These are all good points. My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address. That sounds reasonable to me, and I like John Levine's suggestion to add material to explain more about the level of security that is appropriate for this problem space and why. In light of such an explanation, an HMAC-based mechanism could well be overkill. - make a SHOULD suggestion as to the minimum redaction key length (instead of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a requirement) I have a hard time believing that the examples used in the review (a as the redaction key, CRC as the hash) are ever acceptable, and for that reason, I think a couple of MUSTs would be in order to prohibit that sort of nonsense. In particular: - I think there ought to be a MUST minimum length requirement on the redaction key string to prevent really short ones. - I think use of a secure hash ought to be a MUST to prevent use of CRC and other bad ideas. That could be accompanied by additional guidance that may or may not be SHOULDs, e.g., suggest a SHA2 hash as a good secure hash, suggest use of a longer string than the minimum requirement. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Also a good point. I don't think this is the right place to introduce advice about key rotation and the like as those are well-discussed concepts, so instead Security Considerations can simply make reference to such material elsewhere. I'll go find some. I know there's stuff like that in RFC6376 (DKIM) but I'm sure there are better ones. That would be fine - introducing the concept of key rotation as a means to reduce the impact of key compromise accompanied by a reference to a longer explanation elsewhere seems reasonable. Thanks, --David -Original Message- From: Murray S. Kucherawy [mailto:m...@cloudmark.com] Sent: Tuesday, January 10, 2012 11:41 PM To: Black, David; i...@cybernothing.org; gen-...@ietf.org; ietf@ietf.org Cc: m...@ietf.org; presn...@qualcomm.com Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 -Original Message- From: david.bl...@emc.com [mailto:david.bl...@emc.com] Sent: Tuesday, January 10, 2012 6:44 PM To: i...@cybernothing.org; Murray S. Kucherawy; gen-...@ietf.org; ietf@ietf.org Cc: david.bl...@emc.com; m...@ietf.org; presn...@qualcomm.com Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. [...] I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. These are all good points. My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address. Thus, my inclination is to make the following changes (subject to WG consensus): - add all of this advice to Security
RE: Gen-ART review of draft-daboo-webdav-sync-06
Hi Cyrus,
The proposed changes for the two major issues look good to me:
[1] I'm pleased that the concern about adding elements turned out to be a
wording issue.
[2] Your proposed new text is fine - it provides adequate notice/warning about
possible
collection inconsistency, so I'm ok with not providing pseudo-code.
I'll leave the Downref issue ([3]) for you and Peter to work out with the IESG,
and I'm
fine with continued use of your name in the examples if that's common practice.
Thanks,
--David
-Original Message-
From: Cyrus Daboo [mailto:cy...@daboo.name]
Sent: Monday, January 02, 2012 2:44 PM
To: Black, David; arnaud.quill...@oracle.com; gen-...@ietf.org; ietf@ietf.org
Cc: stpe...@stpeter.im
Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06
Hi David,
Thank you for your review. Comments inline:
--On December 27, 2011 11:07:49 PM -0500 david.bl...@emc.com wrote:
[1] -Major- Section 3.5 does not appear to cover the case reporting added
elements on a subsequent synchronization. The problem may be that the
word changed as used in Section 3.5.1 is assumed to cover adding an
element - if so, that's not a good assumption, and the addition case
should be explicitly called out in the title and body of Section 3.5.1.
The first sentence of 3.5.1 is:
A member URL MUST be reported as changed if it has been mapped as a
member of the target collection since the request sync-token was
generated.
The term mapped implies creation/addition of a new resource in this case.
That may not be obvious to anyone who is not intimately familiar with
WebDAV terminology here, so I propose changing that to:
A member URL MUST be reported as changed if it has been newly mapped as
a member of the target collection since the request sync-token was
generated (e.g., when a new resource has been created as a child of the
collection).
[2] -Major- The operations to retrieve changed members of a collection
are not atomic wrt the operation that obtains a report on what has
changed; collection changes can occur between retrieving the report and
retrieving the changed elements or while retrieving the changed elements.
For this reason, simply obtaining a change report and then retrieving the
elements that have changed according to the report may not result in a
consistent (e.g., as of a point in time) copy of a collection. I believe
that this absence of atomicity is a WebDAV feature, as opposed to a
bug, but I believe that this behavior and what to do about it should be
discussed in the draft. I suggest the following, possibly to the end of
section 3.1
i) Add a sentence or two to warn that obtaining a change report and then
retrieving the changed elements may not result in a consistent local
version of the collection if nothing else is done because changes may
have occurred in the interim.
ii Add a discussion of how to ensure that a local copy of the collection
is consistent. The basic idea is to re-presented the sync token for that
copy to the server after the changed elements have been retrieved; the
local copy is consistent if the server reports that there have been no
changes. Some pseudo-code may help, e.g.:
GetSyncCollectionReport(in token, out newtoken, out report);
while (ReportHasChangedItems(report) {
GetChangedItems(report)
token = newtoken;
GetSyncCollectionReport(in token, out newtoken, out report);
}
Actual code should include a counter that counts the number of iterations
of the while loop and exits with an error if the number of iterations
exceeds some limit; that error exit implies that the collection is
(currently) changing too rapidly to obtain a consistent local version.
Good point. I agree that this deserves some additional text to clarify this
situation. However, I would rather not go into too much detail of how
clients re-sync in cases like this as there are a bunch of different ways
that could happen each of which depends on exactly what the client is
trying to do (e.g., in a lot of cases clients will be doing two-way syncs
so will need to reconcile server and local changes within the loop you
propose above - the details of that are not in scope for this
specification). What I propose is the addition of the following paragraph
to the end of Section 3.1:
Typically, a client will use the synchronization report to retrieve the
list of changes, and will follow that with requests to retrieve the
content of changed resources. It is possible that additional changes to
the collection could occur between the time of the synchronization
report and resource content retrieval, which could result in an
inconsistent view of the collection. When clients use this method of
synchronization, they need to be aware that such additional changes
could occur, and track them
Gen-ART review of draft-daboo-webdav-sync-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-daboo-webdav-sync-06
Reviewer: David L. Black
Review Date: December 27, 2011
IETF LC End Date: December 29, 2011
Summary: This draft is on the right track but has open issues, described in the
review.
This draft specifies new WebDAV functionality that reports on changes to
collections,
enabling a local copy to be kept in sync without retrieving the entire
collection each
time.
I found three open issues, two major, one minor:
[1] -Major- Section 3.5 does not appear to cover the case reporting added
elements on
a subsequent synchronization. The problem may be that the word changed as
used in
Section 3.5.1 is assumed to cover adding an element - if so, that's not a good
assumption, and the addition case should be explicitly called out in the title
and
body of Section 3.5.1.
[2] -Major- The operations to retrieve changed members of a collection are not
atomic
wrt the operation that obtains a report on what has changed; collection changes
can occur
between retrieving the report and retrieving the changed elements or while
retrieving the
changed elements. For this reason, simply obtaining a change report and then
retrieving
the elements that have changed according to the report may not result in a
consistent
(e.g., as of a point in time) copy of a collection. I believe that this
absence of
atomicity is a WebDAV feature, as opposed to a bug, but I believe that this
behavior
and what to do about it should be discussed in the draft. I suggest the
following,
possibly to the end of section 3.1
i) Add a sentence or two to warn that obtaining a change report and then
retrieving the changed
elements may not result in a consistent local version of the collection if
nothing else is
done because changes may have occurred in the interim.
ii Add a discussion of how to ensure that a local copy of the collection is
consistent.
The basic idea is to re-presented the sync token for that copy to the server
after the
changed elements have been retrieved; the local copy is consistent if the
server reports
that there have been no changes. Some pseudo-code may help, e.g.:
GetSyncCollectionReport(in token, out newtoken, out report);
while (ReportHasChangedItems(report) {
GetChangedItems(report)
token = newtoken;
GetSyncCollectionReport(in token, out newtoken, out report);
}
Actual code should include a counter that counts the number of iterations of
the while
loop and exits with an error if the number of iterations exceeds some limit;
that error
exit implies that the collection is (currently) changing too rapidly to obtain
a consistent
local version.
[3] -Minor- idnits 2.12.12 reports a Downref to RFC 5842. Please consult your
Area
Director (Peter Saint-Andre) to determine what to do about this Downref (it
requires
attention, but may not require changes to the draft).
Nit: I suggest not using the author's own name (cyrusdaboo) in the examples.
Someone
may copy the code from the resulting RFC.
Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been published
as RFC 6352;
the RFC Editor will correct this if a new version of the draft is not required
for other
reasons.
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.com Mobile: +1 (978) 394-7754
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-geopriv-policy-uri-02
Hi Richard, I think we're close: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network, thus relying on lower-layer security mechanisms. When neither application-layer or network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods, and SHOULD reject PUT and DELETE requests for policy URIs that use the http: URI scheme. This text looks good to me, except that the structure of the final sentence inadvertently neuters the final SHOULD requirement. Can we move that requirement into Section 7.1? The change in Section 7.2 would then be: OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network, thus relying on lower-layer security mechanisms. When neither application-layer or network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods. This change in Section 7.1 would pick up the moved requirement: OLD If other means of protection are available, an http: URI MAY be used. NEW If other means of protection are available, an http: URI MAY be used, but location servers SHOULD reject all PUT and DELETE requests for policy URIs that use the http: URI scheme. END One of my concerns behind wanting this general SHOULD is that there's no assurance that an http: URI will stay confined to the local network that is being relied upon to secure it. Thanks, --David -Original Message- From: Richard Barnes [mailto:rbar...@bbn.com] Sent: Tuesday, November 08, 2011 9:43 PM To: Black, David Cc: martin.thom...@andrew.com; james.winterbot...@andrew.com; hannes.tschofe...@gmx.net; gen- a...@ietf.org; ietf@ietf.org; rjspa...@nostrum.com; geop...@ietf.org Subject: Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02 Hi David, The penalty for getting a quick response for the first time is that the second response takes longer :) Inline. - The additional text in section 3.1 stating that the policy URI is a shared secret with a forward reference to the security considerations section removes the surprise factor. - The additional text on URI unpredictability in section 7.2 recommending a combination of 32 bits of entropy with rate limiting provides concrete guidance to implementers. Thanks, we'll note those changes for the RFC editor (or for a new revision, if our AD prefers). That leaves the issue of confidentiality and integrity requirements in section 7.2: Alternatively, changing required to REQUIRED in the following sentence in Section 7.2 may suffice, although integrity is not mentioned in this sentence: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. I like this phrasing. I'm not sure it's quite REQUIRED (following the MUST implement / MAY use pattern of BCP 61), but I would go for a strong SHOULD. The underlying LCP protocols already guarantee the MUST implement. Suggested text: Section 7.2 OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. The reason for going beyond BCP 61 is that BCP 61 concerns protocols in general, but this is a specific case with additional security requirements because a policy URI is a shared secret. If a policy URI is sent without confidentiality, a likely result is that the policy URI is still shared, but is no longer sufficiently secret (oops). This is particularly dangerous if there are no additional authorization checks on the PUT or DELETE methods for the policy URI, but it's probably ok in some situations if only the GET method is allowed (e.g., policy creation and update are handled via some other means such as a secure web portal). For that
Gen-ART review of draft-ietf-geopriv-policy-uri-02
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-geopriv-policy-uri-02 Reviewer: David L. Black Review Date: October 21, 2011 IETF LC End Date: October 25, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies policy URIs for management of privacy policy for location information obtained and maintained by Location Configuration Protocols (LCPs). The draft is clear and well written. The open issues concern the security consequences of the shared secret nature of policy URIs - the authorization model is that a policy URI is a shared secret between the location provider and the client whose location is involved, and hence presentation of the URI is sufficient authorization for its use, as an unauthorized entity will not know and cannot guess the URI. [1] This first turns up as an editorial issue in Section 3: Knowledge of the policy URI can be considered adequate evidence of authorization. That sentence should be expanded to explain why, because this is not the case for URIs in general. The explanation is that a policy URI is constructed to be very hard to predict, and functions as a shared secret (e.g., confidentiality protection is required in all protocols that transmit a policy URI). There are a couple of Security Considerations (Section 7) aspects that should be strengthened because a policy URI is a shared secret. [2] The first paragraph of section 7.1 is descriptive: Each LCP ensures integrity and confidentiality through different means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). These measures ensure that a policy URI is conveyed to the client without modification or interception. The paragraph ought to also be prescriptive and include possible future protocols that may use policy URIs - adding a sentence like the following would help: All LCPs that use policy URIs MUST provide confidentiality and integrity for policy URIs sufficient to ensure that a policy URI is conveyed to the client without modification or interception. Alternatively, changing required to REQUIRED in the following sentence in Section 7.2 may suffice, although integrity is not mentioned in this sentence: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. [3} The unpredictability requirements are vague: o The Location Server MUST ensure that the URI cannot be easily predicted. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of random entropy increases the difficulty of guessing a policy URI. Something needs to be stated about how much random entropy is required (e.g., 8 bits is probably not enough ;-) ). Nits: I found a number of acronyms that should be expanded on first use, e.g., LIS, LS, and HELD. idnits 2.12.2 did not 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-geopriv-policy-uri-02
Hi Richard, Thanks for the quick response. Two of the three proposed changes are fine with me: - The additional text in section 3.1 stating that the policy URI is a shared secret with a forward reference to the security considerations section removes the surprise factor. - The additional text on URI unpredictability in section 7.2 recommending a combination of 32 bits of entropy with rate limiting provides concrete guidance to implementers. That leaves the issue of confidentiality and integrity requirements in section 7.2: Alternatively, changing required to REQUIRED in the following sentence in Section 7.2 may suffice, although integrity is not mentioned in this sentence: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. I like this phrasing. I'm not sure it's quite REQUIRED (following the MUST implement / MAY use pattern of BCP 61), but I would go for a strong SHOULD. The underlying LCP protocols already guarantee the MUST implement. Suggested text: Section 7.2 OLD: Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. NEW: Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource. The reason for going beyond BCP 61 is that BCP 61 concerns protocols in general, but this is a specific case with additional security requirements because a policy URI is a shared secret. If a policy URI is sent without confidentiality, a likely result is that the policy URI is still shared, but is no longer sufficiently secret (oops). This is particularly dangerous if there are no additional authorization checks on the PUT or DELETE methods for the policy URI, but it's probably ok in some situations if only the GET method is allowed (e.g., policy creation and update are handled via some other means such as a secure web portal). For that reason, the proposed SHOULD requirement would be ok with me if a couple of things were added: (i) If an LCP sends a policy URI without confidentiality protection, then the LIS or LS MUST reject the PUT and DELETE methods for that URI. (ii) The PUT and DELETE methods SHOULD NOT be supported for policy URIs that use the http: URI scheme (in contrast to the https: URI scheme). For (i) it'd also be useful to note that the current LCPs never send a policy URI without confidentiality protection in connection with this (already stated in 7.1, but ought to be connected to (i) if that text winds up in a different section). For (ii), I'm not sure what is envisioned by the final sentence in section 7.1: If other means of protection are available, an http: URI MAY be used. What sorts of other means of protection were the underlying motivation? Those other means of protection would be the reason for (ii) being a SHOULD instead of a MUST. Thanks, --David -Original Message- From: Richard L. Barnes [mailto:rbar...@bbn.com] Sent: Saturday, October 22, 2011 11:19 AM To: Black, David Cc: martin.thom...@andrew.com; james.winterbot...@andrew.com; hannes.tschofe...@gmx.net; gen- a...@ietf.org; ietf@ietf.org; rjspa...@nostrum.com Subject: Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02 Hi David, Thanks for your review. Glad to provide clarification on these points. Responses inline below. Let me know if these address your concerns. --Richard This draft specifies policy URIs for management of privacy policy for location information obtained and maintained by Location Configuration Protocols (LCPs). The draft is clear and well written. Thanks! [1] This first turns up as an editorial issue in Section 3: Knowledge of the policy URI can be considered adequate evidence of authorization. That sentence should be expanded to explain why, because this is not the case for URIs in general. The explanation is that a policy URI is constructed to be very hard to predict, and functions as a shared secret (e.g., confidentiality protection is required in all protocols that transmit a policy URI). There are a couple of Security Considerations (Section 7) aspects that should be strengthened because a policy URI is a shared secret. I definitely appreciate that this could be surprising in Section 3, but since this section is mainly dealing with how the server makes access control decisions, I'm inclined to address this mainly with a forward reference to the Security Considerations. Suggested text: Section 3.1 OLD: Knowledge of the policy URI can be considered adequate evidence of authorization.
Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09
The Gen-ART review of the -08 version raised two significant open issues. I will defer to the DNS experts in the INT area to determine whether the changes in the -09 version resolve the issues around the format of the service name in the DNS SRV records [1], although based on IESG Evaluation Record, this issue does not appear to have been resolved, and I strongly recommend a DNS Directorate review of this draft. The -09 version of this draft resolves the UDP issue [2]. I noticed one additional minor issue: Due to the change in primary service name from _nfs4 to _nfs, something should be said about the applicability of this draft to versions of NFS other than v4 (e.g., v3). Here's a suggestion for a change in Section 3: OLD: The Service name is _nfs._domainroot. The Protocol as of this writing could be either _tcp or _sctp; version 4 NFS is not defined over UDP. Other transport protocols could be defined in the future, and SRV records that advertise domain root file services with other transport protocols would use the same Service name. The Target fields give the domain names of the NFS servers that export filesystems for the domain's root. An NFS client may then interpret any of the exported root filesystems as the filesystem published by the organization with the given domain name. NEW The Service name is _nfs._domainroot. The Protocol as of this writing could be either _tcp or _sctp; version 4 NFS is not defined over UDP. Other transport protocols could be defined in the future, and SRV records that advertise domain root file services with other transport protocols would use the same Service name. The Target fields give the domain names of the NFS servers that export filesystems for the domain's root. An NFS client may then interpret any of the exported root filesystems as the filesystem published by the organization with the given domain name. The domain root service is not useful for NFS versions prior to v4, as the fs_locations attribute was introduced in NFSv4 (see Section 2). The _nfs. Service name prefix is not limited to NFSv4; it is possible to use that prefix to define additional DNS SRV records for services that are also applicable to other versions of NFS (e.g., NFSv3 [RFC1813]). In addition, an informative reference to RFC 1813 should be added . Thanks, --David -Original Message- From: Black, David Sent: Friday, September 23, 2011 3:20 PM To: everh...@netapp.com; and...@netapp.com; jiayi...@google.com; gen-...@ietf.org; ietf Cc: Black, David; nf...@ietf.org; Brian Pawlowski; Spencer Shepler; David Harrington Subject: Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08 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-nfsv4-federated-fs-dns-srv-namespace-08 Reviewer: David L. Black Review Date: September 23, 2011 IETF LC End Date: September 23, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies the use of DNS to locate the root of a federated filesystem namespace based on the fs_locations functionality in NFSv4. I have two significant open issues: [1] There has been an extensive Last Call discussion of this draft, focusing on the use of a composite two-component service name in DNS SRV records, and the apparent incompatibility of that format with RFC 2782. This discussion has surfaced a proposed resolution in the form of unitary single-level service name specified without a port number. It is *vital* that this proposed resolution be reviewed by DNS experts (probably the DNS directorate) for consistency with DNS as currently specified and deployed. Another IETF Last Call may be appropriate, as this change has a significant impact on this draft, involving a serious rewrite of the portion of Section 4.2 that discusses the possible use of more than two components in a service name and presents a three-component example. [2] While NFSv4.1 (RFC 5661) is restricted to TCP, this draft also references NFSv4.0 (RFC 3530) as applicable, and the latter is defined over both UDP and TCP. Unfortunately, this draft is written as if TCP is the only transport protocol for NFS - that's not the case for NFSv4.0, so either this draft needs to say something about use with NFSv4.0 over UDP, or needs to explicitly prohibit use of this DNS SRV record with NFS over UDP. If the former approach is pursued, RFC 5405 on Unicast UDP Usage Guidelines for Application Designers is an important consideration in writing that text and RFC 5405 should be added as an informative reference. idnits 2.12.12 ran clean. Thanks, --David
Gen-ART review of draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
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-nfsv4-federated-fs-dns-srv-namespace-08 Reviewer: David L. Black Review Date: September 23, 2011 IETF LC End Date: September 23, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies the use of DNS to locate the root of a federated filesystem namespace based on the fs_locations functionality in NFSv4. I have two significant open issues: [1] There has been an extensive Last Call discussion of this draft, focusing on the use of a composite two-component service name in DNS SRV records, and the apparent incompatibility of that format with RFC 2782. This discussion has surfaced a proposed resolution in the form of unitary single-level service name specified without a port number. It is *vital* that this proposed resolution be reviewed by DNS experts (probably the DNS directorate) for consistency with DNS as currently specified and deployed. Another IETF Last Call may be appropriate, as this change has a significant impact on this draft, involving a serious rewrite of the portion of Section 4.2 that discusses the possible use of more than two components in a service name and presents a three-component example. [2] While NFSv4.1 (RFC 5661) is restricted to TCP, this draft also references NFSv4.0 (RFC 3530) as applicable, and the latter is defined over both UDP and TCP. Unfortunately, this draft is written as if TCP is the only transport protocol for NFS - that's not the case for NFSv4.0, so either this draft needs to say something about use with NFSv4.0 over UDP, or needs to explicitly prohibit use of this DNS SRV record with NFS over UDP. If the former approach is pursued, RFC 5405 on Unicast UDP Usage Guidelines for Application Designers is an important consideration in writing that text and RFC 5405 should be added as an informative reference. idnits 2.12.12 ran clean. 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-krb-wg-otp-preauth-19
The -19 version of this draft resolves the issues raised by the Gen-ART review of the -18 version, although issue [2] on registering the URIs has a couple of nits: - IANA also found issue [2] and IANA will need to acknowledge that the -19 version of this draft resolves this registration issue to IANA's satisfaction (the text in the -19 version should be sufficient). - It is unclear to me whether the PSKC registry used to resolve issue [2] is appropriate, but this topic has been discussed in the WG, and hence I prefer to defer this topic to the WG and the responsible Security AD. Thanks, --David -Original Message- From: Black, David Sent: Wednesday, August 24, 2011 8:46 PM To: Richards, Gareth; gen-...@ietf.org; ietf Cc: Black, David; ietf-krb...@lists.anl.gov; Sam Hartman; Stephen Farrell Subject: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 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-krb-wg-otp-preauth-18 Reviewer: David L. Black Review Date: August 24, 2011 IETF LC End Date: August 29, 2011 Summary: This draft is on the right track but has open issues, described in the review. This is a tightly written draft on one-time-password token-based preauthentication for Kerberos. The text does a good job of tightly specifying the algorithms and protocol steps; the resulting text is a bit dense to read, but provides the necessary precision for implementation. Disclaimer - the draft author and this reviewer work for different organizations in the same company (EMC). I found two open issues, both of which are relatively minor: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. I also found a couple of minor nits: In Section 1.1, please expand the FAST acronym on first use. In section 2.4, the following sentence is potentially confusing: For example, event-based tokens may drift since the counter on the token is incremented every time the token is used but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift. The confusion arises because the resync mechanism described in that section causes the client to use the next token value. By itself, that won't help when an event based has gotten ahead of the server; using the next value only puts the token further ahead. Similarly, by itself, this mechanism does not help if the token clock has drifted ahead of the server clock, but does help if the token clock has drifted behind. A little more explanation of what the server can do to take advantage of this mechanism (e.g., how to deal with an event-based token that is ahead of the server) would reduce the confusion. idnits 2.12.12 generated a bunch of warnings, none of which require any change to the draft. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953
RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
I believe that the WG consensus here was that this security issue only applies if the identity of the KDC has not been verified. How about the following updated version of the paragraph? Therefore, unless the identity of the KDC has been verified, anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security considerations should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. That works for me, as the use of SHALL NOT is clear and explicit. Thanks, --David -Original Message- From: Richards, Gareth Sent: Friday, August 26, 2011 6:56 AM To: hartmans-i...@mit.edu; Black, David Cc: gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; stephen.farr...@cs.tcd.ie Subject: RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. I believe that the WG consensus here was that this security issue only applies if the identity of the KDC has not been verified. How about the following updated version of the paragraph? Therefore, unless the identity of the KDC has been verified, anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security considerations should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. --Gareth ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search window and the system in the ID allows the client to send an additional value to help the server do this. This is just as described in RFC4226. How about the following clarification text: Methods to recover from this type of situation are OTP algorithm specific but may involve the client sending a sequence of OTP values to allow the server to further validate the correct position in its search window (see section 7.4 of [RFC4226] for an example). That new text is fine. My primary concern with the existing text is that the server has to do something like this for all the cases except when the clock in a clock-based token is slightly slow, but the existing text doesn't indicate that such server action may be needed. The proposed new text does so, and the reference to section 7.4 of RFC 4226 is a good addition that makes the point clear. Thanks, --David -Original Message- From: Richards, Gareth Sent: Friday, August 26, 2011 10:45 AM To: h...@jpl.nasa.gov Cc: Black, David; ietf@ietf.org; hartmans-i...@mit.edu; ietf-krb...@lists.anl.gov Subject: RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 In section 2.4, the following sentence is potentially confusing: For example, event-based tokens may drift since the counter on the token is incremented every time the token is used but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift. The confusion arises because the resync mechanism described in that section causes the client to use the next token value. By itself, that won't help when an event based has gotten ahead of the server; using the next value only puts the token further ahead. Similarly, by itself, this mechanism does not help if the token clock has drifted ahead of the server clock, but does help if the token clock has drifted behind. A little more explanation of what the server can do to take advantage of this mechanism (e.g., how to deal with an event-based token that is ahead of the server) would reduce the confusion. Possibly there is something in RFC4226, section 7.4 which could be referenced or re-used? It seems to assume that the server itself knows the token seed, which may not be a valid assumption, so perhaps not. Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search window and the system in the ID allows the client to send an additional value to help the server do this. This is just as described in RFC4226. How about the following clarification text: Methods to recover from this type of situation are OTP algorithm specific but may involve the client sending a sequence of OTP values to allow the server to further validate the correct position in its search window (see section 7.4 of [RFC4226] for an example). --Gareth ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
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-krb-wg-otp-preauth-18 Reviewer: David L. Black Review Date: August 24, 2011 IETF LC End Date: August 29, 2011 Summary: This draft is on the right track but has open issues, described in the review. This is a tightly written draft on one-time-password token-based preauthentication for Kerberos. The text does a good job of tightly specifying the algorithms and protocol steps; the resulting text is a bit dense to read, but provides the necessary precision for implementation. Disclaimer - the draft author and this reviewer work for different organizations in the same company (EMC). I found two open issues, both of which are relatively minor: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. I also found a couple of minor nits: In Section 1.1, please expand the FAST acronym on first use. In section 2.4, the following sentence is potentially confusing: For example, event-based tokens may drift since the counter on the token is incremented every time the token is used but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift. The confusion arises because the resync mechanism described in that section causes the client to use the next token value. By itself, that won't help when an event based has gotten ahead of the server; using the next value only puts the token further ahead. Similarly, by itself, this mechanism does not help if the token clock has drifted ahead of the server clock, but does help if the token clock has drifted behind. A little more explanation of what the server can do to take advantage of this mechanism (e.g., how to deal with an event-based token that is ahead of the server) would reduce the confusion. idnits 2.12.12 generated a bunch of warnings, none of which require any change to the draft. 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Hi Sam, Thanks for the quick response? I'll watch for the new text on anonymous PKINIT. Why should we require that alg-ids be registered URIs? That's not my concern - the existing first paragraph of the IANA considerations section in the draft requires IANA registration (or at least tries to) by pointing to the PSKC registry. My concern is that if this is going to be done, it needs to be done right (duh!), and the current text is insufficient. Please take the issue of whether to use IANA for this purpose up with Gareth and the WG. I have no problem with the IETF registering its algorithms there, or us encouraging people to register them there, but it's a URI. What purpose is served by forcing registration? Hmm - more than one URI for the same algorithm might cause interoperability problems. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Wednesday, August 24, 2011 10:04 PM To: Black, David Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; hartmans- i...@mit.edu; stephen.farr...@cs.tcd.ie Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 david.bl...@emc.com writes: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. Why should we require that alg-ids be registered URIs? I.E. what is wrong with me using http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread (or a tag URI if you like) for my OTP algorithm? I have no problem with the IETF registering its algorithms there, or us encouraging people to register them them, but it's a URI. What purpose is served by forcing registration? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Make that - Thanks for the quick response. (off-by-one key error ...) Thanks, --David -Original Message- From: Black, David Sent: Thursday, August 25, 2011 9:14 AM To: Sam Hartman Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; stephen.farr...@cs.tcd.ie; Black, David Subject: RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 Hi Sam, Thanks for the quick response? I'll watch for the new text on anonymous PKINIT. Why should we require that alg-ids be registered URIs? That's not my concern - the existing first paragraph of the IANA considerations section in the draft requires IANA registration (or at least tries to) by pointing to the PSKC registry. My concern is that if this is going to be done, it needs to be done right (duh!), and the current text is insufficient. Please take the issue of whether to use IANA for this purpose up with Gareth and the WG. I have no problem with the IETF registering its algorithms there, or us encouraging people to register them there, but it's a URI. What purpose is served by forcing registration? Hmm - more than one URI for the same algorithm might cause interoperability problems. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Wednesday, August 24, 2011 10:04 PM To: Black, David Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; hartmans- i...@mit.edu; stephen.farr...@cs.tcd.ie Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 david.bl...@emc.com writes: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. Why should we require that alg-ids be registered URIs? I.E. what is wrong with me using http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread (or a tag URI if you like) for my OTP algorithm? I have no problem with the IETF registering its algorithms there, or us encouraging people to register them them, but it's a URI. What purpose is served by forcing registration? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review ofdraft-ietf-mboned-mtrace-v2-08
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-mboned-mtrace-v2-08 Reviewer: David L. Black Review Date: 21 July 2011 IETF LC End Date: 19 July 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft describes version 2 of multicast traceroute. Major Issues: This review is late because it took me much longer than expected to work through this draft in order to figure out how the protocol works. While I believe that the protocol does work if correctly implemented, I don't believe that the protocol is effectively implementable from this draft, and hence significant work is required. The open issues fall into two primary areas: - Message Structure: Sections 4 and 5 are confusing. - Message Processing: The most important functionality of this protocol is the router processing of messages in Section 9. I found numerous problems there, including significant missing pieces of the specification (e.g., the material on when and how to generate Reply messages is incomplete). In addition there are some missing security considerations around traffic amplification. -- Message Structure -- The text in sections 4 and 5 is confusing. The problem starts with the following sentence in section 4.2: An mtrace2 message MUST contain exactly one Mtrace2 Query header. Because the mtrace2 Query header is not discussed until section 5, this sentence is easy to misread as a requirement for exactly one Mtrace2 Query TLV. It gets worse, because it turns out that the Mtrace2 Query header is actually the value[V] for the Query, Request and Reply TLVs. Hence, calling that a Query header is an invitation to confusion (e.g., where are the Request and Reply headers?). I suggest renaming the Mtrace2 Query header to Mtrace2 Trace header and then changing the above sentence to: An mtrace2 message MUST begin with a Query, Request or Reply TLV. The value for each of these TLVs is an Mtrace2 Trace Header (see section 5). These three TLVs MUST NOT be used in any position other than the beginning of a message. That is not easy to figure out from the current text. 5. Mtrace2 Query Header What's the maximum size of the UDP packet? This is important because there's text in Section 9 on that depends on whether another TLV fits into the message or not. There needs to be a minimum size, as nothing will work if there isn't room for at least one standard response block after the header. How does one figure out whether the addresses in the Mtrace2 Query Header are IPv4 or IPv6? I suspect that at least one of the multicast address and source address needs to be valid (i.e., not all 1's for IPv4, not :: for IPv6). That should be stated, along with what happens when both addresses are invalid. State that the client address must be valid (not all 1's for IPv4, not :: for IPv6). Add the 24 bits of TLV to the packet structure diagrams in sections 5, 6, 7 and 8. Sections 6 and 7 - The IPv4 and IPv6 response blocks use the same TLV code (4), but have different contents and lengths. How does the receiver determine which response block is present for TLV code 4? Section 8 Mtrace2 Augmented Response Block The augmented response block is always appended to mtrace2 TLV header (0x04). No, definitely not. Section 4.2 says that the mtrace2 TLV code for an augmented response block is 5, not 4. The following would be better: The augmented response block uses TLV code 5 and always comes after a standard response block TLV (code 4). -- Message Processing -- Section 9 is confusing and incomplete. This is the most important functionality in the document, and it needs to be clear to the reader. I'm having a very hard time figuring out exactly what the router is supposed to do, and I found a number of things that are clearly wrong. It is not sufficient to just fix the things noted in this review - Section 9 needs to be clear and cogent about exactly what the router does for each received message so that code can be written from it. Section 9.1.1 Packet Verification If the router determines that it is not the proper last-hop router, or it cannot make that determination, it does one of two things depending if the Query was received via multicast or unicast. If the Query was received via multicast, then it MUST be silently dropped. If it was received via unicast, a forwarding code of WRONG_LAST_HOP is noted and processing continues as in Section 9.2. The last sentence has a number of problems: - It needs to say that the TLV type in the first TLV is changed from 1 to 2, - Section 9.2 requires that there be a response block, but the Query message doesn't have one. - Section 9.2 will
RE: tsv-dir review of draft-ietf-mptcp-congestion-05
Costin, The proposed -06 version sufficiently clarifies my one open issue. I agree that the NSDI paper is an important citation and did not intend to suggest that it be removed. In addition, your decision to not cite RFC 3124 is ok with me. Thank you for responding to the review. 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.com Mobile: +1 (978) 394-7754 -Original Message- From: Costin Raiciu [mailto:c.rai...@cs.ucl.ac.uk] Sent: Tuesday, July 19, 2011 12:35 PM To: Black, David Cc: tsv-dir; tsv-area; ietf; m.handley; d.wischik; multipathtcp Subject: Re: tsv-dir review of draft-ietf-mptcp-congestion-05 Hi David, Thank you for your review. Major: I have one open issue - the first two goals (in the Introduction) are to have multipath TCP connections behave somewhat like single-path connections in terms of effects on (fairness to) other traffic. The algorithm specified accomplishes this solely by coupling the additive increase functionality across the flows, but allowing each flow to react to drops and congestion separately (no decrease coupling). The draft does not explain why increase coupling alone is sufficient to achieve these goals or what compromise to the goals results from only coupling increases. Our proposal fully achieves goals 1 and 2 - fairness to single path tcp and improve throughput. It does not fully achieve goal three - balancing congestion; fully achieving goal 3 is very difficult, and an explanation is attempted in section 5; a reference is given to the NSDI paper for further info. Section 5 is a good start on this discussion, but it's not clear about what compromises to the goals results from increase coupling only. Section 5 criticizes an alternative that couples both increases and decreases for failing to achieve Goal 1, but doesn't say what this approach achieves. At most a few additional sentences in Section 5 should suffice to address this concern, and Section 2 should be edited to align with the changes to Section 5. We have updated section 5 to make these points clear - they weren't clear enough before. Minor: While the [NSDI] paper is a fine place to reference work published in conferences and/or journals, RFC 3124 on the Congestion Manager is related IETF work and should be cited here as an Informative Reference. The congestion manager is indeed related work and should be cited in a research paper, but does not help understanding the congestion controller presented in this draft. We chose not to cite it explicitly. We chose to cite the NSDI paper because it describes in detail the design choices that shaped the algorithm, and it will help an interested reader understand more about the algorithm. The discussion section is itself a short high level summary of those decisions. We attach the new version of this draft to this email (we cannot post a new version online of the draft because the IETF submission cutoff date has passed). Could you please check the draft and see if the issues you raised have been clarified? We will post the draft as soon as submissions reopen after the IETF Thanks, Costin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-polk-local-emergency-rph-namespace-01
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-polk-local-emergency-rph-namespace-01 Reviewer: David L. Black Review Date: July 12, 2011 IETF LC End Date: July 13, 2011 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft defines a SIP Resource Priority header namespace, esnet, for use in providing preferential treatment to emergency calls (e.g., from on-scene responders). This field is an addition to rather than a replacement for existing notions of priority in the SIP Resource Priority header. Section 2 explains why this was done, but section 2 is a bit sloppy and imprecise. Some level of imprecision is necessary as this draft deliberately does not specify how this header namespace is used to provide preferential treatment. Nonetheless, the following two items could be improved in Section 2's discussion: 1) Explain the reason for including the second paragraph, the paragraph that references RFC 4412's discouragement of modification of priorities within an administrative domain. That paragraph's not connected to the rest of section 2. 2) Explicitly state that one of the anticipated uses of the priorities in the esnet namespace is to override the ordinary priorities found elsewhere in the Resource Priority header. Small nit: There's an extraneous to in the first line of section 3: The esnet namespace should not to be considered generic for all ^^ idnits 2.12.12 found a few formatting problems: == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages == The copyright year in the IETF Trust and authors Copyright Line does not match the current year 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ietf-mptcp-congestion-05
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC: tsv-...@ietf.org if you reply to or forward this review. Summary: This draft is on the right track but has open issues, described in the review. Comments: This draft specifies the congestion control modifications for multi-path TCP. Major: I have one open issue - the first two goals (in the Introduction) are to have multipath TCP connections behave somewhat like single-path connections in terms of effects on (fairness to) other traffic. The algorithm specified accomplishes this solely by coupling the additive increase functionality across the flows, but allowing each flow to react to drops and congestion separately (no decrease coupling). The draft does not explain why increase coupling along is sufficient to achieve these goals or what compromise to the goals results from only coupling increases. Section 5 is a good start on this discussion, but it's not clear about what compromises to the goals results from increase coupling only. Section 5 criticizes an alternative that couples both increases and decreases for failing to achieve Goal 1, but doesn't say what this approach achieves. At most a few additional sentences in Section 5 should suffice to address this concern, and Section 2 should be edited to align with the changes to Section 5. Minor: While the [NSDI] paper is a fine place to reference work published in conferences and/or journals, RFC 3124 on the Congestion Manager is related IETF work and should be cited here as an Informative Reference. idnits 2.12.12 didn't find any nits. 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.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pwe3-fc-encap-14.txt (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard
This IETF draft contains normative references to three Fibre Channel standards that are developed by INCITS Technical Committee T11 (www.t11.org) - FC-BB-6, FC-FS-2 and FC-SP. FC-BB-6 is under active development at T11, and hence its latest working draft (revision 1.02) is publicly available from T11's web site. As the other two references are to published standards, their availability is restricted. In both cases, the material relied upon by this IETF draft has not been changed by follow-on standards work, so the latest drafts of T11's follow-on standards efforts (FC-FS-3 and FC-SP-2) can be used for reference. If anyone needs a copy of FC-FS-2 and/or FC-SP in order to review this IETF draft, please send me an email - I have been authorized by T11 to provide copies of these standards for the personal use of IETF participants in IETF activity related to this draft. 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.com Mobile: +1 (978) 394-7754 -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, February 07, 2011 11:13 AM To: IETF-Announce Cc: p...@ietf.org Subject: Last Call: draft-ietf-pwe3-fc-encap-14.txt (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks' draft-ietf-pwe3-fc-encap-14.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: tsv-dir review of draft-ietf-storm-ifcp-ipn133-updates-02
Joe, Many thanks for reviewing the draft. The requested changes look reasonable, with one clarification - protocol number 133 was used for a pre-standard version of FCIP, not iFCP . Thanks, --David -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Tuesday, September 21, 2010 2:02 PM To: draft-ietf-storm-ifcp-ipn133-upda...@ietf.org; Black, David; david.peter...@brocade.com Cc: IETF discussion list; TSV Dir Subject: tsv-dir review of draft-ietf-storm-ifcp-ipn133-updates-02 Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document updates the specification for iFCP over TCP by deprecating address translation mode. There are no significant transport issues raised by this document. There are some clarifications that seem necessary, as noted below. Joe -- The title implies that there is a 133rd version of IP (i.e., IPv133). It might be more useful to focus on the changes it proposes: Deprecating Translation Mode for iFCP over TCP Overall, the prominence of the protocol 133 issue should be reduced, as it is not specific to the changes proposed by this document. This includes: - removing the last sentence of the abstract - removing the last paragraph of Section 1 - change section 4 as follows: section heading: Using iFCP over TCP section content: Explain that iFCP runs as a payload inside TCP using dynamic port numbers coordinated out-of-band. Add that IP protocol 133 is not used for iFCP, but was used for a pre-release version that did run directly over IP, was deployed, and may still be in use. (do not discuss IANA actions; that's for Sec 6, and since removal is not requested, it would not occur anyway) If references to Protocol 133 remain, such references should be IPv6-friendly and should be more clear that they are inside IP (rather than versions of IP), i.e., IP Protocol/Next Header field with a value of 133. Sec 6 should more clearly state that the IANA entry for IP protocol 133 be updated to note that it is NOT used by iFCP. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-hip-via-01
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 comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes the addition of source routing and route tracing to HIP. It is proposed for Experimental status, which seems appropriate, especially for source routing. The draft's in good shape - idnits 2.12.04 found a few minor nits: == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) - Copy the correct boilerplate. == Outdated reference: A later version (-06) exists of draft-ietf-hip-bone-04 == Outdated reference: A later version (-08) exists of draft-ietf-p2psip-base-07 - These are only worth updating if a new version of the draft is needed for other reasons. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_da...@emc.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
