Re: 73rd IETF - Registration
On Fri, Aug 22, 2008 at 07:46:21AM -0400, Marshall Eubanks wrote: > >but what about cookie preference? > > s/cookie preference/cookie size preference/ > > Marshall > > >;-) > > > >James > > > >> Dietary Restrictions? > >> > >> Tony Hansen see Dietary Restrictions, re cookie pref. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-rfc-image-files-00.txt
--On Friday, 22 August, 2008 16:12 -0700 Bill McQuillan <[EMAIL PROTECTED]> wrote: > On first reading this seems to be an interesting way to go. > > However, is it necessary to call a file full of "figures" an > "image" file? Couldn't we just pick one word throughout? I > vote for "figures" since it seems to match more to the book > publishing metaphore. Thus: > > draft-...-vv.figs.pdf > RFCn/Figures > and some other text changes. > > I also hope that some guidelines for standard ways to > reference a particular figure from the ASCII text will be > developed. Bill, Personal opinions only: I have not polled my esteemed co-author, nor the contributors from the Editorial Board, and we may not agree. My hope is that we can discuss and figure out whether the community likes and will accept the general idea. Your "interesting way to go", even if not conclusive, seems to align with that first step. Beyond that, I'm delighted to quibble, or let others quibble, about terminology in the text, naming conventions for files, packaging of files, side-effects on organization of archives, and probably a range of topics I haven't even thought of yet. As far as I'm concerned, those details are specified in this draft in order to have something specified and to give a clear indication about what needs to be specified. Not doing so risked having a draft that would have been sufficiently vague that we would have risked a debate about what people thought it might say, and those debates are fairly useless. There are some things that might look like details but that are actually rather carefully chosen after exploration of alternatives but these aren't them. Given that, I believe that one set of details of the sort you describe can be easily substituted for another if the community has a strong preference. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-rfc-image-files-00.txt
On first reading this seems to be an interesting way to go. However, is it necessary to call a file full of "figures" an "image" file? Couldn't we just pick one word throughout? I vote for "figures" since it seems to match more to the book publishing metaphore. Thus: draft-...-vv.figs.pdf RFCn/Figures and some other text changes. I also hope that some guidelines for standard ways to reference a particular figure from the ASCII text will be developed. -- Bill McQuillan <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 73rd IETF - Registration
At 10:06 AM 8/22/2008, John C Klensin wrote: --On Friday, 22 August, 2008 02:14 -0500 "James M. Polk" <[EMAIL PROTECTED]> wrote: > At 05:01 PM 8/21/2008, Tony Hansen wrote: >> IETF Secretariat wrote: >> > Registration is now open for the 73rd IETF Meeting! >> >> Kudos on adding these two new questions to the registration >> form: >> >> T-Shirt Size > > +1 > > but what about cookie preference? No a single question. Need diameter (or parameters of other shapes), thickness profile, ingredients, nutrient values, and whether or not they are decorated with cute faces. The debate we have never had is whether people would be more or less productive after breaks if their cookies stared back at them. we do know that some get especially grumpy having not consumed any cookies at a break ekr comes to mind as an example case. john ___ 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: 73rd IETF - Registration
On Aug 22, 2008, at 3:14 AM, James M. Polk wrote: At 05:01 PM 8/21/2008, Tony Hansen wrote: IETF Secretariat wrote: > Registration is now open for the 73rd IETF Meeting! Kudos on adding these two new questions to the registration form: T-Shirt Size +1 but what about cookie preference? s/cookie preference/cookie size preference/ Marshall ;-) James Dietary Restrictions? Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 73rd IETF - Registration
At 05:01 PM 8/21/2008, Tony Hansen wrote: IETF Secretariat wrote: > Registration is now open for the 73rd IETF Meeting! Kudos on adding these two new questions to the registration form: T-Shirt Size +1 but what about cookie preference? ;-) James Dietary Restrictions? Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
