Weekly posting summary for ietf@ietf.org
Total of 57 messages in the last 7 days. script run at: Fri Sep 19 00:53:01 EDT 2008 Messages | Bytes| Who +--++--+ 8.77% |5 | 9.56% |37577 | [EMAIL PROTECTED] 5.26% |3 | 12.98% |51012 | [EMAIL PROTECTED] 5.26% |3 | 6.36% |25004 | [EMAIL PROTECTED] 5.26% |3 | 5.78% |22722 | [EMAIL PROTECTED] 5.26% |3 | 4.81% |18881 | [EMAIL PROTECTED] 3.51% |2 | 3.82% |15010 | [EMAIL PROTECTED] 3.51% |2 | 3.76% |14757 | [EMAIL PROTECTED] 3.51% |2 | 3.23% |12684 | [EMAIL PROTECTED] 3.51% |2 | 3.02% |11884 | [EMAIL PROTECTED] 3.51% |2 | 2.85% |11197 | [EMAIL PROTECTED] 3.51% |2 | 2.80% |11015 | [EMAIL PROTECTED] 3.51% |2 | 2.62% |10300 | [EMAIL PROTECTED] 3.51% |2 | 2.45% | 9610 | [EMAIL PROTECTED] 3.51% |2 | 2.33% | 9143 | [EMAIL PROTECTED] 3.51% |2 | 2.21% | 8697 | [EMAIL PROTECTED] 1.75% |1 | 3.58% |14068 | [EMAIL PROTECTED] 1.75% |1 | 2.33% | 9135 | [EMAIL PROTECTED] 1.75% |1 | 1.99% | 7822 | [EMAIL PROTECTED] 1.75% |1 | 1.78% | 6999 | [EMAIL PROTECTED] 1.75% |1 | 1.77% | 6969 | [EMAIL PROTECTED] 1.75% |1 | 1.70% | 6660 | [EMAIL PROTECTED] 1.75% |1 | 1.66% | 6527 | [EMAIL PROTECTED] 1.75% |1 | 1.61% | 6322 | [EMAIL PROTECTED] 1.75% |1 | 1.49% | 5849 | [EMAIL PROTECTED] 1.75% |1 | 1.47% | 5790 | [EMAIL PROTECTED] 1.75% |1 | 1.36% | 5352 | [EMAIL PROTECTED] 1.75% |1 | 1.31% | 5131 | [EMAIL PROTECTED] 1.75% |1 | 1.30% | 5092 | [EMAIL PROTECTED] 1.75% |1 | 1.23% | 4834 | [EMAIL PROTECTED] 1.75% |1 | 1.22% | 4805 | [EMAIL PROTECTED] 1.75% |1 | 1.22% | 4792 | [EMAIL PROTECTED] 1.75% |1 | 1.17% | 4606 | [EMAIL PROTECTED] 1.75% |1 | 1.16% | 4544 | [EMAIL PROTECTED] 1.75% |1 | 1.05% | 4134 | [EMAIL PROTECTED] 1.75% |1 | 1.01% | 3976 | [EMAIL PROTECTED] +--++--+ 100.00% | 57 |100.00% | 392900 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SECDIR review of draft-ietf-forces-model-14
Thanks Richard. It is heartening that someone from another aspect of the community can read and understand the document. I will await instructions from the ADs as to whether some text on the degree of control a lying FE can exercise while misleading the CE (almost unlimited) is a helpful thing to add to the security considerations section. Again, thank you fro the effort and the comment, Joel Richard Barnes wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document describes an information model for describing forwarding > elements within the ForCES framework. In this model, forwarding > elements are constructed as a network of Logical Functional Blocks with > a well-defined interconnection topology. The document seems > functionally complete and consistent. > > The document defines an XML syntax for describing FE capabilities and > states. This structure (in some semanticaly equivalent encoding) will > be the basis for such descriptions within the ForCES protocol. Section > 7 makes clear that FE descriptions constructed according to this model > will be used to communicate FE topology information for several purposes. > > Given that attacks on this information while en route between ForCES > entities are dealt with in RFC 3746, what seems to me to be missing here > is a discussion of what risks an entity can introduce by > mis-constructing a model, i.e., by communicating false information > within the protocol. For example, could an FE prevent a CE from > controlling certain LFBs by omitting them from the topology it reports? > Some discussion of these risks would be helpful. > > Overall, however, I think this document adequately addresses relevant > security concerns. > > --Richard > > ___ > 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
SECDIR review of draft-ietf-forces-model-14
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an information model for describing forwarding elements within the ForCES framework. In this model, forwarding elements are constructed as a network of Logical Functional Blocks with a well-defined interconnection topology. The document seems functionally complete and consistent. The document defines an XML syntax for describing FE capabilities and states. This structure (in some semanticaly equivalent encoding) will be the basis for such descriptions within the ForCES protocol. Section 7 makes clear that FE descriptions constructed according to this model will be used to communicate FE topology information for several purposes. Given that attacks on this information while en route between ForCES entities are dealt with in RFC 3746, what seems to me to be missing here is a discussion of what risks an entity can introduce by mis-constructing a model, i.e., by communicating false information within the protocol. For example, could an FE prevent a CE from controlling certain LFBs by omitting them from the topology it reports? Some discussion of these risks would be helpful. Overall, however, I think this document adequately addresses relevant security concerns. --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
A brief comment on this... I may have more to say later on... --On Thursday, 18 September, 2008 10:07 -0700 The IESG <[EMAIL PROTECTED]> wrote: > > The IESG has received the attached text for a proposed IESG > Statement: IESG Statement on the Usage of Assignable > Codepoints in Specification Examples >... > > = = = = = = Text of Proposed IESG Statement = = = = = = = >... > 1) Spam: apparently valid email addresses in an RFC are widely > believed to have been harvested and included in Spam lists. > The domain may receive spam at mailboxes other than the one > used in the example email address, if the domain name is used > in common name or brute force attacks. Please note that a careful reading of this paragraph would either ban or discourage the appearance of author email addresses in RFCs. Yet such addresses have been a firm requirement for many years (if I recall, since before there was an IETF). Questions: (i) Does the IESG intend to change the requirement for email addresses? (ii) Does the IESG believe that the appearance of a domain name in an email address in an example is somehow more harmful or likely to draw the attention of spammers than one in an "Author's Address" section? If not, could you explain your reasoning? (iii) Does the IESG intend to pursue the idea, discussed many times, of creating a reserved mail domain and assigning all RFC authors mailboxes or aliases in it? I note with interest that this statement does not appear to apply (or at least does not appear to offer justification for applying) these rules to domain names that do not appear in email addresses (or in configuration files, etc.). I note with even more interest that reservation of "codepoints" for example or other documentation purposes would violate existing IESG statements and rules about conservation of scarce resources (where scarcity is an issue) or would require negotiation with other bodies. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for review of proposed IESG Statement on Examples
The IESG has received the attached text for a proposed IESG Statement: IESG Statement on the Usage of Assignable Codepoints in Specification Examples The IESG plans to make a decision in the next few weeks, and solicits final comments on this proposed IESG statement. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-10-02. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. On behalf of the IESG, Russ Housley = = = = = = Text of Proposed IESG Statement = = = = = = = IESG Statement on the Usage of Assignable Codepoints in Specification Examples Protocol specifications and other documents intended for RFC publication often include useful examples with correctly formatted and syntactically valid codepoints. Example codepoints may be names, addresses or assigned numbers, such as email addresses, domain names, IP addresses or ports. The value used in an example may already have been assigned or may become assigned in the future to entities on the Internet, and this can cause problems. Codepoints used in specification examples can result (and have in the past resulted) in some amount of unwanted traffic. The impact of this unwanted traffic varies highly depending on the context and nature of the example. Some examples of causing unwanted traffic include: 1) Spam: apparently valid email addresses in an RFC are widely believed to have been harvested and included in Spam lists. The domain may receive spam at mailboxes other than the one used in the example email address, if the domain name is used in common name or brute force attacks. 2) Test code: when test implementors use the examples from the specification, sometimes they forget to change the example addresses, potentially resulting in unwanted traffic to the example address. 3) Configuration files: example configuration files are commonly copied and then edited. Configuration files may be distributed to a large number of hosts as part of a software package. That software may be deployed or tested before removing the example address. In several cases, this class of error caused substantial impact on the resource named. The results were effectively distributed denial of service attacks and increased operational costs for the targets. Use of examples in RFCs is not a new concern. The issues have been known and considered for several types of codepoints. BCP 32 (RFC 2606 - Reserved Top Level DNS Names) reserved some domain names for use in examples. RFC 3330 (Special-Use IPv4 Addresses) and RFC 5156 (Special-Use IPv6 Addresses) assigned some IP address ranges specially for examples and documentation. RFC4735 (Example Media Types for Use in Documentation) registered one example media type and one subtype under each of the registered media types for example use. Other similar specifications and reserved codepoints exist. The IESG understands that not all types of codepoints have reserved values or ranges for documentation and examples. The IESG also understands that sometimes the use of reserved values makes examples harder to read or less apt. In these cases authors have several options: - The specification itself can request further values or codepoints to be assigned. - The author can get permission from the holders of assigned values. However, the stability of the assignment needs to be considered. - The author can request approval for use of non-example addresses, names or codepoints, with an analysis of the expected effect of this use. Documents that update previously published RFCs fall under less pressure to update examples that have already been published. The use of reserved codepoints is still recommended in these documents when new examples are added or when examples change. Upon publication of this statement, the IESG will apply the following requirements to documents submitted for publication as RFCs in the IETF Stream. The document SHOULD use values reserved for examples where such assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156) and when the necessary semantic can be communicated clearly enough. If unassigned codepoints are desired it is RECOMMENDED that those codepoints be assigned or registered. If assigned codepoints are desired, it is RECOMMENDED that the authors get approval from the current codepoint holder. Designers of new protocols SHOULD consider example usage and register or assign values for example usage. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF copying conditions
<[EMAIL PROTECTED]> writes: >> > I think the *whole point* of a standard is to restrict how >> things are >> > done, in order to promote interoperability. >> >> Standards are recommendations not restrictions. > > Let's say that the restrictions viewpoint wins out in the > IETF and all RFCs are copyrighted in such a way that I > am not free to publish a revised version. > > What law would prevent me from publishing the following > GW-SMTP document? > > snip- > Gee-Whizz SMTP is a derivative of IETF. > > In RFC 2821 replace all occurences of HELO with GDAY. > snip- > > This is clearly an incompatible derivative of SMTP but I > don't even need to quote the document, even though "fair use" > laws would allow me to do that. Indeed, and that is why the argument that specifications need to be copy+modify protected in order to prevent incompatible derivatives is silly. Further, re-writing RFC 2821 using other words is a feasible task for any significant SDO that really wishes to standardize a modified variant of SMTP. > P.S. it seems to me that the best way to ensure that incompatible > derivatives do not flourish is to make sure that the work of the > IETF remains relevant to the current situation, and not mired in > the past. That way, the IETF will maintain a position of respect > and people will not want to create incompatible derivative works. > > Openness is required in order for advancement to occur. +1. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF copying conditions
+1 On Thu, Sep 18, 2008 at 9:10 PM, Tony Finch <[EMAIL PROTECTED]> wrote: > On Wed, 17 Sep 2008, Joe Abley wrote: >> >> I think the *whole point* of a standard is to restrict how things are >> done, in order to promote interoperability. > > Standards are recommendations not restrictions. > > Tony. > -- > f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ > NORTHWEST SHANNON: SOUTHWESTERLY 5 TO 7, BECOMING VARIABLE 4 LATER. ROUGH OR > VERY ROUGH. RAIN, BECOMING FAIR LATER. MODERATE OR POOR BECOMING GOOD. > ___ > 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: IETF copying conditions
> > I think the *whole point* of a standard is to restrict how > things are > > done, in order to promote interoperability. > > Standards are recommendations not restrictions. Let's say that the restrictions viewpoint wins out in the IETF and all RFCs are copyrighted in such a way that I am not free to publish a revised version. What law would prevent me from publishing the following GW-SMTP document? snip- Gee-Whizz SMTP is a derivative of IETF. In RFC 2821 replace all occurences of HELO with GDAY. snip- This is clearly an incompatible derivative of SMTP but I don't even need to quote the document, even though "fair use" laws would allow me to do that. --Michael Dillon P.S. it seems to me that the best way to ensure that incompatible derivatives do not flourish is to make sure that the work of the IETF remains relevant to the current situation, and not mired in the past. That way, the IETF will maintain a position of respect and people will not want to create incompatible derivative works. Openness is required in order for advancement to occur. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF copying conditions
On Wed, 17 Sep 2008, Joe Abley wrote: > > I think the *whole point* of a standard is to restrict how things are > done, in order to promote interoperability. Standards are recommendations not restrictions. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTHWEST SHANNON: SOUTHWESTERLY 5 TO 7, BECOMING VARIABLE 4 LATER. ROUGH OR VERY ROUGH. RAIN, BECOMING FAIR LATER. MODERATE OR POOR BECOMING GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt
Hi, I believe the gen-art comments need to be discussed before this document can move before the IESG. Lars On 2008-8-21, at 23:30, ext [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-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
Nomcom nominations not encrypted and e-mailed back in clear text
It would be useful if the NomCom nomination web page stored the feedback encrypted, and did not send the nomination back to me unencrypted through e-mail. As far as I can tell, I cannot expect any kind of privacy for nominations. If you want to get better feedback on people, consider improving the feedback system. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
