Gen-ART review of draft-krishnan-v6ops-teredo-update-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 comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This is a reasonably well written short draft that injects randomness into Teredo IPv6 address generation and deprecates the Teredo cone bit. I found a few nits: (1) The first nit is right at the start of the draft (!). This draft is clearly intended to update RFC 4380, but Updates: 4380 is missing from the draft header on p.1. Please add that. (2) Section 3.2 on p.6 uses the acronyms RA and RS - they need to be expanded on first use. (3) The first paragraph in the Security Considerations section (5) states the goal of comparable address prediction resistance (security) wrt a host directly attached to an untrusted Internet link, but nothing in the Security Considerations section indicates how close the technique in this draft comes to achieving that goal. I suggest adding a short discussion of how 13 random bits compares with the level of randomness that can be expected from native IPv6 address assignment mechanisms. (4) idnits 2.12.04 found four more nits that should be easy to address: == 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/) == No 'Intended status' indicated for this document; assuming Proposed Standard == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-tunnel-security-concerns-01 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
RE: OpsDir review of draft-zimmermann-avt-zrtp-17
Phil, The draft is well written - it was a pleasure to review it. The added text on automated systems conveys the warning well (e.g., worse than useless and absolutely unsafe to rely on a robot voice), thanks for adding it. On backup/restore, I would elaborate somewhat on this added text at the end of Section 15.1: Unlike the long-lived non-updated key material used by SSH, the dynamically updated shared secrets of ZRTP may lose sync if traditional backup/restore mechanisms are used. This is mitigated by ZRTP's built-in cache backup logic. (Section 4.6.1) As I understand Section 4.6.1, the mitigation is partial, because after a backup, once two calls have been made to the same party, the backed-up secrets for that party no longer work. In the above text, I would insert partially before mitigated and explain that if 2 or more calls to the same party are made after the secrets for that party are backed up, then restoring the secrets for that party does not do anything useful because both rs1 and rs2 will have been changed subsequent to that backup. It might be worth mentioning that it's a deliberate protocol design decision to avoid high-value generated secrets like the long-lived non-updated key material used by SSH (see benefits discussed in the last paragraph of Section 3.1.2), and this restriction on secret backup/restore is a consequence. Thanks, --David -Original Message- From: Philip Zimmermann [mailto:p...@mit.edu] Sent: Saturday, April 24, 2010 5:11 PM To: Black, David Cc: ops-...@ietf.org; alan.b.johns...@gmail.com; j...@callas.org; ietf@ietf.org; rjspa...@nostrum.com; gonzalo.camari...@ericsson.com Subject: Re: OpsDir review of draft-zimmermann-avt-zrtp-17 David, thank you for reviewing our draft. Your suggestions were helpful. It was a pleasure talking with you on the phone. I'm glad we had a chance to discuss the points you raised. We addressed all the issues you raised in the next draft, draft 18. Regards, Phil On Mar 29, 2010, at 6:43 PM, black_da...@emc.com black_da...@emc.com wrote: I have performed an Operations Directorate review of draft-zimmermann-avt-zrtp-17 Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- This draft specifies a proposed protocol for keying SRTP. It is being published as an Informational RFC because the IETF chose a different proposal (draft-ietf-avt-dtls-srtp) to publish as Proposed Standard. If this draft had been proposed for standards track publication, I would have characterized the automated system concern and the inability to backup secrets as open issues that merited discussion in the draft - both are tagged with [*]. As this draft will be published as informational, a lower standard of review may apply, and I leave it to the authors' judgment as to what changes should be made. The operational aspects of the protocol are reasonably good - the protocol goes to a significant effort to avoid having to pre-provision and maintain authentication material by using an ephemeral DH exchange that is run from scratch on the first call between a pair of participants. The protocol also adapts an SSH-like leap of faith model to protect subsequent interactions among the same parties. By itself, an unauthenticated DH exchange can easily be subverted by a man-in-the-middle (MiTM) attack - the protocol defends against this by generating an identification of the protocol run (SAS) at each end that can then be compared by the participants reading the SAS to each other. A successful MiTM attack will cause different SAS identifiers to be generated at the two call endpoints. [*] The draft asserts that it is very difficult for an MiTM attacker to change the SAS on the fly in audio. There is an obvious exception to this difficulty - if one of the parties on the call is an automated system, its voice response reading the secret is likely to have a predictable structure, and its vocalizations are likely to be easily recordable and/or otherwise forgeable by an MiTM. This should be noted in the security considerations section after the paragraph on voice spoofing at the bottom of p.99, with a strong
OpsDir review of draft-zimmermann-avt-zrtp-17
I have performed an Operations Directorate review of draft-zimmermann-avt-zrtp-17 Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- This draft specifies a proposed protocol for keying SRTP. It is being published as an Informational RFC because the IETF chose a different proposal (draft-ietf-avt-dtls-srtp) to publish as Proposed Standard. If this draft had been proposed for standards track publication, I would have characterized the automated system concern and the inability to backup secrets as open issues that merited discussion in the draft - both are tagged with [*]. As this draft will be published as informational, a lower standard of review may apply, and I leave it to the authors' judgment as to what changes should be made. The operational aspects of the protocol are reasonably good - the protocol goes to a significant effort to avoid having to pre-provision and maintain authentication material by using an ephemeral DH exchange that is run from scratch on the first call between a pair of participants. The protocol also adapts an SSH-like leap of faith model to protect subsequent interactions among the same parties. By itself, an unauthenticated DH exchange can easily be subverted by a man-in-the-middle (MiTM) attack - the protocol defends against this by generating an identification of the protocol run (SAS) at each end that can then be compared by the participants reading the SAS to each other. A successful MiTM attack will cause different SAS identifiers to be generated at the two call endpoints. [*] The draft asserts that it is very difficult for an MiTM attacker to change the SAS on the fly in audio. There is an obvious exception to this difficulty - if one of the parties on the call is an automated system, its voice response reading the secret is likely to have a predictable structure, and its vocalizations are likely to be easily recordable and/or otherwise forgeable by an MiTM. This should be noted in the security considerations section after the paragraph on voice spoofing at the bottom of p.99, with a strong recommendation that credentials be provisioned at the automated system sufficient to use either the 7.2 signature technique or 8.1.1 integrity protection technique, and that those techniques always be used with pre-recorded or synthesized voice. If the first call between two parties does not include voice confirmation of the SAS that instance of the protocol is MiTM-able. The Introduction glosses over this by using the phrases reasonable authentication against a MiTM attack and key continuity properties analogous to SSH. While I believe both phrases are correct, the Introduction should also point out that the first call with no prior shared key material is MiTM-able, as is the case for SSH, as not every reader of this draft can be expected to be familiar with that aspect of SSH security. [*] Unlike SSH, ZRTP updates the shared secret used to block MiTM attacks on every call. This makes it impossible to backup and restore that secret because the backup becomes invalid on next use of the secret. If a phone has to be hard reset (not unheard-of), it loses all of its secrets unless a backup is conducted immediately prior to the hard reset (not always possible as the failure requiring a hard reset may block backup). This should to be pointed out as a counterpoint in the Security Considerations discussion of the requirements for protecting long-lived non-updated shared secrets, as used by SSH. This ongoing shared secret update may increase the protocol's practical vulnerability to MiTM attacks because the participants cannot distinguish presence of an MiTM attacker from one party having lost its secret (or even the most recent update to the secret - a soft reset of the phone at exactly the wrong moment may cause this). If the parties assume that the most common reason for setup failure is that a secret has been lost, an MiTM attacker inserts can mimic that by inserting herself in a call, thereby causing both sides to believe that the secret has been lost. She then attacks the resulting initial run of the protocol - if voice confirmation of the secret
5378 - one purpose
John, If I'm correct and transfer of a Standard to another SDO is really a non-issue, then perhaps the question of what problem(s) 5378 was intended to solve becomes more relevant... or perhaps it does not. But, given the problems the 5378/5377 model has turned out to create, eliminating one of the major claimed reasons for creating that model makes it much easier to consider just repealing the things and doing a small update to 3978/4748 to de-glitch them. My recollection of one of the major problems that 5378 was intended to solve is allowing use of text from IETF standards outside of the IETF. Two specific examples are: 1) Use of code from an RFC in an implementation. This often requires the ability to modify the code in some minor ways. 2) Use of text from an RFC in another standard. This is *not* transfer of the standard, but rather allowing use of the actual text in a different standard that does something similar. The pre-5378 copyright rules block both of these. The ipr WG spent a great deal of time discussing code use, and whether to apply the same provisions to text (ultimately, the same provisions were not applied). I have personally been in a situation where an editor in another standards organization had to do a complete rewrite of a large quantity of text obtained from an RFC because the IETF could not grant copyright permission independent of whether the IETF wanted to grant that permission or not. Regardless of the mess that's been made for revisions of documents that used the old rules, I doubt that a de-glitch effort on 3978/4748 can address the two examples noted above, as both require additional permissions from authors that the IETF has not obtained in the past (and hence that the IETF does not have for documents created under past rules). 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.comMobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-ietf-nfsv4-pnfs-block-10
Christian, Thank you for doing this review. On the volume identification offset: - Section 2.2.1 (Volume Identification) specifies two methods for identifying a position on a disk: by positive offset starting at the beginning of the disk, and by negative offset starting at the end of the disk. The second method is limited to implementations where server and client have the same understanding of the disk size. This method could be generalized: If you defined an offset, positive or negative, to be in the context of the disk size as seen by the client, then you may potentially also support implementations where server and clients have a different understanding of the disk size. The authors may consider this. I would prefer not to do this. It's fairly easy to make a mistake in this environment that has the client looking in the wrong place for the volume identification, risking a false positive, and unpleasant results. Beyond this, removing the requirement that server and client have the same understanding of the disk size may create situations in which different clients have different ideas of the disk size; that seems like needless complexity, so all clients need to have the same understanding of disk size, and adding the server to that understanding is a small and reasonable step in pursuit of robustness. As Hannes has already pointed out, there's quite a bit of crash detection and recovery material in the main NFSv4.1 draft, including descriptions of how to recover layouts in general (layouts are among the resources that a client can reclaim during a grace period after server restart). Hence this draft only adds material specific to the block/volume layout. We'll add a sentence or two in order to explain this and point to the material in the main NFSv4.1 draft. We'll expand the first uses of the four acronyms. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 -Original Message- From: Christian Vogt [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 7:42 AM To: IETF Discussion Mailing List Cc: Black, David; fridella, stephen; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Review of draft-ietf-nfsv4-pnfs-block-10 I was asked by the IESG to review the pNFS Block/Volume Layout specification [draft-ietf-nfsv4-pnfs-block-10], and I am sharing my review on this list. The specification is overall in good shape and should proceed for publication soon. I do suggest addressing the following comments, though, before forwarding the document to the RFC Editor. Technical: - Section 2.2.1 (Volume Identification) specifies two methods for identifying a position on a disk: by positive offset starting at the beginning of the disk, and by negative offset starting at the end of the disk. The second method is limited to implementations where server and client have the same understanding of the disk size. This method could be generalized: If you defined an offset, positive or negative, to be in the context of the disk size as seen by the client, then you may potentially also support implementations where server and clients have a different understanding of the disk size. The authors may consider this. - Section 2.4 (Crash Recovery Issues) specifies recovery procedures that a client could initiate following a server crash. These procedures apply in one specific condition, which is defined at the beginning of the section (When the server crashes while the client holds a writable layout, and the client has written data to blocks covered by the layout, and the blocks are still in the PNFS_BLOCK_INVALID_DATA state, [then]...). The section should also consider other conditions. It may be sufficient to explain why only the described condition requires recovery. - Section 2.4 (Crash Recovery Issues) does not explain how a client detects a server crash. The section should briefly explain this. It may be sufficient to mention that crash detection is specified in a related document, or that it is implementation-specific. Editorial: - The specification uses undefined acronyms in a couple of places, including in the title. Those should be spelled out when mentioned the first time. Search for pNFS, SAN, XDR, LUN to find the relevant places in the specification. Best regards, - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Transport Area review of draft-ietf-nfsv4-minorversion1-26.txt
This is a combined Gen-ART and Transport Area review, hence the introductory boilerplate for both reviews follows: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 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 [EMAIL PROTECTED] if you reply to or forward this review. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nfsv4-minorversion1-26.txt Reviewer: David L. Black Review Date: 27 November 2008 IETF LC End Date: 27 November 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: In general, this is a well written draft and reasonably readable despite its length. The draft has had extensive review in the WG and there are multiple known interoperable implementations of much of its contents. As a result, this review focuses on clear exposition of requirements. I found one technical issue that must be addressed: Section 5.10 on character case for Unicode references a very old RFC (RFC 1345) and provides a case determination algorithm (substring match on CAPITAL or SMALL in a Unicode character name) that is wrong and potentially dangerously so. This section needs to be rewritten to reference a Unicode document that defines the notion of case for a particular version of Unicode. The good news is that everything needed to get this right is in Section 14's profiles of stringprep (Unicode 3.2 is referenced from Section 14 via RFC 3454), so a small rewrite of Section 5.10 to remove the case determination algorithm and direct the reader to Section 14 for all internationalization details will probably fix this. I would remove the reference to RFC 1345 as part of this. Minor Technical Items: The draft is a bit cavalier about use of lower case must and should. I found a number of these that arguably should be upper case, but nothing that struck me as crucial to change. Section 2.9.1 - at the end of the first sentence in the last paragraph, please add , as a consequence UDP by itself MUST NOT be used as an NFSv4.1 transport. This is clearly a consequence of the stated requirements, but one that is worth calling out explicitly. Section 2.10.1 - I was looking for at least a MUST support and possibly a MUST use requirement for sessions in this section and didn't see either requirement stated. At least MUST support needs to be added here. Section 2.10.8.1 - The connection cannot be hijacked by an attacker who connects to the client port prior to the intended server as is possible with NFSv4.0. I think that sentence is too strong, and that what was meant is that NFSv4.1 provides security measures (e.g., authentication) that enable this form of hijacking to be prevented. Section 2.10.9, 3rd paragraph - the input text as represented by the XDR encoded enumeration of type ssv_subkey4. That's a bit too terse. Changing enumeration -- enumeration value for that subkey would be clearer. p.80 after item 4. - If there is a reconfiguration event which results in the same network being assigned to servers where the eir_server_scope value is different, Should that be same network address rather than same network ? p.85 - The description of length4 is Describes LOCK lengths. The length4 type is used for a lot more than locks, so the description needs to be generalized. p.91, Section 3.3.15 - Change will be defined to are defined in the last sentence. p.103, Section 5.4 - Explain what the implementation implications are of the attribute class (per server vs. per FS vs. per FS object). Section 5.8.* and elsewhere - consider including the data type of the attribute in the name of the section that defines the attribute or in the text of that section. p 114, Section 5.8.2.30 - The last paragraph presumably refers to selection of the quota set that provides the contents of the quota_used attribute. That should be stated explicitly. p.117, middle of page - The dns_domain portion of the owner string is meant to be a DNS domain name. For example, [EMAIL PROTECTED] Change ietf.org to example.org. See ID-Checklist item 3.6 and RFC 2606. p.118, end of Section 5.9 - Add a MUST NOT requirement forbidding use of the nobody string to represent an actual owner principal. p.135, ACE4_SYNCHRONIZE - Explain what synchronized reads and writes are synchronized with/to. p.141, Section 6.3.1.1 - Add a bullet item indicating that retention may also block access otherwise allowed by ACLs with a
RE: Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt
Fernando, (1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead. Relevant portions of that draft should be reproduced or otherwise explained in Section 3.2. The reference to this I-D has been updated to the corresponding RFC. Thanks - please send the reference to the secretariat, because the I-D Tracker doesn't record the fact that this draft was published as an RFC. As part of doing this, please state whether trying v6 and v4 connections in parallel is a good idea or not and why. The document does not discuss alternative approaches, at it just documents this alternative reaction to soft errors, as implemented in a number of stacks. (FYI, the draft originally aimed at Std. Track, and discussed other alternative approaches for dealing with the problem of long delays between connection establishment attempts. Then we changed the draft category to Informational, to simply document this behavior. At that point, the discussion of parallel connections and other approaches was dropped). I don't think just ignoring this problem is acceptable, but a reference to a discussion of what can be done about it in that RFC or some other document should suffice. (2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a modified SYN when an RST is received in response to an ECN-setup SYN, and suggests that this mechanism is applicable to ICMP errors received in response to an ECN-setup SYN. This mechanism was specified in RFC 3168 because there were known deployed middleboxes with this problem-causing RST behavior, and the mechanism was necessary to deal with them. Are there any known middleboxes that send an ICMP error in response to a SYN that signals ECN capability? - If yes, state the specific ICMP error(s) that is(are) used and limit the recommendation to the actual error(s). - If no, remove this entire RFC 3168 discussion as speculative, or describe it as a possible response should this problem scenario ever arise in practice. I am particularly referring to firewalls, that can be configured to reject incoming connections with either RST segment, ICMP error messages, or silently. Would your comment be addressed if I incorporate a small paragraph to clarify this? The resulting text would read: --- cut here [RFC3168] states that a host that receives a RST in response to the transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. This is meant to deal with faulty middle-boxes that reject connections when a SYN segment has the ECE and CWR bits set. Given that this section describes a modification that processes ICMP error messages as hard errors when they are received for a connection in any of the non-synchronized states, systems implementing this behavior could resend the SYN segment with the ECE and CWR bits cleared when an ICMP error message is received in response to a SYN segment that had these bits set. This would address those scenarios in which a middle-box such as a firewall rejects incoming connection requests with an ICMP soft error simply because the ECE and CWR bits were set in the incoming SYN segment. cut here (Only the last paragraph was added). I see two problems: - I want to see the offending ICMP soft errors named as opposed to a general allowance being made for all soft errors. - I believe the concept in that last paragraph belongs before the Given that ... sentence. Try the following two paragraphs: [RFC3168] states that a host that receives a RST in response to the transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. This is meant to deal with faulty middle-boxes that reject connections when a SYN segment has the ECE and CWR bits set. Some faulty middle-boxes (e.g., firewalls) may reject connections with an ICMP soft error of XXX instead of an RST. Therefore a system that processes ICMP error messages as hard errors when they are received for a connection in any of the non-synchronized states, MAY respond to an XXX ICMP error message received in response to a SYN segment with the ECE and CWR bits set by retransmitting that SYN segment with those bits cleared instead of abandoning the connection. The actual ICMP error or errors need to be filled in to replace XXX above. (3) Section 5.3 describes a NAT behavior that causes a host TCP problem and then suggests changing the NAT to fix it. While that's a good idea in an ideal world (and needs to be stated in the draft), in practice, deployed NATs have to be dealt with as-is. In addition to recommending fixing the NAT, please discuss what could be done when the NAT cannot be fixed. There's not much that could be done. However, this would just break TCP simultaneous opens, that are unlikely. (As a matter of fact, there are
RE: FW: IETF copying conditions
Larry, Paul Hoffman wrote: Which SDOs that you participate in want to see other SDOs publishing *incompatible* versions of their protocols? Hi Paul, Of course none of the SDOs that I work with want to see incompatible versions. But this turns the issue on its head. Open source and open standards deal with the freedom to do things, even though we might discourage people to take us up on that offer of freedom. So with respect to IETF specifications, the open source and open standards objective is that the world is *free* to make compatible or incompatible versions of our specifications. (This is the philosophy that neither IETF nor Microsoft nor IBM, nor anyone else, is going to be the absolute God of acceptable software.) I'm sure that good people everywhere will cooperate to ensure that all good versions of our specifications are compatible, and cooperative people will be encouraged to remain compatible by virtue of the quality of our work. But if anyone, anywhere, for any reason, wants to take an IETF specification and modify it, open source requires that he be free to do so. I think requires is a stretch. There are a large number of non-IETF standards implemented in open source for which copyright does not permit arbitrary modifications, so I think requires is incorrect. Copyright provisions that do not grant derivative works rights and have distribution terms far less permissive than IETF's are common in other standards bodies, some of whom rely on charging money for copies of standards to fund their budgets. IETF has chosen not to charge for standards for many good reasons. Encouraging people who want to modify standards to talk to the people who developed the standards is a good idea, and to the extent that copyright terms encourage people to do so, that's beneficial. An example of the benefits of this sort of discussion is RFC 4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol (I'm an author). When I started working on this, my initial belief was that an IETF RFC and use of IANA-allocated values was highly unlikely (e.g., IKEv2 for FC does not run over IP) and I was pleasantly surprised that the IETF Security Area wanted to see the FC values and usage documented in an RFC. OTOH, of the various arguments made for use of RFC text, the one I'm most sympathetic to is documentation - code comments, manuals, online help, etc., where the ability to selectively quote from the RFC that is implemented can be very useful. This would need to be controlled, as blanket permission for arbitrary selective quoting can be dangerous - it's fairly easy to change a standard to be non-interoperable via selective quoting. For an (amusing) extreme example from another domain, see: http://www.legis.state.wi.us/senate/sen10/news/FrankensteinVeto.pdf While I doubt that anyone would ever resort to something that bizarre in quoting from an RFC, I hope the underlying concern is clear. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tcpm-tcp-soft-errors-08.txt Reviewer: David L. Black Review Date: 21 August 2008 IETF LC End Date: 26 August 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: This is a good draft reporting on problems encountered in practice with TCP's handling of ICMP errors and what has been done about them. This draft has received extensive discussion in the Transport Area, and I believe it is wise to defer to the Transport Area decision that this draft will not make any changes to the TCP standard. While the draft is in generally good shape, I did find three open issues: (1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead. Relevant portions of that draft should be reproduced or otherwise explained in Section 3.2. As part of doing this, please state whether trying v6 and v4 connections in parallel is a good idea or not and why. (2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a modified SYN when an RST is received in response to an ECN-setup SYN, and suggests that this mechanism is applicable to ICMP errors received in response to an ECN-setup SYN. This mechanism was specified in RFC 3168 because there were known deployed middleboxes with this problem-causing RST behavior, and the mechanism was necessary to deal with them. Are there any known middleboxes that send an ICMP error in response to a SYN that signals ECN capability? - If yes, state the specific ICMP error(s) that is(are) used and limit the recommendation to the actual error(s). - If no, remove this entire RFC 3168 discussion as speculative, or describe it as a possible response should this problem scenario ever arise in practice. (3) Section 5.3 describes a NAT behavior that causes a host TCP problem and then suggests changing the NAT to fix it. While that's a good idea in an ideal world (and needs to be stated in the draft), in practice, deployed NATs have to be dealt with as-is. In addition to recommending fixing the NAT, please discuss what could be done when the NAT cannot be fixed. Nits: Section 1 - reduce generality of this text. OLD: This document analyzes the fault recovery strategy of TCP [RFC0793], and the problems that may arise due to TCP's reaction to ICMP soft errors. NEW: This document analyzes problems that may arise due to TCP [RFC0793] fault recovery reactions to ICMP soft errors. It would be good to provide the text expansion of the codes in Figure 1, as was done in the text before the figure. In section 4, please provide the expansion of TCPM WG (TCP Maintenance Working Group). idnits 2.08.10 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 [EMAIL PROTECTED]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-avt-rtp-jpeg2000-beam-10.txt
Futemma-san, The proposed new version of the draft looks ok to me - it has dealt with all of the concerns in the Gen-ART review. I have one comment on the changes. The second paragraph of Section 8 now recommends clearing the saved mh_id (and I would think also the saved header) if the decoder detects an inconsistency between the header and payload. It would be useful to repeat that recommendation in Section 4.2 (so that all of the situations in which the receiver should clear saved information are explained in that section) with a recommendation to see Section 8 for more explanation. Thanks, --David -Original Message- From: Satoshi Futemma [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 11:16 PM To: Black, David Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt Dear, An attachment is the changes of draft-ietf-avt-rtp-jpeg2000-beam we propose. The changes are: - The abstract became more clear and added RFC editor note. - added the algorithm to calculate priority value of progression based order in Section 3.2 - the media type video/jpeg2000 eppeared in Section 5 and Section 7. - Changed the last sentence in 8. Security Section If they are ok, I will submit the document. Best Regards, Futemma [EMAIL PROTECTED] wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-avt-rtp-jpeg2000-beam-10.txt Reviewer: David Black Review Date: 16 June 2008 IESG Telechat date: 19 June 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The authors have only partially addressed the open issues noted in the Gen-ART review of the -09 version. More work is needed: [1] The review of the -09 version stated: Section 3.2 doesn't provide enough information to calculate a packet priority value from layer, resolution and component values. In fact the example it gives appears to be simple enough to also be an example of the component based ordering defined in Section 3.5. Section 3.2 needs to explain how the priority value is calculated and use a more complex example to illustrate the results of the calculation. In my opinion, Section 3.2, while improved, is still not clear enough to be interoperably implemented in its current form. A more complex example is now used, but the text does not state the the algorithm used to generate the priority, nor does it provide the specific algorithm for the example. The general algorithm is that the ordering is based on the triple layer, resolution, component and the minimum priority is 1, so, if - There are ltotal layers (layer value range is 0 to ltotal-1) - There are rtotal resolutions (resolution value range is 0 to rtotal-1) - There are ctotal components (component value range is 0 to ctotal-1) then for a triple lval, rval, cval, - priority = 1 + cval + (ctotal*rval) + (ctotal*rtotal*lval) and for the example where ltotal=1, rtotal=2 and ctotal=3, - priority = 1 + cval + 3*rval because lval=0 hence the ctotal*rtotal*lval term is zero (3*2*0) and hence does not contribute to the priority computation. [2] The review of the -09 version stated Section 4.1 contains this problematic text: An initial value of mh_id MUST be selected randomly between 1 and 7 for security reasons. This has been partially addressed. While section 2.1 now requires that the initial value of mh_id always be zero, the above problematic text remains, and still needs to be removed from Section 4.1. In addition, Security Considerations paragraph on mh_id concludes with a rather cryptic statement that Care should be taken to prevent implementation bugs with potential security consequences. Either more specific guidance should be given, or the entire paragraph should be removed, as mh_id does not appear to have any security value. In addition, there is a new open issue: [3] Section 7 does not appear to instruct IANA on what is to be done. It appears that IANA should add the new parameters in section 5 to the existing registration of a media type, but neither section 5 nor section 7 tells IANA what do to or which media type registration is to be modified. Nits: Reference [1] has still not been corrected. The Gen-ART review of the -09 version stated: Reference [1] should reference the Internet Draft by name.
RE: [lemonade] Gen-ART review of draft-ietf-lemonade-convert-17.txt
Alexey, Thank you for your prompt response. Keeping the To: and Subject: lines in the IANA registration in Section 11.1 is fine since they are in RFC 2506, and RFC 2506 is noted in that section as having established the registry. Please consider adding an informative reference to RFC 2506, but this is not essential. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 [EMAIL PROTECTED] wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lemonade-convert-17.txt Reviewer: David L. Black Review Date: 15 April 2008 IETF LC End Date: 16 April 2008 Hi David, Thank you for your review. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This is a generally well-written draft on the CONVERT extension to IMAP. All of these comments are minor nits. In Section 2, please remove this convention: [[anchor3: Editorial comments and questions are marked like this.]] Done. p.10 contains a couple of example email addresses. Please use example.com, example.net or example.org as the domain. Somebody else complained about this earlier, so I've already fixed this in my copy. In Section 11.1 are the To: and Subject: lines needed as part of the IANA registration? If not, please remove them. They are a part of the IANA template in RFC 2506, so I would rather keep them In the IANA registration in Section 11.1, please ask IANA to replace RFC by the RFC number assigned to this draft. Ok. idnits 2.08.05 got confused by the square brackets used in IMAP syntax and reported a number of potential reference problems - there are no actual problems. Indeed. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-lemonade-convert-17.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lemonade-convert-17.txt Reviewer: David L. Black Review Date: 15 April 2008 IETF LC End Date: 16 April 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This is a generally well-written draft on the CONVERT extension to IMAP. All of these comments are minor nits. In Section 2, please remove this convention: [[anchor3: Editorial comments and questions are marked like this.]] p.10 contains a couple of example email addresses. Please use example.com, example.net or example.org as the domain. In Section 11.1 are the To: and Subject: lines needed as part of the IANA registration? If not, please remove them. In the IANA registration in Section 11.1, please ask IANA to replace RFC by the RFC number assigned to this draft. idnits 2.08.05 got confused by the square brackets used in IMAP syntax and reported a number of potential reference problems - there are no actual problems. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sipping-sbc-funcs-05.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sipping-sbc-funcs-05.txt Reviewer: David L. Black Review Date: 4 April 2008 IESG Telechat date: 10 April 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The authors have addressed all of the comments from the Gen-ART review of the -04 version of this draft - that was nicely done, and many thanks to the authors. The draft could be published as an RFC in its current form, but there's one nit that really should be dealt with: One of the comments was addressed by adding the last sentence to this paragraph in Section 3.4.2: There is also a problem related to the method how SBCs choose the value for the validity of a registration period. This value should be as high as possible, but it still needs to be low enough to maintain the NAT binding. Typically SBCs do not have any deterministic method for choosing a suitable value. However, SBCs can just use a sub-optimal, relatively small value which usually works. Please provide an example of a sub-optimal, relatively small value which usually works. This merits careful consideration, as implementers may well use the value provided as an example. One possibility is to use 15 seconds as the example and cite Section 3.5 of draft-ietf-tsvwg-udp-guidelines-06.txt (as an informative reference) for the source of this value (and a useful place to look for further discussion of this topic). Minor nit: Section 3.1.3: (i.e., information related to network elements is beeing hidden), Extra e here ^^ idnits 2.08.05 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 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-09.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-rtp-jpeg2000-beam-09.txt Reviewer: David Black Review Date: 15 March 2008 IETF LC End Date: 15 March 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: There are two open issues, both of which should be fairly easy to address: [1] Section 3.2 doesn't provide enough information to calculate a packet priority value from layer, resolution and component values. In fact the example it gives appears to be simple enough to also be an example of the component based ordering defined in Section 3.5. Section 3.2 needs to explain how the priority value is calculated and use a more complex example to illustrate the results of the calculation. [2] Section 4.1 contains this problematic text: An initial value of mh_id MUST be selected randomly between 1 and 7 for security reasons. This needs to be explained, and security is probably the wrong word. Any security that depends on this random choice is likely to be easily subverted by the adversary trying all 7 possible values. Nits: As noted by IANA, Section 7.2 doesn't contain any IANA actions and hence probably should not be a subsection of the IANA Considerations section (7) Reference [1] should reference the Internet Draft by name. [1] Futemma, RTP Payload Format for JPEG 2000 Video Streams, RFC XXXY, April 2007. I believe this is draft-ietf-avt-rtp-jpeg2000-18.txt. That should be in the reference instead of RFC XXXY. Then add an RFC Editor note asking the RFC Editor to replace all instances of RFC XXXY with the RFC number assigned when reference [1] is published as an RFC. idnits 2.08.04 found this problem with reference [1] and was confused by reference [3]. Reference [3] is fine as-is; no change is needed. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sipping-pending-additions-04.txt
Gonzalo, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sipping-pending-additions-04.txt Reviewer: David L. Black Review Date: 29 February 2008 IESG Telechat date: 06 March 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The following two issues noted the Gen-ART review of the -03 version of this draft do not appear to have been addressed in the -04 version. [1] 5.1.2. SUBSCRIBE Bodies A SUBSCRIBE for Pending Additions events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification. How is that supposed to be interoperable? A better approach would be to prohibit bodies now and allow a future specification to define them. [2] 5.1.7. Subscriber Processing of NOTIFY Requests NOTIFY requests contain full state. The subscriber does not need to perform any type of information aggregation. This text doesn't explain the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state (if applicable) (see Section 4.4.8 of RFC 3265). This text needs to be rewritten and expanded. The -04 draft addresses the partial notification case, but not the full notification case, unless Section 6.2 was intended to cover all notification processing, in which case it has the wrong title. idnits 2.08.04 ran clean aside from finding a couple of referenced Internet-Drafts that have revised versions. The RFC Editor will remove the version numbers in any case, so it's not important to correct them. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-evain-ebu-urn-01.txt
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-evain-ebu-urn-01.txt
Reviewer: David L. Black
Review Date: 15 November 2007
IETF LC End Date: 10 December 2007
Summary:
This draft is on the right track, but has open issues,
described in the review.
Comments:
There is one minor open issue, but it does cause syntactic
ambiguity, and hence needs to be fixed:
Declaration of structure:
URNs assigned by EBU will have the following hierarchical
structure based on the organisational structure of the EBU
resources:
urn:tva:{category}:{string}
where {category} and {string} are US-ASCII strings that
conforms to URN Syntax requirements ([RFC2141]).
The issue is that the use of the colon character (:) in
{category} needs to be prohibited in order to protect the
colon used as a delimiter between {category} and {string}. In
addition, it may also be appropriate to prohibit use of some or
all additional other characters defined in Section 2.2 of
RFC 2141 in {category} beyond prohibiting the colon character -
such a prohibition would apply the same syntax rules
rules to {category} as apply to the Namespace ID (ebu).
Nits:
(1)
Declared registrant of the namespace:
Name: jean-Pierre Evan
Should jean be capitalized?
Is there an i missing in Evan?
(2)
Declaration of structure:
URNs assigned by EBU will have the following hierarchical
structure based on the organisational structure of the EBU
resources:
urn:tva:{category}:{string}
tva -- ebu
(3)
3. Examples
The following examples are not guaranteed to be real. They are
presented for pedagogical reasons only.
urn:ebu:metadata:pmeta:2007
urn:ebu:metadata:cs:EscortCS:2007
urn:other:anytype:version
The third example (urn:other:anytype:version) should be removed.
(4)
idnits 2.05.01 found a possible boilerplate problem:
Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC
4748)
Disclaimer -- however, there's a paragraph with a matching
beginning.
Boilerplate error?
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED]Mobile: +1 (978) 394-7754
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt Reviewer: David L. Black Review Date: 7 October 2007 IETF LC End Date: 12 October 2007 IESG Telechat date: 18 October 2007 Summary: This draft is ready for publication as an Informational RFC. Comments: I am the chair of the RDDP working group. Since this draft proposes to apply the RDDP protocols to NFS, I have followed this draft and the related NFS RDMA protocol drafts in the nfsv4 WG and made comments on them in that forum. I have no further comments on this draft. idnits 2.04.16 runs clean (no issues found). Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
Elisa, Note that we're not singling out IPFIX here. The forthcoming revisions to the syslog documents, for example, will have the following statement (TLS is TLS over TCP): Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [RFC2914]. This is why the syslog TLS transport is REQUIRED to implement and RECOMMENDED for general use. The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used. I believe a similar statement for IPFIX would be appropriate. we currently have the following statement for IPFIX/UDP: --- UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering. However, UDP is not a reliable transport protocol, and IPFIX messages sent over UDP might be lost as with partially-reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties: o A dedicated network, o within a single administrative domain, o where SCTP is not available due to implementation constraints, o and the collector is as close as possible to the exporter. --- Would the addition of the text below be an acceptable solution? --- Note that because UDP itself provides no congestion control mechanisms, it is recommended to use UDP transport only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. --- While Lars (as AD) is the final authority (e.g., on whether it is recommended above is strong enough language), I'd like to add a couple of sentences to recognize dedicated network that hosted a NetFlow implementation as a common case (to help out the network administrators who actually have to make this work): An important example of an explicitly provisioned managed network for IPFIX is use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
Elisa, Most of these responses look fine. I do think additional text should be added on the topics of: - warnings about when not to use unordered delivery - explanation of when UDP use is appropriate More details inline ... Some responses also in line. I have deleted the stuff where we have agreed. We're getting close, but I think some more work on UDP guidelines is still appropriate. As the existence of the UDP guidelines draft indicates, this is a topic of current interest in the Transport Area. Section 6.1: There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered at the receiver as soon as it is received rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender even messages sent partially reliably will still be delivered in order. [1] Isn't this likely to cause problems when messages are processed out of order? If three messages are sent containing absolute counts of 45, 87, and 138, out of order processing combined with a delay to the first message could result in the count being 45 at the recipient after the three messages are processed, which seems rather wrong. Whose responsibility is it to prevent this? In contrast, partial reliability skips updates that would be generated by processing the dropped messages, and hence seems ok. I propose adding the following text at the end of the paragraph (to recommend not using unordered delivery when order may matter): Unordered delivery SHOULD NOT be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. I think some more explanation is in order about why ordering matters for templates. I would also say that unordered delivery SHOULD NOT be used when Total (absolute) Counters are used, as reordering could result in the counter value decreasing at the Collecting Process, and even being left with a stale value if the last message processed is stale. ok, so the proposed text on unordered delivery is the following: There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered to the receiver as soon as it is queued rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender even messages sent partially reliably will still be delivered in order. Unordered delivery SHOULD NOT be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. Unordered delivery SHOULD NOT be used when Total (absolute) Counters are used, as reordering could result in the counter value decreasing at the Collecting Process, and even being left with a stale value if the last message processed is stale. (note that I've appended the sentence you proposed) Looks good, here's one minor edit to what I wrote for consistency: Total (absolute) Counters -- Total counters Section 6.2: UDP [2] I don't see any discussion of congestion control in here. Something needs to be done to avoid a high rate IPFIX protocol session over UDP worsening a congestion situation because not only is the IPFIX flow non-responsive to congestion, but congested conditions may increase the volume of IPFIX data to be reported. At the very least, this draft should repeat and reinforce the discussion in Section 10.3.1 of draft-ietf-ipfix-protocol-24.txt, which says that UDP should not be used over congestion sensitive network paths - I'm not thrilled about that approach, but the ipfix-protocol draft is already in the RFC Editor Queue. A general recommendation against UDP when TCP or SCTP is possible may be appropriate, and the first item in Section 10.1 is related to this concern, as it requires availability of a congestion-controlled protocol. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties: 1. a dedicated network 2. within a single administrative domain 3. where SCTP is not available due to implementation constraints 4. and the collector is as close as possible to the exporter. Would you like to see this text in the document or is the current text at the beginning of 6.2 enough: [ ... snip ... ] Please put the above text into the document and explain dedicated network in more detail - that is crucial to ensuring the additional IPFIX traffic generated as a consequence of high traffic situations does not make the situation worse from a congestion standpoint. In writing
Gen-ART review of draft-ietf-enum-calendar-service-03.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-enum-calendar-service-03.txt Reviewer: David Black Review Date: 24 August 2007 IETF LC End Date: 6 September Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This is a relatively straightforward registration of an ENUM service, and the draft does a good job of explaining the service that is being registered. I found one minor nit in the service registration (Section 2): Security considerations: See section 3. That should be See section 4. as section 3 contains examples and section 4 is the Security Considerations. idnits 2.04.14 did not find any issues. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-07.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-avt-rtp-and-rtcp-mux-07.txt Reviewer: David Black Review Date: 17 August 2007 IESG Telechat date: 23 August 2007 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: All of the comments raised in the Gen-ART review of the -05 version have been addressed in the -07 version of this draft. In particular, the -07 version contains sufficient instructions to IANA. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
Elisa, Most of these responses look fine. I do think additional text should be added on the topics of: - warnings about when not to use unordered delivery - explanation of when UDP use is appropriate More details inline ... Many thanks, --David David, thanks for your review. Find answers and comments inline... [EMAIL PROTECTED] wrote: 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. --- Summary --- This draft is in generally good shape, but has some issues that need to be addressed. The three most important issues are: [1] Side effects of out-of-order message processing [2] Dealing with UDP's lack of congestion control [3] X.509 certificate interoperability They're tagged with these numbers below. Issue [3] is fairly easy to address (cite RFC 3280), but can cause complex interoperability disasters when it is not addressed. --- Comments --- Section 3.5: Note also that while SCTP guarantees to preserve message boundaries even if the message sent is larger than the path MTU, there is no such facility in TCP or TLS. Please explain why this matters. The TCP or TLS receiver receives a byte stream and parses the IPFIX messages based on that byte stream. As long as the byte stream contents are sufficient to identify IPFIX message boundaries, how/why does SCTP's preservation of them matter to IPFIX implementations? We initially wrote this note because CPs over a datagram-oriented transport (UDP, SCTP) can use the packet boundaries instead of having to use the Message Length field to read the message off the wire. This simplifies the CP implementation (one read() to get a Message instead of two (one for the message header and one for the rest). Anyway I'm not completely sure this is relevant and fits here (nor it does mentioning TLS at this stage...) so my proposal is to completely cut this sentence That's a completely reasonable thing to do. Section 6.1: There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered at the receiver as soon as it is received rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender even messages sent partially reliably will still be delivered in order. [1] Isn't this likely to cause problems when messages are processed out of order? If three messages are sent containing absolute counts of 45, 87, and 138, out of order processing combined with a delay to the first message could result in the count being 45 at the recipient after the three messages are processed, which seems rather wrong. Whose responsibility is it to prevent this? In contrast, partial reliability skips updates that would be generated by processing the dropped messages, and hence seems ok. I propose adding the following text at the end of the paragraph (to recommend not using unordered delivery when order may matter): Unordered delivery SHOULD NOT be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. I think some more explanation is in order about why ordering matters for templates. I would also say that unordered delivery SHOULD NOT be used when Total (absolute) Counters are used, as reordering could result in the counter value decreasing at the Collecting Process, and even being left with a stale value if the last message processed is stale. o Increase the bandwidth of the links through which the Data Records are exported. Both instances of this should be rephrased to: o Increase the bandwidth available for communicating the exported Data Records. There are a number of scenarios in which link bandwidth increases do not benefit all flows on a link. ok, changed. Section 6.2: UDP [2] I don't see any discussion of congestion control in here. Something needs to be done to avoid a high rate IPFIX protocol session over UDP worsening a congestion situation because not only is the IPFIX flow non-responsive to congestion, but congested conditions may increase the volume of IPFIX data to be reported. At the very least, this draft should repeat and reinforce the discussion in Section 10.3.1 of draft-ietf-ipfix-protocol-24.txt, which says that UDP should not be used over congestion sensitive network paths - I'm not thrilled about that approach, but the ipfix-protocol draft is already in the RFC Editor Queue. A
Gen-ART review of draft-ietf-sip-ice-option-tag-02
Jonathan, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sip-ice-option-tag-02 Reviewer: David Black Review Date: 11 August 2007 IETF LC End Date: 16 August 2007 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: This short draft defines a couple of SIP tags for ICE. It's in good shape. The only things I found are very minor: The Unfortunately, word at the beginning of Section 3.1 should probably be removed. idnits 2.04.12 found an outdated reference: == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-ice-13 Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-rtp-and-rtcp-mux-05.txt Reviewer: David Black Review Date: 16 July 2007 IETF LC End Date: 17 July 2007 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft is generally in good shape, although one needs to be an RTP expert to understand all the details. The only open issue is the missing instructions to IANA for RTCP packet type registration - from a technical standpoint, this is a nit, but getting it right is of sufficient importance to avoidance of future restrictions RTP/RTCP multiplexing that I've flagged it as an open issue. Everything else in this review is an editorial comment, although the absence of the explanation of the mechanics of the RTP/RTCP conflicts makes that section of the draft difficult to read. Section 1 talks about NAT (Network Address Translation) as a motivation, but the real motivation appears to be NAPT (Network Address Port Translation). This ought to be discussed, and I strongly suggest an Informative reference to RFC 3022. The term NAT pinhole also needs to be explained here to connect the problems caused by two UDP ports to NAPT usage, and it may be useful to mention firewall pinholes as a related issue. Section 4 should explain the mechanics of the RTP/RTCP conflict: - The RTCP PT is bits 8-15. - The RTP PT is bits 9-15. - RTP uses bit 8 in that word for a M (Marker) bit that may be on or off. The latter item is the cause for needing to check for whether the RTCP PT conflicts with either the RTP PT or the RTP PT + 128. The last 2 paragraphs in Section 4 before the final Note in that section need attention: - The paragraph on registration of new RTCP packet types needs to instruct IANA on what rules to enforce. The use of SHOULD in the current text is not sufficient, instead this needs to be restated as instructions to IANA on how to assign RTCP packet types and noted in the IANA considerations section. - In this text in the second paragraph: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, Insert the word dynamic between the choice of and RTP payload type values for clarity. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
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. --- Summary --- This draft is in generally good shape, but has some issues that need to be addressed. The three most important issues are: [1] Side effects of out-of-order message processing [2] Dealing with UDP's lack of congestion control [3] X.509 certificate interoperability They're tagged with these numbers below. Issue [3] is fairly easy to address (cite RFC 3280), but can cause complex interoperability disasters when it is not addressed. --- Comments --- Section 3.5: Note also that while SCTP guarantees to preserve message boundaries even if the message sent is larger than the path MTU, there is no such facility in TCP or TLS. Please explain why this matters. The TCP or TLS receiver receives a byte stream and parses the IPFIX messages based on that byte stream. As long as the byte stream contents are sufficient to identify IPFIX message boundaries, how/why does SCTP's preservation of them matter to IPFIX implementations? Section 4.2: Although it is not explicitly mentioned in the protocol draft the order of Information Elements within the Template MAY be changed by Exporting or Collecting Processes for example for alignment purposes. It looks like this allows a single Collecting implementation (multiple Collecting Processes) to receive information from multiple Exporting Processes using the same template but with different ordering of information sent by each Exporting Process. If that is correct, it would be good to advise implementers of this possibility and suggest that a single normalized order of stored information for each template be used in a Collecting implementation to avoid confusion if/when this happens - somewhere in Section 5 would be an appropriate location for this advice. Section 6.1: There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered at the receiver as soon as it is received rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender even messages sent partially reliably will still be delivered in order. [1] Isn't this likely to cause problems when messages are processed out of order? If three messages are sent containing absolute counts of 45, 87, and 138, out of order processing combined with a delay to the first message could result in the count being 45 at the recipient after the three messages are processed, which seems rather wrong. Whose responsibility is it to prevent this? In contrast, partial reliability skips updates that would be generated by processing the dropped messages, and hence seems ok. o Increase the bandwidth of the links through which the Data Records are exported. Both instances of this should be rephrased to: o Increase the bandwidth available for communicating the exported Data Records. There are a number of scenarios in which link bandwidth increases do not benefit all flows on a link. Section 6.2: UDP [2] I don't see any discussion of congestion control in here. Something needs to be done to avoid a high rate IPFIX protocol session over UDP worsening a congestion situation because not only is the IPFIX flow non-responsive to congestion, but congested conditions may increase the volume of IPFIX data to be reported. At the very least, this draft should repeat and reinforce the discussion in Section 10.3.1 of draft-ietf-ipfix-protocol-24.txt, which says that UDP should not be used over congestion sensitive network paths - I'm not thrilled about that approach, but the ipfix-protocol draft is already in the RFC Editor Queue. A general recommendation against UDP when TCP or SCTP is possible may be appropriate, and the first item in Section 10.1 is related to this concern, as it requires availability of a congestion-controlled protocol. The possibility of Exporter vs. Collector misconfiguration on template resend interval vs. template expiry time is unfortunate and (as described) can cause interoperability issues. Can IPFIX define a template for an Exporter to report its resend interval? That would enable a Collector to determine an appropriate expiry time for each Exporter, and might obviate the need for the packet-count-based resend mechanism discussion. Before using a Template for the first time, the Exporter may send it in several different IPFIX messages in quick succession to increase the likelihood that the Collector has received the Template. That's exactly the wrong thing to do if there's a congested tail-drop queue in the path, as it
RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
Gonzalo, The -05 draft looks fine, and I have no problem with leaving comment (1) [whether to say something applicable beyond BFCP on the subjects of IP address selection and use of SubjectAltName] to the discretion of the ADs. Thanks, --David -Original Message- From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 5:59 AM To: Black, David Cc: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Hi David, I have put together a new revision of the draft that addresses all your comments. Regarding your comment (1), I will send a note to the ADs so that they decide what to do. Until the draft appears in the archives, it can be fetched from: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-conne ction-05.txt Thanks, Gonzalo [EMAIL PROTECTED] wrote: Gonzalo, Most of this looks good; I have a few comments: (1) In the two places where there are general recommendations that are not specific to BFCP (IP address selection and use of SubjectAltName in certs in preference to Subject), it would be good to note that these are general recommendations that are not specific to BFCP, **but** please consult your AD on whether and how to do this, as these are cross-area issues in the IETF. The existing text is ok. (2) I would change the sentence about PBKDF2 key strengthening, as the use of security is questionable: OLD: Because such key derivation functions may incorporate iteration functions for key strengthening they provide some additional security against dictionary attacks. NEW: Because such key derivation functions may incorporate iteration functions for key strengthening they provide some additional protection against dictionary attacks by increasing the amount of work that the attacker must perform. (3) Regarding the obtain language, I would make the following change to explain why the attacks don't apply - OLD: When the keys are randomly generated and of sufficient length, these attacks do not obtain. NEW: When the keys are randomly generated and of sufficient length, dictionary attacks are not effective because such keys are highly unlikely to be in the attacker's dictionary. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 -Original Message- From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Sunday, June 17, 2007 5:52 AM To: Black, David Cc: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Cullen Jennings Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Hi David, thanks for your comments. Answers inline: [EMAIL PROTECTED] wrote: 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. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Given that such a generic document does not exist, we need to give these recommendations here. Section 4 starts with All BFCP entities implement TLS ... That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., [RFC 4582] requires that all BFCP entities implement TLS ... What about performing the following change? OLD: All BFCP entities implement TLS [7] and SHOULD use it in all their connections. NEW: [RFC 4582] requires that all BFCP entities implement TLS and recommends that they use it in all their connections. In the second paragraph of Section 4, I would change can request the use of TLS to SHOULD request the use of TLS. OK, I will fix it. Section 5.1 specifies that SubjectAltName identities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? We got that
RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
Gonzalo, Most of this looks good; I have a few comments: (1) In the two places where there are general recommendations that are not specific to BFCP (IP address selection and use of SubjectAltName in certs in preference to Subject), it would be good to note that these are general recommendations that are not specific to BFCP, **but** please consult your AD on whether and how to do this, as these are cross-area issues in the IETF. The existing text is ok. (2) I would change the sentence about PBKDF2 key strengthening, as the use of security is questionable: OLD: Because such key derivation functions may incorporate iteration functions for key strengthening they provide some additional security against dictionary attacks. NEW: Because such key derivation functions may incorporate iteration functions for key strengthening they provide some additional protection against dictionary attacks by increasing the amount of work that the attacker must perform. (3) Regarding the obtain language, I would make the following change to explain why the attacks don't apply - OLD: When the keys are randomly generated and of sufficient length, these attacks do not obtain. NEW: When the keys are randomly generated and of sufficient length, dictionary attacks are not effective because such keys are highly unlikely to be in the attacker's dictionary. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 -Original Message- From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Sunday, June 17, 2007 5:52 AM To: Black, David Cc: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Cullen Jennings Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Hi David, thanks for your comments. Answers inline: [EMAIL PROTECTED] wrote: 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. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Given that such a generic document does not exist, we need to give these recommendations here. Section 4 starts with All BFCP entities implement TLS ... That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., [RFC 4582] requires that all BFCP entities implement TLS ... What about performing the following change? OLD: All BFCP entities implement TLS [7] and SHOULD use it in all their connections. NEW: [RFC 4582] requires that all BFCP entities implement TLS and recommends that they use it in all their connections. In the second paragraph of Section 4, I would change can request the use of TLS to SHOULD request the use of TLS. OK, I will fix it. Section 5.1 specifies that SubjectAltName identities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? We got that recommendation from our security adviser. I do not know whether this will be documented in a generic document at some point. The following text appears to be an oversight: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. The client *always* knows the server's IP address (e.g., DNS returns it). I think the intended case here is that the client contacts the server using the server's IP address and as a result does not know the server's hostname. Rephrasing in that sort of fashion would also express a preference for hostname as certificate identity, which I believe is desirable. What about performing the following change?: OLD: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. NEW:
tsv-dir review of draft-ietf-xcon-bfcp-connection-04
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. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Section 4 starts with All BFCP entities implement TLS ... That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., [RFC 4582] requires that all BFCP entities implement TLS ... In the second paragraph of Section 4, I would change can request the use of TLS to SHOULD request the use of TLS. Section 5.1 specifies that SubjectAltName identities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? The following text appears to be an oversight: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. The client *always* knows the server's IP address (e.g., DNS returns it). I think the intended case here is that the client contacts the server using the server's IP address and as a result does not know the server's hostname. Rephrasing in that sort of fashion would also express a preference for hostname as certificate identity, which I believe is desirable. Section 6 disturbingly shifts between password and pre-shared key and appears to get a few things wrong in the process. To begin with, the statement that TLS PSK mode is subject to offline dictionary attacks. is false when the PSK is high-entropy. OTOH, it is correct when the PSK is low-entropy (e.g., a password, or derived from a password without introduction of additional entropy). The discussion in Section 7.2 of RFC 4279 applies, especially the last paragraph about PSK generation. The section needs to be carefully revised to distinguish between password and pre-shared key, especially given the mention of use of PBKDF2 to generate the latter from the former. Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn)
Pekka, [logical components being:] encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. I'd like to see it explicitly stated that transporting congestion information in the (metered) IP packets themselves is out of scope. Forward transport of the basic congestion information has to be in scope as Fred has pointed out. Backwards transport needs to be scoped by application scenario - for example, backwards transport via SIP is clearly out of scope for the initial PCN work. OTOH, not specifying how to actually move any of this information around would turn PCN into the moral equivalent an IRTF Research Group, which (IMHO) would be bad - at the end of the day, PCN needs to produce something that actually works (need running code in addition to rough consensus). Thanks, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar
Ray, Looking at the 2007 and 2008 dates on events.cal, it looks like ANSI T10 (SCSI) is the primary conflict for the first week of November, and ANSI T11 (Fibre Channel) is the primary conflict for the first week of December. The currently proposed schedule is first week of December for the 3rd IETF meeting each year, and hence hits T11 every year. Would it be possible to alternate between the first week of November and the first week of December in successive years so that each of T10 and T11 only gets hit every other year, or are there other considerations that favor December over November? Thanks, --David (ips, imss, rddp WG chair) David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 -Original Message- From: Ray Pelletier [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 17, 2006 6:59 AM To: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar All; This is a 1 week Last Call for feedback on Version 01 proposed 2008 - 1010 IETF Meeting dates. The IAOC anticipates taking action to formally adopt dates on 25 May 2006. These dates differ from the originally proposed dates based upon community feedback, a review of meeting dates of those organizations on the Clash List and maintenance of a reasonably similar period between meetings. While every effort was made to avoid conflicts where known, it was not always possible with those organizations in the should avoid category. Your feedback to [EMAIL PROTECTED] on conflicts with these dates would be appreciated. Proposed 2008 - 2010 meeting dates: 2008 IETF 71 Mar 30 - Apr 4 IETF 72 Jul 27 - Aug 1 IETF 73 Dec 7 - 12 2009 IETF 74 Mar 22 - 27 IETF 75 Aug 2 - 7 IETF 76 Dec 6 - 11 2010 IETF 77 Mar 28 - Apr 2 IETF 78 Jul 25 - 30 IETF 79 Dec 5 - 10 Our findings of the schedule of other organization's meetings can be found at: http://www.ietf.org/meetings/events.cal.html . Thanks for your assistance. Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar
Ray, Let me check that I understand your answer - it sounds like you're keeping a 1-week buffer clear on both sides of IEEE 802, so that a November IEEE 802 meeting makes it impossible for IETF to meet in November as the IEEE week plus the 1-week before and after buffers take out the entire available portionof November (the US Thanksgiving holiday weekend takes out the rest of the month). Did I understand that correctly? It strikes me as excessive. I can understand October being sufficiently early as to cause other problems. Thanks for taking another look, --David David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 From: Ray Pelletier [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 8:50 PMTo: Black, DavidCc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: Re: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar [EMAIL PROTECTED] wrote: Ray, Looking at the 2007 and 2008 dates on events.cal, it looks like ANSI T10 (SCSI) is the primary conflict for the first week of November, and ANSI T11 (Fibre Channel) is the primary conflict for the first week of December. The currently proposed schedule is first week of December for the 3rd IETF meeting each year, and hence hits T11 every year. Would it be possible to alternate between the first week of November and the first week of December in successive years so that each of T10 and T11 only gets hit every other year, or are there other considerations that favor December over November? David, I'll take a fresh look at it, but it's kind of hard to avoid conflicts with T10 and T11 "Should Avoid" meetings when there are 6 of each scheduled in 2008. The greatest pressure on December meetings is our need to avoid conflicts by one week with "Must Avoids" like IEEE in November, forcing us into December or October meeting considerations. December is not my first choice. October puts spacing pressure back to the beginning of the year.Again, I'll look at it, but unless we relax the one week conflict avoidance with "Must Avoids" I'm not optimistic.Ray Thanks, --David (ips, imss, rddp WG chair) David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 -Original Message- From: Ray Pelletier [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 17, 2006 6:59 AM To: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Last Call: Proposed 2008 - 2010 IETF Meeting Calendar All; This is a 1 week Last Call for feedback on Version 01 proposed 2008 - 1010 IETF Meeting dates. The IAOC anticipates taking action to formally adopt dates on 25 May 2006. These dates differ from the originally proposed dates based upon community feedback, a review of meeting dates of those organizations on the Clash List and maintenance of a reasonably similar period between meetings. While every effort was made to avoid conflicts where known, it was not always possible with those organizations in the "should avoid" category. Your feedback to [EMAIL PROTECTED] on conflicts with these dates would be appreciated. Proposed 2008 - 2010 meeting dates: 2008 IETF 71 Mar 30 - Apr 4 IETF 72 Jul 27 - Aug 1 IETF 73 Dec 7 - 12 2009 IETF 74 Mar 22 - 27 IETF 75 Aug 2 - 7 IETF 76 Dec 6 - 11 2010 IETF 77 Mar 28 - Apr 2 IETF 78 Jul 25 - 30 IETF 79 Dec 5 - 10 Our findings of the schedule of other organization's meetings can be found at: http://www.ietf.org/meetings/events.cal.html . Thanks for your assistance. Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
