Re: Another look at 6to4 (and other IPv6 transition issues)
On Sun, Jul 17, 2011 at 6:59 AM, Doug Barton do...@dougbarton.us wrote: On 07/16/2011 07:02, John C Klensin wrote: --On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: snip But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. That do sum it up pretty good. snip Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy records. My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... and _yes_ that will hurt bad but it will force a hard error on the whole 6to4 issue. It's so much better with one hard error than lots of possible errors. snip But I don't recall seeing the sort of venom that is directed toward 6to4 being focused on them. Perhaps there weren't enough complaints or you have solid data that 6to4 has caused even more damage. Once again repeating myself ... I have no venom towards 6to4. This isn't a personal attack. And yes, various people and organizations that have vested interests in seeing IPv6 deployed have posted the data about why 6to4 causes way more problems than it solves, and I believe them. I dare to say the content providers want 6to4 gone because it _can_ be pointed at as a risk when enabling IPv6. And I do think the ISP see this as a quite black/white problem _if_ they have to deal with it. Either 6to4 are on and working all the time without them doing much, or it's gone. And this will be my last post on the subject at all, see no point in using more time on it. Lets move on :) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-yevstifeyev-ion-report-06
On 07/16/11 06:12, Mykyta Yevstifeyev wrote: Hello Harald, As you could see in one of my previous messages, I did intend to include some analysis in the draft (http://www.ietf.org/mail-archive/web/ietf/current/msg67491.html). However, numerous responses which discouraged me from doing this were received, and including that section will create problems with consensus. I saw the messages. It is very hard to write an analysis on behalf of someone else - to my mind, the analysis of why the IESG decided what they did has to be based on information from the IESG; it's impossible for any outsider, including you and me, to divine what their thought processes on this matter were. There's no IETF consensus to be documented here; the analysis and decision was done by the IESG, and the IESG (as it was composed at that time) is the body from which the information has to come. All any outsider (like you and me) can do is to help with the editing. However, I share your opinion that the document won't be full, so I think the following analysis section, which is different from the previous proposed one, can satisfy you and everybody else: Now, if someone were to speak for the then-present IESG and say the same thing, I would make the following comments: 3.4. Analysis There were a number of reasons which forced IESG to close the IONs experiment. Nit: forced IESG - caused the IESG to decide. There's no forcing function. One of them is a complexity of their approval and publication, compared with ones for IESG Statements and simple Web Pages. As IONs were intended to represent operational experience, they might have needed to be updated quickly. Even though these documents were meant to have a very lightweight approval procedure, it could sometimes be inappropriate for that material which was contained therein. In a protocol, I'd ask for a definition of quickly. Days, weeks or months? Examples of documents where days is the correct timescale? Secondly, due to the nature of the scope of IONs, there was no need to allow the access to the revision history (which is unavailable in simple Web Pages as well). I disagree with this statement, obviously. If the IESG thought so, it is correct to include it. Thirdly, IONs on procedural question could step into the conflict with Best Current Practice (BCP) RFCs; moreover, as IONs approval procedure did not imply any formal community review, unlike BCPs, they could easily fall in the community non-acceptance. I believe this is a red herring. However, I can fully believe that the argument was raised, even though I don't believe it, so if the IESG indeed thought that, I'm fine with having that documented. Correspondingly, it was concluded that the mandate of IONs can fully be fulfilled by RFCs, when documenting IETF procedures, IESG Statements, when clearing up other issues for which RFC publication process is not appropriate, and Web Pages, when dealing with other IETF-related issues. Nit: it was concluded - the IESG concluded. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Content-disposition: noise. On 07/16/11 09:15, Nathaniel Borenstein wrote: Notice Of Intentions in Sending Email? On Jul 16, 2011, at 1:09 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Thursday, July 14, 2011 11:39 AM To: Randall Gellens; Marc Petit-Huguenin Cc: IETF discussion list Subject: Re: Confidentiality notices on email messages If one starts down that path, there is a real possibility for a semantically-rich environment. For example, consider a noise type for flaming, repetitive, responses to a topic on the IETF list. One could also very efficiently reflect what I assume was the intent of a recent observation on the list with noise-type=hitler :-( The trick though, alas, is to get people using such disclaimers to begin using such a media type. Maybe we need an attractive acronym for NOISE as a decoy. ___ 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: Confidentiality notices on email messages
On Mon, 18 Jul 2011 14:41:35 +0200, Harald Alvestrand har...@alvestrand.no said: HA Content-disposition: noise. Or: Content-disposition: delete -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
--On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: To address your concern about whether or not vendors are paying attention to this discussion, and why historic status is substantively different than off by default, no really, OFF BY DEFAULT, I'll put my FreeBSD developer hat on for a minute and tell you that we definitely do pay attention to stuff like this, and whereas we already have it off by default (and have for some time) moving it to historic gives us the cover we need to remove the code at some point down the road when that's appropriate. That's an extremely important distinction, and one of the reasons that as a member of v6ops I ultimately came down in support of the 2-document strategy. Doug, And that is exactly where we agree on the effect and disagree about whether it is desirable. I think there is consensus that 6to4 is dangerous unless carefully and intelligently configured and that is certainly should not be turned on by default. If anyone has argued against that position, they are in a tiny minority. Similarly, I think there is consensus that following the advice in the advice document makes 6to4 much safer to use, even if not entirely risk-free (I contend that there is no risk-free, perhaps as a corollary to the principle that, if we invent something idiot-proof, someone will invent a better idiot). So there should be no question about the desirability about publishing the content of that document. The question, as far as the advice document is concerned, is how to get the message out most effectively, most clearly, and on as timely a basis as possible. I think that having it update the base 6to4 specs is important because that is how the RFC Series is threaded. Without that, there is an increased risk of people finding the 6to4 specs and implementing them without ever seeing the advice piece (just as, even with the updates/updated by pointers, we still hear about new TCP implementations based on RFC 793 alone). For the reasons discussed above, I don't think anyone would find that outcome desirable. As to whether there should be a single document or a separate Applicability Statement that points to both the base specifications and the advice document, I'm really pretty agnostic even though I don't see many advantages in two documents. A separate Applicability Statement that does update the base documents but points to the advice one would accomplish much the same purpose and eliminate the requirement that the advice document explicitly update the base ones. While I think publishing a separate document just to avoid that linkage would waste time, I'm actually pretty agnostic about that option too. But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option -- for FreeBSD users, the exact effect of your removing the code -- I haven't seen nearly as strong as case, or anything even close to consensus, for that position. If it was actually what the community believed, then the advice document would be a complete waste of time except possibly as a retrospective on how 6to4 might have been better specified (a retrospective that we would want to publish as (immediately) Historic). If the thing is still useful, even in limited circumstances and used correctly, then the IETF should not provide you with cover to remove the code because it is not in the best interest of the community for you to remove the code. Might both your removing the code and moving 6to4 to Historic in the future be appropriate? Sure. I also look forward to the day when we can move IPv4 to Historic (just as the various specifications that make up NCP should have been moved years ago if we paid attention to that sort of housekeeping). Summary: we should not move something to Historic that is still in use, useful, and that can be used correctly. We explain how to use it or the circumstances under which is should or should not be used, narrowing those descriptions as much as needed. And/or we explain all of the situations in which it should not be used. Simply reclassifying it as Historic is problematic to the use cases that actually do work and doesn't provide nearly enough information as what people should actually do, especially people who already have the protocol deployed in some form. Using Historic, rather than, e.g., NOT RECOMMENDED [any more] as a sort of super-deprecation mechanism depends too much on our assumption that people with working deployments will simply ignore us. While the assumption is right, it puts the whole situation into one in which the IETF is publicly operating on the assumption that its advice won't be followed. If we do that very often, we might as well just go home. FWIW, I note that there are at least a few other things that shipped for years with FreeBSD that could cause a lot of
Re: Confidentiality notices on email messages
On Thu, Jul 14, 2011 at 01:45:44AM -, John Levine wrote: It's clueless cargo cult lawyering. +1, and see also: http://www.river.com/users/share/etiquette/#legalistic which reads in part: First, such boilerplate contains useless adhesions, meaning the explicit and implied threats they make are particularly annoying. If you send something via email, the recipients (are you sure you aren't sending to a mailing list?) and anyone else who sees your clear text postcard in transit can undetectably and with full deniability do whatever they want with the information written on it in plain view. Even casual users of email know email is not a secure communications medium. Thus the threats in typical bogus legalistic boilerplate are naught but an attempt at highly improper intimidation. Demands made in this manner will be regarded as evidence of a hostile attitude on your part by a significant portion of recipients. The threats will negatively affect how your recipients perceive the other ideas in your message. Second, in the case of mailing lists (are you sure the address to which you sent isn't one?) or USENET posts, falsely claiming a message is confidential and privileged is simply too stupid for words. ---rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 3:36 AM, Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... and _yes_ that will hurt bad but it will force a hard error on the whole 6to4 issue. It's so much better with one hard error than lots of possible errors. Actually, no. It will cause a significant increase in the number of service calls that will last for years. And those will be the fault of the ISPs blocking the traffic. It must be re-iterated that the vast majority of problems associated with 6to4 appear to be caused by operators, not by 6to4 itself. 6to4 does have some real problems, and some of us are looking for ways to fix them. But that's no excuse for operators to deliberately make things worse. I dare to say the content providers want 6to4 gone because it _can_ be pointed at as a risk when enabling IPv6. And I do think the ISP see this as a quite black/white problem _if_ they have to deal with it. Either 6to4 are on and working all the time without them doing much, or it's gone. Part of the problem seems to be that operators want a quick solution that is under their control, when it appears that no such solution can exist. - Changes to the default address selection rules, already implemented or being implemented, should help significantly, but it will take some time for hosts to get updated to reflect those changes. (Asking Microsoft, Apple, and Linux vendors to include those changes in incremental updates - if they haven't already done so - might help speed that process along.) - The changes in -advisory will help somewhat, but it will take time for operators and vendors to learn about them and implement them, and the effect will be gradual. - The changes in -experimental will also help somewhat, if those changes are published in some form, but the effect will also be gradual. - Improvements to the 6to4 protocol (especially where relay routers are concerned) might help, but again will require updates to hosts and/or routers. (it's conceivable that fixes could be implemented in hosts that don't require the routers to be upgrade in order for those changes to be helpful) - As I said yesterday, there are ways that content providers can use IPv6 to distribute content to their customers over HTTP, as well as monitor the percentage of their users that are IPv6 capable, though they're a tad trickier than simply adding records to the DNS and turning on v6 in their servers. All of the above can help. However, - Yelling 6to4 is Evil as loudly as possible, e.g. declaring it Historic and publishing -historic, - Filtering protocol 41 packets, - Blocking 2002::/16 traffic or routing advertisements, or - Blocking 192.88.99.0/24 traffic or routing advertisements, will all make the situation worse for users, operators, and content providers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Meeting Materials for IETF 81
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why, one week before the beginning of the IETF meeting, is the Meeting Materials link not enabled on the web site? There was a discussion on this very mailing-list few months ago (what is the problem bis) that discussed about the productivity of WG sessions. I do believe that having the slides for the presentations posted ahead of time helps participants to understand the problem and focus on questions and discussion during the f2f, which makes for a better use of our time. Obviously not everybody agree with me, as it is common to see presentations uploaded few minutes before the presentation and even in at least one case, few hours after! - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4kTZYACgkQ9RoMZyVa61eGuACfZvEdmU+FcADkAcJ3TTOZF+xK KjMAnRRcQw1cmTMyixr2PFPDqbfw0+aB =J3+E -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Materials for IETF 81
In the meantime: https://datatracker.ietf.org/meeting/81/materials.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Materials for IETF 81
The link is now live. Alexa On Jul 18, 2011, at 8:13 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why, one week before the beginning of the IETF meeting, is the Meeting Materials link not enabled on the web site? There was a discussion on this very mailing-list few months ago (what is the problem bis) that discussed about the productivity of WG sessions. I do believe that having the slides for the presentations posted ahead of time helps participants to understand the problem and focus on questions and discussion during the f2f, which makes for a better use of our time. Obviously not everybody agree with me, as it is common to see presentations uploaded few minutes before the presentation and even in at least one case, few hours after! - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4kTZYACgkQ9RoMZyVa61eGuACfZvEdmU+FcADkAcJ3TTOZF+xK KjMAnRRcQw1cmTMyixr2PFPDqbfw0+aB =J3+E -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action. Why not just sign up for a standard phase-out plan? Don't we want 6to4 users to have any advanced notice that we plan to break their Internet? Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 3:30 PM, james woodyatt wrote: On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action. Why not just sign up for a standard phase-out plan? Don't we want 6to4 users to have any advanced notice that we plan to break their Internet? Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them? I don't understand the desire for a phase out plan when there's nothing better to phase in that's generally available. Preferring IPv4 to 6to4 makes sense. But filtering 6to4 traffic or its routing advertisements is a denial-of-service attack. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Noel, Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Monday, July 18, 2011 11:34 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu; v6...@ietf.org Subject: RE: Another look at 6to4 (and other IPv6 transition issues) From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)
On 2011-07-19 11:26, Erik Kline wrote: Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? I don't see any progress. We may just have to blacklist any resolvers that have 6to4 clients behind them and leave it at that. Why? How would that help anybody? What would help is following the steps in the -advisory document. (Discussing how many angels can dance on the head of an RFC certainly won't help either. Could we all stop now please?) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt (Applicability of Keying Methods for RSVP Security) to Informational RFC
The IESG has received a request from the Transport Area Working Group (tsvwg) to consider the following document: - 'Applicability of Keying Methods for RSVP Security' draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The document also discusses applicability of encrypting RSVP messages. The Responsible AD notes that the IPR declaration terms seem to apply to standards-track documents, but not necessarily to an Informational document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-security-groupkeying/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/988/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Second Last Call: draft-ietf-mpls-loss-delay-profile-03.txt (A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks) to Informational RFC
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' draft-ietf-mpls-tp-loss-delay-profile-03.txt as an Informational RFC This is a second last call. The last call is only necessary because of a late-received IPR disclosure. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC . The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] [RFC Editor, please replace with the RFC number assigned to draft-ietf-mpls-loss-delay.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-loss-delay-profile/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1583/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Third Last Call: draft-ietf-mpls-loss-delay-03.txt (Packet Loss and Delay Measurement for MPLS Networks) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' draft-ietf-mpls-loss-delay-03.txt as a Proposed Standard This is a third last call. The last call is only necessary because of a further late-received IPR disclosure. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1574/ http://datatracker.ietf.org/ipr/1584/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-karp-threats-reqs-03.txt (The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports) to Informational RFC
The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports' draft-ietf-karp-threats-reqs-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The Keying and Authentication for Routing Protocols (KARP) effort aims to overhaul and improve these mechanisms. This document has two main parts - the first describes the threat analysis for attacks against routing protocols' transports and the second enumerates the requirements for addressing the described threats. This document, along with the KARP design guide will be used by KARP design teams for specific protocol review and overhaul. This document reflects the input of both the IETF's Security Area and Routing Area in order to form a jointly agreed upon guidance. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Configuration Data Model for IPFIX and PSAMP' to Proposed Standard (draft-ietf-ipfix-configuration-model-10.txt)
The IESG has approved the following document: - 'Configuration Data Model for IPFIX and PSAMP' (draft-ietf-ipfix-configuration-model-10.txt) as a Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-configuration-model/ Technical Summary This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [RFC6020]. The configuration data is encoded in Extensible Markup Language (XML). Working Group Summary The mediation framework was added to the IPIFX charter in 2008. The document was discussed at all meetings since then and had several revisions. There was nothing special about this document. There is a strong consensus in the IPFIX WG to publish this version of the document. There are no particular issues in the document without strong consensus in the IPFIX WG. Document Quality The document underwent a WG last call in the IPFIX WG and a YANG doctor review. This way, a high document quality has been achieved already. Personnel Juergen Quittek is the Document Shepherd. Dan Romascanu is the Responsible Area Director. RFC Editor Note OLD: [W3C.REC-xml-20040204] Paoli, J., Maler, E., Yergeau, F., Sperberg-McQueen, C., and T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), World Wide Web Consortium FirstEdition REC-xml- 20040204, February 2004, http://www.w3.org/TR/2004/REC-xml-20040204 NEW: [W3C.REC-xml-20081126] Paoli, J., Yergeau, F., Sperberg-McQueen, C., Maler, E., and T. Bray, Extensible Markup Language (XML) 1.0 (Fifth Edition), World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, http://www.w3.org/TR/2008/REC-xml-20081126. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Terminology Used in Internationalization in the IETF' to BCP (draft-ietf-appsawg-rfc3536bis-06.txt)
The IESG has approved the following document: - 'Terminology Used in Internationalization in the IETF' (draft-ietf-appsawg-rfc3536bis-06.txt) as a BCP This document is the product of the Applications Area Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3536bis/ Technical Summary This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This document gives an overview of internationalization as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. Some of the overview is a somewhat tuturial in nature. It is not meant to be a complete description of internationalization. The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC. Some of the definitions in this document come from many earlier IETF documents and books. Working Group Summary Not surprisingly for a document such as this, there were many suggestions of terminology to include, and of alternative definitions to the ones included. The editors have done a good job of striking a necessary balance between an overly bloated document and one that includes the right set of terms, with definitions that reflect reasonable consensus, if not always unanimity. There were a number of such discussions, with none bearing particular mention here. Document Quality This document replaces RFC 3536, cleaning up and updating many of the definitions therein. RFC 3536 has been in use for eight years, and this document reflects that maturity and what we've learned about the gaps in the terminology and definitions over that time. Section 7 is a significant new section that talks about IDNA work done since RFC 3536. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Conclusion of FYI RFC Sub-series' to Informational RFC (draft-iesg-rfc1150bis-01.txt)
The IESG has approved the following document: - 'Conclusion of FYI RFC Sub-series' (draft-iesg-rfc1150bis-01.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-iesg-rfc1150bis/ Technical Summary This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. Working Group Summary This document is not the product of any IETF working group. Document Quality This document was discussed on the rfc-interest mail list. No one spoke against closure of the FYI sub-series on that mail list. Personnel Adrian Farrel is the Document Shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note Section 1 OLD: ... information that regarding the Internet and might be interesting to ... NEW: ... information regarding the Internet that might be interesting to ... --- Section 2 para 1: s/publishing/to produce/ --- Section 2, para 2 s/should be used/can be used/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-bankoski-vp8-bitstream-04.txt
The IESG has no problem with the publication of 'VP8 Data Format and Decoding Guide' draft-bankoski-vp8-bitstream-04.txt as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-bankoski-vp8-bitstream/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-bankoski-vp8-bitstream/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. Working Group Summary This document is not the result of any IETF Working Group. It is an Independent Stream submission to the RFC Editor. Personnel Robert Sparks shepherded the RFC5742 review. Note to the RFC Editor Per RFC5742: 1. The IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-2012: Results of Random Selection
Hi all, The following is the list of 10 Nomcom volunteers selected randomly from this list: https://datatracker.ietf.org/ann/nomcom/2991/ 118. Lianshu Zheng, Huawei Technologies; 35. Stephen Hanna, Juniper Networks; 100. Simo Veikkolainen, Nokia; 44. Sheng Jiang, Huawei Technologies Co. Ltd.; 84. Rifaat Shekh-Yusef, Avaya; 92. Pascal Thubert, Cisco; 1. Jaap Akkerhuis, NLnet labs; 99. Olivier Vautrin, Juniper Networks; 108. IJsbrand Wijnands, Cisco; 58. Dapeng Liu, China Mobile; Congratulations to everyone who got selected as a voting member. This begins the one week community review of the selection - please let me know ASAP if you see any problems with the selections. The challenge period will close at 23:59 EDT on Monday July 25, 2011. I am in the process of contacting the individuals to confirm they are still able to serve on the Nomcom. Once again, I would like to thank everyone who volunteered for the Nomcom and I hope you will continue volunteering in the years to come. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-ch...@ietf.org, suresh.krish...@ericsson.com NOTE: 76. Allyn Romanow, Cisco Systems was picked as 10th selection but had to be skipped due to the two members per affiliation restriction specified in Section 4 Rule 17 of RFC3777. Selection Details = Seed Values: The seed values used in selecting the committee members are follows: Canadian Lottery Lotto 649 Saturday July 16, 2011 Results: http://diffusion.loto-quebec.com/sw3/res/asp/index.asp?l=1pRequest=2cProduit=4 (7 numbers including the bonus number: numbers between 1 and 49) Value: 02 12 23 35 39 49 44 US National debt (Debt Held by the Public), published by the Treasury department as of Friday, July 15, 2011 http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 43838132 US National debt (Intragovernmental Holdings), published by the Treasury department as of Friday, July 15, 2011 http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 43531153 Euromillions Lottery Friday July 15, 2011 Results: http://www.europeanlotteryguild.com/lottery_results/euromillions_results/draw_history?results_date=2011-08-01 (7 numbers including the star balls: 5 numbers between 1 and 50 and 2 star balls between 1 and 11) Value: 06 26 33 34 39 03 04 With the selection algorithm results are based on RFC 3797 as follows: [suresh@beeblebrox nomcom11]$./nomcom Type size of pool: (or 'exit' to exit) Type number of items to be selected: (or 'exit' to exit) Approximately 62.1 bits of entropy needed. Type #1 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 2 12 23 35 39 44 49 Type #2 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 43838132 Type #3 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 43531153 Type #4 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 3 4 6 26 33 34 39 Type #5 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. Key is: 2.12.23.35.39.44.49./43838132./43531153./3.4.6.26.33.34.39./ indexhex value of MD5div selected 1 0DC9765D111926682972CDB0BE0D2F75 120 - 118 - 2 D6A71A7BA3B379743C7C2E86ED793FB4 119 - 35 - 3 FD440C774ED64A735F817DDB414D69FE 118 - 100 - 4 90DAB0968FC05AA4A3E854F88BE2CBF2 117 - 44 - 5 7CFDC92829037007F178BEA0FB2838C5 116 - 84 - 6 FF1B0A4C427822E41CFD7AA072F87483 115 - 92 - 7 0A2F3DD7A862AD8B7A99323DF747FB36 114 - 1 - 8 8F74E1BF0926172EE4907EDA97E8083A 113 - 99 - 9 50A198675A31BB4225AC3358265C1464 112 - 108 - 10 834B1152DF1E7FA6EA7C4C2C3B6AB625 111 - 76 - 11 19CF15ADFA7B364A20D498F64A5E1236 110 - 58 - 12 A23A41557BC2447A183BFBC32D8EEE92 109 - 104 - 13 700AA85DC4CAA77FC303B08E58B2F506 108 - 54 - 14 166E56A9AB07A49C4EC77EEBA9F6DE06 107 - 97 - 15 9F2F1498FD73BF4FA6C54382E217B5D6 106 - 90 - Done, type any character to exit. [suresh@beeblebrox nomcom11]$ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
