Re: MLTF meeting before IGF
Dear Ted, thank you for this. I should have added this note myself. At 05:56 03/10/2006, Ted Hardie wrote: Note that the information below pertains to a meeting which is not sponsored by or endorsed by the IETF.Participants should understand that the discussion of an Internet-Draft or a potential proposal for a later IETF working group does not imply that the IETF IPR policies, Note Well, appeal procedures, or other mechanisms apply to the discussion or the meeting. Correct. This mail was sent for information. There is ongoing work in the IETF in this area, in the LTRU working group (see http://www.ietf.org/html.charters/ltru-charter.html ). Interoperability with the WG-LTRU deliverables as well as with other standadization deliverables and processes, and with RFC 4690 suggestions is a priority. I obtained that RFC 4646 was eventually shaped according to that need. Yet, it is still to be enforced by the IETF (I also still wait for the promised expedited IESG response to the RFC 4647 appeal). jfc At 4:38 AM +0200 10/3/06, Jefsey_Morfin wrote: The MLTF project (Multilingual Internet Technical Forum) was initiated two years ago. It was delayed by the debate regarding the IANA Language Subtags and Extensions Registries. During that time, meetings were held in Versailles in order to guide an interoperability and innovation protection strategy. Today, the RFC 4646 has been published which matches our requirements and should support the IETF internationalization plane (however, its implementation still calls for attention). The MLTF core can now resume its endeavour towards the standardisation, development, documentation, testing, and industrial deployment assistance that was called for by the IGF for the multilingualisation of the Internet and the entire digital ecosystem. It was introduced at the ITU/UNESCO joint meeting in Geneva, and discussed at the ISOC EGENI meeting in Paris. It is one of the substantive contributions to the Athens IGF meeting http://intgovforum.org/Substantive_1st_IGF/e-mdrs-intro.pdf; http://intgovforum.org/Substantive_1st_IGF/e-mdrs-intro.pdf . An MLTF concertation meeting will be held in Versailles on 5 October 2006 and pursued in Athens (before the 1 November 2006 session). To attend the first meeting at the invitation of the Versailles Chamber of Commerce you must be registered for security reasons. A preparatory mailing list has been set-up that you can join by sending a mail to [EMAIL PROTECTED]. You will find information about this meeting at http://mltf.org/; http://mltf.org. Some of the key international technical partners of the Multilingual Internet governance will attend or will be represented. Several IETF Drafts for information will be discussed concerning the languages e-empowerment path, the multilingualisation of the Internet, a united model for the multilingual, multitechnology digital ecosystem, the place of the Internet in this model, the relations with its SSDOs and the interest of the proposition of an IETF WG-Multilingualisation for the IETF techhnology aspects. The organisation of the MLTF, the preparation of a Spring 2007 meeting, and the economic model, analysis, development, testing, ontology constitution, gathering, and maintenance, deployment of a multilingual distributed referential system (MDRS) are all on the agenda. The priority is to permit ISO 11179 conformant crosswalk interoperability with the IANA registries - once they have stabilised - as well as with the other Language codes, standards, and services. This should be achieved through the MDRS langroot. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MLTF meeting before IGF
Ted Hardie wrote: Note that the information below pertains to a meeting which is not sponsored by or endorsed by the IETF. Participants should understand that the discussion of an Internet-Draft or a potential proposal for a later IETF working group does not imply that the IETF IPR policies, Note Well, appeal procedures, or other mechanisms apply to the discussion or the meeting. There is ongoing work in the IETF in this area, in the LTRU working group (see http://www.ietf.org/html.charters/ltru-charter.html ). If anyone discovers evidence that there is another person participating in the MLTF apart from Jefsey, that would be interesting. so far, all the evidence I've seen seems to indicate that it's an one-man show. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On 3-okt-2006, at 0:20, Fred Baker wrote: This is also a good way forward, and it has the advantage that it's more general than my suggestion which requires changes to the client protocol. I would suggest that a key in the list actually has two timestamps (virtual or actual) associated with it - a point in time where the sender should start using it, and a point in time at which the key should be deleted from the list (eg neither send nor accept). I don't quite see what happens when the new key isn't present on both systems and timestamps start to expire, but that should be solvable in one way or another. Suggestion: don't start sending ALL traffic with all keys, just throw in a copy of a packet signed with the new key once in a while and keep using just the old key for most traffic until a packet with the new key is received from the other side. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. Thanks for the plug, Mike :-) Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Tue, Oct 03, 2006 at 01:00:14PM +0200, Brian E Carpenter wrote: If that's indeed the case, the first order of business needs to be to document current practice. I see no chance of making forward progress on actual changes without first having a consensus as to what our current state is. Brian Carpenter has written draft-carpenter-rfc2026-critique-02.txt which does exactly that, and he has repeatedly solicited comments on it. If you think that it would be helpful to have it published as an informational RFC before undertaking to make normative changes to our standards procedures, please say so. Thanks for the plug, Mike :-) Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. silence is NOT consent. Its silence. to be SURE, i'd wait till you had actually expressions of support. but, i'm not you am i? :) --bill Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On Oct 3, 2006, at 3:36 AM, Iljitsch van Beijnum wrote: I don't quite see what happens when the new key isn't present on both systems and timestamps start to expire, but that should be solvable in one way or another. The purposes of the TCP-MD5 protocol is to ensure that two TCPs that don't have the same keys can't communicate. I think it accomplishes that, sooner or later. Your concern is that it might be too frisky getting there. I'm proposing that you be in control of how quickly you get there by how you set the delete timer. Suggestion: don't start sending ALL traffic with all keys, just throw in a copy of a packet signed with the new key once in a while and keep using just the old key for most traffic until a packet with the new key is received from the other side. Well, one approach to my optimization would be start sending all new traffic with the new key, but retransmit with the old key. That *does* require at least an operational change to the protocol implementation, although not a change to the protocol itself. It also means that during the period that only Alice thinks there are two active keys, we can't move very quickly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MLTF meeting before IGF
--On Monday, 02 October, 2006 20:56 -0700 Ted Hardie [EMAIL PROTECTED] wrote: Note that the information below pertains to a meeting which is not sponsored by or endorsed by the IETF. Participants should understand that the discussion of an Internet-Draft or a potential proposal for a later IETF working group does not imply that the IETF IPR policies, Note Well, appeal procedures, or other mechanisms apply to the discussion or the meeting. There is ongoing work in the IETF in this area, in the LTRU working group (see http://www.ietf.org/html.charters/ltru-charter.html ). To carry this one step further, my recollection is that the AUP for the IETF list prohibits non-IETF meeting announcements and other advertising. Sergeants at arms, please take note. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On 3-okt-2006, at 13:41, Fred Baker wrote: The purposes of the TCP-MD5 protocol is to ensure that two TCPs that don't have the same keys can't communicate. I think it accomplishes that, sooner or later. Your concern is that it might be too frisky getting there. I'm proposing that you be in control of how quickly you get there by how you set the delete timer. Well, sure, if your intent is to make sure you stop communicating with your peer when they don't implement a new key, that will certainly work. My concern is the case where this happens by accident because of some operator error or miscommunication between the two ASes involved. What happens today in this case is that the session goes down immediately after the operator configures the new key. This means the issue can be resolved rightaway. In a system where old keys are retired at some point in time AFTER the configuration change, it's much harder to resolve any issues. This is made worse by the fact that the time when the problem occurs can't be predicted reliably: you never know whether your timestamp will determine the change or the one set by the other side, and if the other side didn't put in the right key they could also very easily have put in the wrong timestamp, even without NTP or timezone problems. So I think most operators would prefer to do a key rollover where the old key remains valid indefinitely and is removed manually rather than automatically after some time. Suggestion: don't start sending ALL traffic with all keys, just throw in a copy of a packet signed with the new key once in a while and keep using just the old key for most traffic until a packet with the new key is received from the other side. Well, one approach to my optimization would be start sending all new traffic with the new key, but retransmit with the old key. This is exactly the kind of complexity that is best avoided... It would be much better to have the key rollover mechanism function autonomously without having to be aware of higher layer state. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MLTF meeting before IGF
On Tue, Oct 03, 2006 at 08:07:15AM -0400, John C Klensin wrote: To carry this one step further, my recollection is that the AUP for the IETF list prohibits non-IETF meeting announcements and other advertising. Sergeants at arms, please take note. Noted, and since there is a PR-action active against Mr. Morfin, and since this is a clear violation of RFC 3005: Inappropriate postings include: - Announcements of conferences, events, or activities that are not sponsored or endorsed by the Internet Society or IETF. Mr. Morfin will be banned from posting to the IETF list under the auspices of RFC 3683. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On Oct 3, 2006, at 5:19 AM, Iljitsch van Beijnum wrote: So I think most operators would prefer to do a key rollover where the old key remains valid indefinitely and is removed manually rather than automatically after some time. Somehow I can't imagine any real implementation NOT having this capability. So you set the delete timer for next year... You're in control of it. I guess I'm making a suggestion, and if it is not reasonable then Steve and his working group have to decide that. You raised a concern, that the roll-over procedure could cause unintended outages. I suggested an approach that doesn't cause unintended outages and puts you in control of what your network does. What it sounds like you're arguing for is turning the procedure off, doing the change manually with the other operator on the phone, and taking the outage when if happens. If that is indeed what you want, then I think you want a nerd-knob that will allow you to choose your destiny by turning the procedure off. For the rest of the world, I can think of folks that change keys on a daily or weekly basis, or at least tell me they do, and are really in hope of a way to automate that in a reliable fashion. I think Steve is trying to accomplish that for them; I certainly am. Yes, by the way - the folks I'm thinking of are indeed concerned that equipment that used to be under their control might become available to someone else. In such a case, they would prefer that the keys be destroyed and that communication cease. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. You asked. Your critique itself has its pluses and minuses. On the plus side you've at least identified some of the issues that have made the document a little long in the tooth, like ASes, RFC Editor text, standard levels, interoperability reports, IPR etc. However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. Here are specific comments about your section by section critique: I think you've misinterpreted section 3.3, which discusses levels of requirements for standards themselves, not individual components of TS documents. But beyond this one has to question the whole notion of requirement levels such as those in that section. Why should they be there at all? The IETF has no force of authority other than moral, and people are not going to write code -- or support it -- for the sake of the IETF's moral authority. Similarly the discussion regarding Independent RFCs. We don't need to critique the words since the IAB RFC Editor are working on an update. Let's go critique THOSE words. You document the broken rather than fix it. See, for instance, your commentary about PS. You yourself call out confusion regarding STDs only being assigned at PS. However, at least RFC2026 is self consistent. In addition, I would actually affirm some of the general intent that A Technical Specification is any description of a protocol, service, procedure, convention, or format. I think implementable and testable are laudable goals (;-) but the way we test both is through operational experience, which is why we had the standards levels in the first place. IN PRACTICE, many standards are implemented well before they get through the IESG process, and so Internet-Drafts are largely serving the purpose of PS. Although STD1 is rarely updated it should still be so. One reason is that the web is a horrible historical medium for determining what the status of a standard WAS at in a particular time period. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-carpenter-rfc2026-critique-02.txt (was: As Promised, an attempt at 2026bis)
On Tue, 3 Oct 2006, Brian E Carpenter wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. I've read the document a couple of times, and it appears to me to be reasonably accurate. On Tue, 3 Oct 2006, Eliot Lear wrote: However, you have missed the forest from the trees. The fundamental description of how we behave as an organization is lost in a section by section critique. It would have been better for you to update RFC 2026 with an appendix explaining the changes and why they are necessary to reflect reality. Oh wait. I've done (or at least begun) that. I, too, would prefer to see an update to 2026 that brings it into conformance to current practice. However, Eliot's draft goes well beyond that by proposing substantive changes to current practice, and those proposed changes seem to be quite controversial. In the absence of an update proposal that has community consensus, I think it would be useful to have a description of how 2026 diverges from current practice. So I would encourage Brian to attempt to publish draft-carpenter-rfc2026-critique-02.txt as an information RFC. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
--On Tuesday, 03 October, 2006 13:00 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Quite seriously - am I to conclude from the absence of comments on that draft that everyone agrees that it correctly describes current practice? If so, I'll look for an AD to sponsor it. Brian, As I suggested at the Montreal plenary, I believe that the majority of the community has reached a state of exhaustion on all but the most critical and pressing process issues (and maybe on those). If that hypothesis is correct, real consensus (positive or negative) about such proposals is likely to be impossible. The folks who still care about process issues and are not burned out will speak up and the folks who are afraid of unintended consequences despite being exhausted will speak up (but perhaps only on Last Call). The vast majority of the community will be silent, not because they are not impacted or don't care (although some will fall into both of those categoris) but, for the rest, because of general exhaustion with one process battle after another. The reactions to both Eliot's and Scott's 2026bis draft (in-depth comments and discussion from the usual process activists, plus comments from others when something they consider outrageous is said) and to your 2026 critique (mostly silence) could be attributed, not to agreement by everyone else, but to that exhaustion factor. Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
John, Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. As said in my note sent on 2006-08-10, my conclusion after Montreal was essentially the same as yours: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. My intention is to use the current list discussion to confirm or refute this conclusion. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
--On Tuesday, 03 October, 2006 17:21 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: John, Or, perhaps I'm completely wrong about the sense of the community. But I would suggest and ask that, before any more of these documents are pushed or Last Called, you try to determine the degree to which the community just does not want to deal with these issues for a while. As said in my note sent on 2006-08-10, my conclusion after Montreal was essentially the same as yours: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. And that was why I was a bit surprised to see you suggesting finding an AD to sponsor, and presumably Last Call, your draft. My intention is to use the current list discussion to confirm or refute this conclusion. Good. If we disagree, it is only on what a formal change constitutes. I would consider an in-depth summary of what is wrong with 2026 (at least on any basis other than a personal informational opinion piece) and any attempt to replace 2026 with a version that reflects current practice to be such formal changes, if only because they would require almost the same level of effort in review and consensus-finding as actually changing the process. But some might disagree. thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As Promised, an attempt at 2026bis
On Tuesday, October 03, 2006 11:27:36 AM -0400 John C Klensin [EMAIL PROTECTED] wrote: Good. If we disagree, it is only on what a formal change constitutes. I would consider an in-depth summary of what is wrong with 2026 (at least on any basis other than a personal informational opinion piece) and any attempt to replace 2026 with a version that reflects current practice to be such formal changes, if only because they would require almost the same level of effort in review and consensus-finding as actually changing the process. But some might disagree. As I start to write this, I've read through a little more than half of Brian's draft; I stopped when I found something to comment on. What I'm seeing is descriptive, not prescriptive - it describes ways in which RFC2026 differs from what we actually do, offers interpretation based on current practice, and so on. I think a document like that, taken as a non-normative description rather than a specification, could be useful operationally. People who read RFC2026 without being familiar with current practice are likely to be rather confused, and Brian's draft clears up many of the possible confusions and offers additional commentary that may be useful in understanding what goes on. I assume that a document like this would be published as an informational document, without the benefit of IETF consensus and possibly without even a Last Call (there is _nothing_ that says Informational documents need a last call, and they are frequently published without one). I wouldn't have a problem with that, and in fact, it's probably best that this _not_ be an IETF consensus document if it is to serve a useful purpose. Now, the thing I found to comment on. Brian writes the following about the last paragraph of section 4.2.2: This presumably means outside of the IETF process not outside of the Internet community. As part of this year's RFC Editor RFP process, clarity is being sought about the independent submissions track, which should probably not be discussed at all in the basic definition of the standards process. See [I-D.klensin-rfc-independent] for a more current description. Actually, I think the section means what it says, and is referring _not_ to independent submissions but to cases where a specification developed elsewhere is republished as an RFC to make it more readily available to the Internet community. For example, we do this on a fairly regular basis with the specifications of cryptographic hash functions. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On 3-okt-2006, at 15:07, Fred Baker wrote: So I think most operators would prefer to do a key rollover where the old key remains valid indefinitely and is removed manually rather than automatically after some time. Somehow I can't imagine any real implementation NOT having this capability. So you set the delete timer for next year... You're in control of it. That sounds good, especially if the default is infinity. I guess I'm making a suggestion, and if it is not reasonable then Steve and his working group have to decide that. I don't think Steve has a working group for this. What it sounds like you're arguing for is turning the procedure off, doing the change manually with the other operator on the phone, and taking the outage when if happens. You mean like how things are done today? (-: Actually I proposed something else in my original message in this thread and also earlier in a message to Steve, on the NANOG list IIRC: have BGP speakers announce to the other side that they have a new key along with a hash over the key and when both sides have the same new key, do the rollover without delay. This means the rollover always happens when the new key is configured on the second end but only if the keys match. In any situation where it's possible that both ends set up different keys, I believe it's important to have the resulting outage happen immediately rather than later. BGP already provides plenty of ways to shoot yourself in the foot, we should take care not to introduce new ones. I can think of folks that change keys on a daily or weekly basis, or at least tell me they do, and are really in hope of a way to automate that in a reliable fashion. Well, my expience is pretty much the opposite: in the commercial ISP world here in Europe, key changes are rare. Nevertheless, reliable is the operative word here. If a key change is required this often, wouldn't it make more sense to protect the BGP session with IPsec? That is vastly superior to TCP- MD5 in all respects other than ease of initial setup. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On 3-Oct-2006, at 14:17, Iljitsch van Beijnum wrote: Well, my expience is pretty much the opposite: in the commercial ISP world here in Europe, key changes are rare. ISC has deployed (I think) almost 40 nodes of F now across six continents, and there's peering at pretty much all of those locations. That adds up to a fair number of sessions. Those who look after those nodes now on a daily basis might report different recent experience, but when I was doing that work I don't believe I ever saw a request from a peer to change a key on a working session. So, your experience in Europe matches my experience in Europe, Asia, North America, South America, Australasia and Africa. Having said that, I certainly support the idea that changing keys is a good idea, so long as people continue to use the TCP MD5 option on their BGP sessions. Mechanisms to make it easier to change keys are surely a good idea in that context. Whether or not the TCP MD5 option is worth using at all is a different question. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
67th IETF - Hotels
San Diego is approaching fast! One problem with the upcoming event in San Diego is that the city will be under siege of a citywide convention. This means hotel rooms are very scarce and immediate action should be taken: It is strongly suggested that you book your rooms now. Here are some suggestions to help you with your accommodations: 1. Keep checking with the main hotels (Sheraton and Hilton). While the IETF block is technically full, the hotels may still be taking reservations. Also it is typical for some rooms to be cancelled resulting in additional openings. Given the island setting of this venue, it would be best to be on the island. 2. Overflow hotels have been arranged and are within five miles (15 minutes by cab). All have agreed to favorable rates especially given the high demand for the rooms. Information on two additional hotels has been added to the IETF website: http://www.ietf.org/meetings/67-hotels.html. We will continue to update the site as more hotel rooms are secured. 3. Travelocity, Expedia and Orbits all show rooms that are available. Please act now, as rooms will become harder to get and a lot more expensive as we approach the meeting. Also for those of you who have not attended this event in San Diego in the past, our main venue is on an island so the longer you wait the farther away you will be. REMINDER: Early-Bird registration cut-off is Friday, October 27, 2006. You can register for the IETF Meeting at: http://www.ietf.org/meetings/67-IETF.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
