Re: Appeals, post-appeal discussions, DoS attacks on the IETF, and the depth of turtles
--On Monday, 24 July, 2006 07:07 +0200 Frank Ellermann [EMAIL PROTECTED] wrote: John C Klensin wrote: I commend draft-carpenter-ietf-disputes-00 as an attempt to rethink this area. People who are interested in this topic should probably study it. Yes, it's interesting. With a mandatory attempt of peaceful settlement, probably a good idea. But I won't subscribe to | Participants in the IETF are deemed to agree to these | procedures in full and final settlement of such disputes. Yes, that one bothered me too, perhaps for different reasons and perhaps not. From my point of view, there has to be an opportunity for a more judicial/ legalistic process somewhere. If we want to see appeals as part of a cooperative, potentially multi-step, reconsideration model, then it becomes even more important to move the judicial proceedings elsewhere. And trying to ban them simply won't work, although I would predict that someone who resulted to the courts and lost would find him or herself rather throughly shunned in the IETF thereafter... not as a matter of procedure or rule, but as a matter of predictable human behavior and reactions. Also interesting is deciding to issue a Last Call cannot be the subject of the DRP. That misses the point of a decision NOT to issue a last call, e.g. whith the known caee of two mutually exclusive documents. So that clause is no progress in relation to 2026, it's only clearer. I tend to agree on this too, or at least I think I do. I don't see it as desirable to permit appeals on the decision to issue a Last Call, since I believe that the IESG should be able to Last Call substantially anything to get clear community input. But I believe that, in general, if an AD, or the IESG, as a whole, is asked to issue a Last Call and declines to do so, that decision should be subject to appeal. And, if the IESG wants to see that in general narrowed --as I think it should be-- then they should be generating, or convincing someone else to generate-- a clear statement about the conditions under which Last Calls will and will not be issued and get community consensus behind that statement. ... draft-klensin-recall-rev-00 (long expired) was intended to make it easier for the IAB or IESG to identify problems in their own environment that were linked to individuals and initiate a community process to solve them. s/community/Nomcom eligible/ - the recall stuff is restricted to the paying members. There are two issues in this. The first is that we have active participants (and contributors) in the IETF who do not attend meetings. There were good reasons to exclude them from Nomcoms, but it is less clear that they should be excluded from recall activities... Except that it is hard to identify them in a clear way and that, rather than paying was an important reason for the Nomcom criterion The second and far more important, IMO, is that, at present, members of the IAB and IESG --who pay with not only registration fees but with considerable time devoted to the IETF -- cannot participate in requesting a recall because they cannot serve on Nomcoms. Their exclusion from Nomcoms was intended to prevent a number of obvious possible abuses, but it is not clear that the same principles apply to recall petitions. My own belief is that, when the Nomcom eligible rule was applied to recalls, the IAB and IESG members were excluded as an unintended side-effect. Certainly I recall no community discussion about whether that exclusion was wise and/or necessary. What that draft proposed was eliminating the restriction. draft-klensin-chair-empowerment-01 Apparently not yet available, looking into -00: A duel, good idea. Add an enforced delay, a week or so, it's too easy to do something stupid. A delay would probably be a good idea, but I don't see an obvious way to start the timer. I suppose the Chair could propose that action to the Nomcom Chair and the Nomcom Chair could wait a week before doing anything, then ask the Chair if he or she was still serious and notify the relevant IESG member to see if any other action was likely to be forthcoming before presenting the question to the Nomcom. Is that what you had in mind? john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
That's part of the problem, sponsorship should be managed from a different perspective, and totally decoupled from the venue itself. IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. At this way the main costs (meeting rooms, AV, secretariat, etc.), are covered in a fair and planned way, and not dependant on each meeting itself. Also this provides the IAD the budget ahead so can book the most convenient venues at least 18 months up-front, and allow a cost reduction for both IETF itself, and attendees which can get better traveling deals and more time for those that need to request an authorization to their management, etc. Regards, Jordi De: YAO Jiankang [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Jul 2006 11:31:56 +0800 Para: John L [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions - Original Message - From: John L [EMAIL PROTECTED] To: YAO Jiankang [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 18, 2006 10:34 AM Subject: Re: Meetings in other regions I do think there is considerable merit in identifying a set of venues that are known to do a good job and using them whenever a meeting is scheduled for their part of the world. Minneapolis is roughly in the middle of the populated part of North America, the hotel knows us, why not go back there? it seems boring that everytime we go to the same venue. Not to put too fine a point on it, but if you don't find IETF meetings to be exciting enough on their own merits, it's OK if you don't go. Why not kill two birds with a stone? after enjoying the nice merits of the IETF meeting, you can appreciate the different life in the different cities at the weekend. It is also unfair to those who traveled from other regions such as europe and asia. I said whenever a meeting is scheduled for their part of the world. When it's time for a meeting in North America, hold it in Minneapolis. If we find similarly reliable venues in Europe or Asia, use them when the meetings are in those parts of the world. Every IETF meeting is sponsored by the different companies. The sponsors normally love holding the meeting in the local city where the sponsor is located. Even you and me agree that the meeting is held in the same city, the sponsor may disagree. R's, John ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeals, post-appeal discussions, DoS attacks on the IETF, and the depth of turtles
John C Klensin wrote: [DRP excl. last calls] in general, if an AD, or the IESG, as a whole, is asked to issue a Last Call and declines to do so, that decision should be subject to appeal. And, if the IESG wants to see that in general narrowed --as I think it should be-- then they should be generating, or convincing someone else to generate-- a clear statement about the conditions under which Last Calls will and will not be issued and get community consensus behind that statement. Yes, they need something against bogus (or malicious) last call requests. That something would have the same DoS protection as the proposed 'dispute resolution process'. [active participants for the recall procedure] it is hard to identify them in a clear way [...] IAB and IESG members were excluded as an unintended side- effect. Maybe - if you intend to revive that draft - you could add all (co-) authors of n or more standards track documents, for an n covering all past and present IAB and IESG members. [duel draft] the Nomcom Chair could wait a week before doing anything, then ask the Chair if he or she was still serious and notify the relevant IESG member to see if any other action was likely to be forthcoming before presenting the question to the Nomcom. Is that what you had in mind? Yes, maybe as explicit right. If the IETF or IESG Chair added Cc: ietf@ietf.org or similar it's hopeless, no further delay, they have to shoot it out. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IANA, Unicode, and the multilingual Internet
At 04:05 06/07/23, JFC Morfin wrote: 4.3. IANA registries. In the case of IANA registries there is no market alternative [we saw that in the alt-root case]. The control of a IANA registry can therefore be strategic. Until now the IANA had three main areas: numbers, names, protocol parameters. The numbers/names are pure Internet issues but were considered sensible enough to be delegated to ICANN. The new area of languages This is not a new area. IANA has managed a language tag registry since around 1995 (see RFC 1766). But it is important to note that IANA just registers language tags (or since recently, language subtags), not languages. is not an Internet issue, RFC 1766, RFC 3066, as well as its approved successors (draft-ietf-ltru-registry, draft-ietf-ltru-initial and draft-ietf-ltru-matching) only deal with language tags on the Internet. It is difficult to understand how language tagging on the Internet would not be an Internet issue. is far more important and sensible than names and numbers, I wouldn't be co-chair of the LTRU WG if I wouldn't believe that language tagging is important, but there are far more important issues (it's e.g. easy to show that 'charset' tagging is much more important than language tagging, because the consequences of failures are much greater). Also, I agree that language tagging occasionally can be a sensible issue (a look at the [EMAIL PROTECTED] mailing list would definitely give that impression), but by and large, most language tags are used in practice without any problems. and is de facto [this is what I object] delegated to UNICODE. It's difficult to object to something that isn't the case. The language subtag registry is de facto delegated to ISO (for language codes, country codes, and script codes) because the IANA registry (except for blunders by ISO that we hope they won't make anymore) just reflects the relevant ISO standards. Of the above three kinds of codes, language codes are obviously the most important (no language tag without a language code), and script codes are the least important (most language tags don't need a script code). The Unicode consortium is designated as the for registration authority for script codes. But this doesn't mean that they can assign new script codes at will; ISO 15924 (see e.g. http://www.unicode.org/iso15924/standard/) describes that new codes need at least four positive votes from the six voting members of the Joint Advisory Committee. Only one of these members is from the Registration Authority (Unicode), all the others are from other, ISO-related, organizations. The IETF is obviously not prepared to this kind of fundamental conflict. In order to talk about whether the IETF is prepared for a certain kind of conflict, we first would need to know what kind of conflict this is. But I can't find any fundamental conflict in the paragraph above. 5. IETF strategy. There are cases where a possible solution is a significant change of the IETF, or even to kill the IETF itself. The conflict I am engaged into, is certainly of that nature. RFC 3935 gives IETF leaders the capacity to address such situations, except when the opposed option is defended by one/several IETF leaders. We should not consider that such conflicts are exceptional: the lack of architectural guidance by the IAB raises several other issues. After the Multilingual Internet, what about the multilateral, the multitechnology, etc. support? There are two ways to understand Multilingual Internet above. One is that the Internet is already to the most part multilingual: There are Web pages in a large number of langugages, emails are sent around daily in a similar number of languages, and so on, and some of the remaining issues, mostly in the area of identifiers, are either on the verge of being fully deployied (IDN) or at least work has started (internationalized email addresses). The other way to understand Multilingual Internet is that the Multilingual Internet is something completely different from what we have now, much more multilingual for the end user, or whatever. But while we have heard much buzzwording about that, we haven't seen any of that in any actual kind, shape, or form, nor have we actually been told what it's going to look like, or how it's going to be better than what we have now (see previous paragraph). So it's vaporware even by the standards of vaporware. A similar analysis can be made for multilateral and multitechnology above. Of course the Internet is multilateral, it allows multiple parties to communicate with each other. Of course it is multitechnology, on many levels (from the physical and link layer up to the applications layer). Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org
Re: Meetings in other regions
JORDI PALET MARTINEZ wrote: That's part of the problem, sponsorship should be managed from a different perspective, and totally decoupled from the venue itself. IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. As you know Jordi local sponsors have historically been invaluable in getting access to local resources, like network connectivity and handling the logistics of network setup. having local support is always better than not having it. At this way the main costs (meeting rooms, AV, secretariat, etc.), are covered in a fair and planned way, and not dependant on each meeting itself. Some costs. E.G. connectivity are in fact highly dependant on the meeting location. You whole budget takes a bath the first time you have to sign a 12 month lease with the ptt/ilec on an e/ds-3 to get connectivity into a venue. Do you then go back to that venue for the next meeting because you're still paying $8000 a month for the circuit? Also this provides the IAD the budget ahead so can book the most convenient venues at least 18 months up-front, and allow a cost reduction for both IETF itself, and attendees which can get better traveling deals and more time for those that need to request an authorization to their management, etc. Regards, Jordi De: YAO Jiankang [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Jul 2006 11:31:56 +0800 Para: John L [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions - Original Message - From: John L [EMAIL PROTECTED] To: YAO Jiankang [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 18, 2006 10:34 AM Subject: Re: Meetings in other regions I do think there is considerable merit in identifying a set of venues that are known to do a good job and using them whenever a meeting is scheduled for their part of the world. Minneapolis is roughly in the middle of the populated part of North America, the hotel knows us, why not go back there? it seems boring that everytime we go to the same venue. Not to put too fine a point on it, but if you don't find IETF meetings to be exciting enough on their own merits, it's OK if you don't go. Why not kill two birds with a stone? after enjoying the nice merits of the IETF meeting, you can appreciate the different life in the different cities at the weekend. It is also unfair to those who traveled from other regions such as europe and asia. I said whenever a meeting is scheduled for their part of the world. When it's time for a meeting in North America, hold it in Minneapolis. If we find similarly reliable venues in Europe or Asia, use them when the meetings are in those parts of the world. Every IETF meeting is sponsored by the different companies. The sponsors normally love holding the meeting in the local city where the sponsor is located. Even you and me agree that the meeting is held in the same city, the sponsor may disagree. R's, John ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ 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: netwrk stuff
-Original Message- From: Douglas Otis [EMAIL PROTECTED] Sent: Jul 24, 2006 7:24 AM To: todd glassey [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Subject: Re: netwrk stuff On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote: The question as to why that initiative's process was stalled would have to be answered to be fair. One would have to take into consideration whether the underlying technologies were the issue, those undertaking the effort abandoned it, or whether it was the WG and AD who had failed to properly marshal their WG Vetters to complete this effort. The completion of documents, and the closing of WGs remains within the competence of the IETF. Beyond describing the intended use and the vetting initially achieved, there is little benefit derived revisiting a document unless a change is required. How so ? - this is a statement of objectivity or the lack of it more accurately. When a change is required, the affected document should be marked as updated or replaced, where again the intended use and the vetting initially achieved should once again be noted. There may be issues with that. One of the things that the IETF has not dealt with is the use of the IETF's processes as weapons against others with less presence or power within the IETF WG's - the problem is that not everyone here is a nice-person - some are actually really bad people who are here intentionally to screw others who don't agree with them or who have opinions that are dangerous to initiatives or the the political framework of the IETF. Bluntly the IETF has grossly failed in being either Open or Fair and Frank these Ar what need to be addressed. The IETF's processes are best described as a twisted-fantasy through loophole land. They don't serve to make standards honest and fair but rather impossible for a mere mortal to participate with and that is more offensive to the world than the nasty language I used in describing the failures of this and the previous IETF's in coming to grips with what the IETF has become - a haven for career standards participants who need to be somewhere to justify their status within their sponsors. Designations of Experimental seems to be an indication of a vetting level. BCP versus Information also seems to be an indication of a document having undergone different vetting. Clarify the initial vetting (the related confidence the organization is willing to initially signify). This clarification can be conveyed by noting the intended use. Conveying how popular a particular document has become in subsequent years has proved either outside the competence or the concern of the IETF. While as a matter of pride the IETF may wish to place accolades upon popular documents, such efforts will likely be a distraction and provide little benefit. These efforts could be seen as attempting lead the parade by running in front of the crowd. While popular documents are indicative of having done a good job, very few documents involving popular use remain static. Since the IETF has said it needs to be smart about what projects and initiatives it undertakes, then it should want as much assurance up-front as possible. That said when a formal project is proposed it should be well enough defined and documented, and have commitment formally from those who are the core of the Initiative's Vetting Team. ... Is there some benefit derived revising documents where the intended use has not changed? Those deploying applications based upon these documents will separately publish their own conclusions by way of call-outs. The IETF has made the call-out process difficult, and this should be improved. I think the way to address whether deprecation is some level of use in the world. Set a use minimum for any protocol - and anyone that falls below that use level - is deprecated. This way the IETF active standards track the Internet's tastes and desires since it is the Internet that the IETF is to track... But rather would need other than true deprecation - lets just change their names to Reference and Active Standards. Reference are any non-active Standards. Active Standards are those that are voted (did I really say that?) by the IESG to track the Industry's use. This seems to suggest competency and popularity are synonymous. There should be at least four levels maintained by industry when using these documents. 1) Current (development) 2) Stable (production) 3) Deprecated (still supported) 4) Obsolete (not supported) Current is simply the latest. This output may never become designated as being Stable. Stable indicates few issues are unresolved by several implementations. Deprecated indicates modes or features will no longer be supported in future versions. Obsolete indicates that interchange is no longer assured. It seems the industry and not the IETF should make these classifications. The results of interchange testing is the determining factor and
Re: Meetings in other regions
Joel... Wow - what can U say... This is an issue because of the gross incompetence of an entity who is set up to propagate problems so that it will have something to work on... I bet the management of the IETF finds that comment as offensive as I find their incompetence in these matters. The IETF should submit a RFP for a service provider to take this over for any and all meetings held in... This is a problem for the IETF because of the gross failure of the IETF's organizers to get it... Sorry but having been the specific person responsible for raising money for supporting the meetings of the American Bar Association's Information Security Committee and haveing been a promoter for musical and other theatrical events in past-incarnations, I speak from first hand knowledge... Bluntly the reason the IETF has so many problems with its meetings is not the IETF but the people organizing them and their level of expertise in negotiating T'sC's as well as their operating costs as the IETF. Todd -Original Message- From: Joel Jaeggli [EMAIL PROTECTED] Sent: Jul 24, 2006 7:28 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Meetings in other regions JORDI PALET MARTINEZ wrote: That's part of the problem, sponsorship should be managed from a different perspective, and totally decoupled from the venue itself. IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. As you know Jordi local sponsors have historically been invaluable in getting access to local resources, like network connectivity and handling the logistics of network setup. having local support is always better than not having it. At this way the main costs (meeting rooms, AV, secretariat, etc.), are covered in a fair and planned way, and not dependant on each meeting itself. Some costs. E.G. connectivity are in fact highly dependant on the meeting location. You whole budget takes a bath the first time you have to sign a 12 month lease with the ptt/ilec on an e/ds-3 to get connectivity into a venue. Do you then go back to that venue for the next meeting because you're still paying $8000 a month for the circuit? Also this provides the IAD the budget ahead so can book the most convenient venues at least 18 months up-front, and allow a cost reduction for both IETF itself, and attendees which can get better traveling deals and more time for those that need to request an authorization to their management, etc. Regards, Jordi De: YAO Jiankang [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Jul 2006 11:31:56 +0800 Para: John L [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions - Original Message - From: John L [EMAIL PROTECTED] To: YAO Jiankang [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 18, 2006 10:34 AM Subject: Re: Meetings in other regions I do think there is considerable merit in identifying a set of venues that are known to do a good job and using them whenever a meeting is scheduled for their part of the world. Minneapolis is roughly in the middle of the populated part of North America, the hotel knows us, why not go back there? it seems boring that everytime we go to the same venue. Not to put too fine a point on it, but if you don't find IETF meetings to be exciting enough on their own merits, it's OK if you don't go. Why not kill two birds with a stone? after enjoying the nice merits of the IETF meeting, you can appreciate the different life in the different cities at the weekend. It is also unfair to those who traveled from other regions such as europe and asia. I said whenever a meeting is scheduled for their part of the world. When it's time for a meeting in North America, hold it in Minneapolis. If we find similarly reliable venues in Europe or Asia, use them when the meetings are in those parts of the world. Every IETF meeting is sponsored by the different companies. The sponsors normally love holding the meeting in the local city where the sponsor is located. Even you and me agree that the meeting is held in the same city, the sponsor may disagree. R's, John ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of
Re: netwrk stuff
On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote: The question as to why that initiative's process was stalled would have to be answered to be fair. One would have to take into consideration whether the underlying technologies were the issue, those undertaking the effort abandoned it, or whether it was the WG and AD who had failed to properly marshal their WG Vetters to complete this effort. The completion of documents, and the closing of WGs remains within the competence of the IETF. Beyond describing the intended use and the vetting initially achieved, there is little benefit derived revisiting a document unless a change is required. When a change is required, the affected document should be marked as updated or replaced, where again the intended use and the vetting initially achieved should once again be noted. Designations of Experimental seems to be an indication of a vetting level. BCP versus Information also seems to be an indication of a document having undergone different vetting. Clarify the initial vetting (the related confidence the organization is willing to initially signify). This clarification can be conveyed by noting the intended use. Conveying how popular a particular document has become in subsequent years has proved either outside the competence or the concern of the IETF. While as a matter of pride the IETF may wish to place accolades upon popular documents, such efforts will likely be a distraction and provide little benefit. These efforts could be seen as attempting lead the parade by running in front of the crowd. While popular documents are indicative of having done a good job, very few documents involving popular use remain static. Since the IETF has said it needs to be smart about what projects and initiatives it undertakes, then it should want as much assurance up-front as possible. That said when a formal project is proposed it should be well enough defined and documented, and have commitment formally from those who are the core of the Initiative's Vetting Team. ... Is there some benefit derived revising documents where the intended use has not changed? Those deploying applications based upon these documents will separately publish their own conclusions by way of call-outs. The IETF has made the call-out process difficult, and this should be improved. I think the way to address whether deprecation is some level of use in the world. Set a use minimum for any protocol - and anyone that falls below that use level - is deprecated. This way the IETF active standards track the Internet's tastes and desires since it is the Internet that the IETF is to track... But ratwould need toher than true deprecation - lets just change their names to Reference and Active Standards. Reference are any non-active Standards. Active Standards are those that are voted (did I really say that?) by the IESG to track the Industry's use. This seems to suggest competency and popularity are synonymous. There should be at least four levels maintained by industry when using these documents. 1) Current (development) 2) Stable (production) 3) Deprecated (still supported) 4) Obsolete (not supported) Current is simply the latest. This output may never become designated as being Stable. Stable indicates few issues are unresolved by several implementations. Deprecated indicates modes or features will no longer be supported in future versions. Obsolete indicates that interchange is no longer assured. It seems the industry and not the IETF should make these classifications. The results of interchange testing is the determining factor and this is not an area handled by the IETF. There will always be a company that does something different. If company X happens to have a large install base, how does that affect the ratings? There could be separate ratings indicated by company X. This review should be done annually at one of the meetings as a process model and the level of penetration of any protocol needs to be factored into the equation somehow. Why? What would be the benefit? What information is used? Note that we already have this policy, although it applied erratically by In closing lets put blame for a failed project where it belongs... in the WG Chair's lap. I think there is a fundamental failing in the mindset of the IETF and that is that the failings of the WG Vetters to come to consensus documents the failure of the WG Chairs for not better controlling their resources or projects. The lack of substantial benefits for pursuing a meaningless administrative effort may explain the mindset. Instead, the IETF should attempt to facilitate a call-out that can easily track Current, Stable, Deprecated, or Obsolete by each company or distribution. Many of these protocols involve a compilation of many RFCs. Using an overlay as described by the SRD draft, for example, would allow a Name.Serial-number approach where there would be real
RFC Editor RFP Review Request
The IAOC intends to issue an RFP for the RFC Editor function no later than 31 July 2006. To that end we seek your review and comments to the draft RFP. The draft RFP is in .doc and .pdf formats and can be found at http://koi.uoregon.edu/~iaoc/ . Comments should be submitted by 25 July to ensure consideration. The 24 page draft RFP contains the following elements: Section I General Procedural Information Section II Specifications Section III Statement of Work Section IV Service Levels Section V Proposal Format Section VI Selection Section VII Other Terms and Conditions: IPR Section VIII Contractor Checklist Section IX Signature Page Appendices Appendix 1 Statement of Work Appendix 2 Offeror's Affidavit Your comments have been of enormous assistance in the past. Thanks Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Hi Joel, I know that in most of the cases, the connectivity can also be arranged as part of the local sponsorship package. That's why I've used etc. :-) Regards, Jordi De: Joel Jaeggli [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 24 Jul 2006 07:28:41 -0700 Para: [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions JORDI PALET MARTINEZ wrote: That's part of the problem, sponsorship should be managed from a different perspective, and totally decoupled from the venue itself. IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. As you know Jordi local sponsors have historically been invaluable in getting access to local resources, like network connectivity and handling the logistics of network setup. having local support is always better than not having it. At this way the main costs (meeting rooms, AV, secretariat, etc.), are covered in a fair and planned way, and not dependant on each meeting itself. Some costs. E.G. connectivity are in fact highly dependant on the meeting location. You whole budget takes a bath the first time you have to sign a 12 month lease with the ptt/ilec on an e/ds-3 to get connectivity into a venue. Do you then go back to that venue for the next meeting because you're still paying $8000 a month for the circuit? Also this provides the IAD the budget ahead so can book the most convenient venues at least 18 months up-front, and allow a cost reduction for both IETF itself, and attendees which can get better traveling deals and more time for those that need to request an authorization to their management, etc. Regards, Jordi De: YAO Jiankang [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Jul 2006 11:31:56 +0800 Para: John L [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions - Original Message - From: John L [EMAIL PROTECTED] To: YAO Jiankang [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 18, 2006 10:34 AM Subject: Re: Meetings in other regions I do think there is considerable merit in identifying a set of venues that are known to do a good job and using them whenever a meeting is scheduled for their part of the world. Minneapolis is roughly in the middle of the populated part of North America, the hotel knows us, why not go back there? it seems boring that everytime we go to the same venue. Not to put too fine a point on it, but if you don't find IETF meetings to be exciting enough on their own merits, it's OK if you don't go. Why not kill two birds with a stone? after enjoying the nice merits of the IETF meeting, you can appreciate the different life in the different cities at the weekend. It is also unfair to those who traveled from other regions such as europe and asia. I said whenever a meeting is scheduled for their part of the world. When it's time for a meeting in North America, hold it in Minneapolis. If we find similarly reliable venues in Europe or Asia, use them when the meetings are in those parts of the world. Every IETF meeting is sponsored by the different companies. The sponsors normally love holding the meeting in the local city where the sponsor is located. Even you and me agree that the meeting is held in the same city, the sponsor may disagree. R's, John ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ 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 ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached
RE: RFC Editor Function SOW Review
I spent the first many years of my professional life overseas working as a Linguist writing and speaking other people's languages. Even though my own proficiency was inadequate by their standards, I relied upon talented native speakers to enhance my publications so that they became well written in the target language. This is what the IETF also needs to do. The IETF authors needn't be very proficient in English, but they need to be proficient enough to coherently explain their technical points so that others can understand them. What is needed is to ensure that somebody, with the authors' oversight, is enlisted to improve the drafts so that the ultimate IETF documents themselves are in very good English. Because the IETF is now International, all the IETF documents must be in well-written English because we now come from so many languages and cultures. It is hard enough dealing in foreign languages without exacerbating the problem for the non-native English speaker by asking them to understand garbled versions of English. If it is difficult for the native English speaker to understand, it is much worse for the non-Native speakers (unless they happen to speak the same language as the garbler). BTW, some native English speakers also produce horrid documents because they are poor writers. These individuals also need to leverage editors who can translate their thoughts into coherent English. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Todd Glassey wrote: Joel... Wow - what can U say... This is an issue because of the gross incompetence of an entity who is set up to propagate problems so that it will have something to work on... I bet the management of the IETF finds that comment as offensive as I find their incompetence in these matters. Presently it's an issue for the secretariat and the IAD when the meeting is unhosted... As a volunteer I'm willing to cop to gross incompetence anytime you want but if you want ascribe that to the IETF management I should think you'd want to cite specific instances. The IETF should submit a RFP for a service provider to take this over for any and all meetings held in... This is a problem for the IETF because of the gross failure of the IETF's organizers to get it... Sorry but having been the specific person responsible for raising money for supporting the meetings of the American Bar Association's Information Security Committee and haveing been a promoter for musical and other theatrical events in past-incarnations, I speak from first hand knowledge... The IAD and the IAOC have a review of the hosting model in process. I'm not competent to speak for them or anyone else, but I think it's safe to assume that they are mindful of community input. Bluntly the reason the IETF has so many problems with its meetings is not the IETF but the people organizing them and their level of expertise in negotiating T'sC's as well as their operating costs as the IETF. My experience with project management would suggest that a contract is only the starting point, successful execution is another matter. Todd -Original Message- From: Joel Jaeggli [EMAIL PROTECTED] Sent: Jul 24, 2006 7:28 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Meetings in other regions JORDI PALET MARTINEZ wrote: That's part of the problem, sponsorship should be managed from a different perspective, and totally decoupled from the venue itself. IETF should look for global sponsors, in a given time frame, for example for a year, or just a meeting if needed, but as said *decoupled* from the venue. Local sponsors can take care of the social, breaks, etc. As you know Jordi local sponsors have historically been invaluable in getting access to local resources, like network connectivity and handling the logistics of network setup. having local support is always better than not having it. At this way the main costs (meeting rooms, AV, secretariat, etc.), are covered in a fair and planned way, and not dependant on each meeting itself. Some costs. E.G. connectivity are in fact highly dependant on the meeting location. You whole budget takes a bath the first time you have to sign a 12 month lease with the ptt/ilec on an e/ds-3 to get connectivity into a venue. Do you then go back to that venue for the next meeting because you're still paying $8000 a month for the circuit? Also this provides the IAD the budget ahead so can book the most convenient venues at least 18 months up-front, and allow a cost reduction for both IETF itself, and attendees which can get better traveling deals and more time for those that need to request an authorization to their management, etc. Regards, Jordi De: YAO Jiankang [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 18 Jul 2006 11:31:56 +0800 Para: John L [EMAIL PROTECTED] CC: ietf@ietf.org Asunto: Re: Meetings in other regions - Original Message - From: John L [EMAIL PROTECTED] To: YAO Jiankang [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Tuesday, July 18, 2006 10:34 AM Subject: Re: Meetings in other regions I do think there is considerable merit in identifying a set of venues that are known to do a good job and using them whenever a meeting is scheduled for their part of the world. Minneapolis is roughly in the middle of the populated part of North America, the hotel knows us, why not go back there? it seems boring that everytime we go to the same venue. Not to put too fine a point on it, but if you don't find IETF meetings to be exciting enough on their own merits, it's OK if you don't go. Why not kill two birds with a stone? after enjoying the nice merits of the IETF meeting, you can appreciate the different life in the different cities at the weekend. It is also unfair to those who traveled from other regions such as europe and asia. I said whenever a meeting is scheduled for their part of the world. When it's time for a meeting in North America, hold it in Minneapolis. If we find similarly reliable venues in Europe or Asia, use them when the meetings are in those parts of the world. Every IETF meeting is sponsored by the different companies. The sponsors normally love holding the meeting in the local city where the sponsor is located. Even you and me agree that the meeting is held in the same city, the sponsor may disagree. R's, John
RE: Minutes and jabber logs
List of attendees? Surely that is actually independent of the minutes... -- -Original Message- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, July 18, 2006 6:14 AM -- To: David Harrington -- Cc: ietf@ietf.org -- Subject: Re: Minutes and jabber logs -- -- Just a reminder of what our process rules (RFC 2418) say: -- -- All working group sessions (including those held -- outside of the IETF -- meetings) shall be reported by making minutes available. These -- minutes should include the agenda for the session, an -- account of the -- discussion including any decisions made, and a list of -- attendees. The -- Working Group Chair is responsible for insuring that -- session minutes -- are written and distributed, though the actual task may -- be performed -- by someone designated by the Working Group Chair. The -- minutes shall -- be submitted in printable ASCII text ... -- -- We don't insist on the list of attendees when that is in -- the blue sheets, -- but it's clear that the minutes have to be readable (an -- account of the -- discussion including any decisions made) and that is not usually -- the state of a raw jabber log. It's important, since the -- decisions taken -- in a meeting have to be confirmed on the list - if the minutes are -- properly written, it's enough to ask for agreement on the minutes. -- -- A carefully edited jabber log can of course be just fine. -- -- (All of this applies equally to meetings at IETF sites, -- interim meetings, -- WG conference calls, and WG jabber conferences - readable -- minutes must be -- agreed on the list.) -- -- Brian -- -- -- David Harrington wrote: -- Hi, -- -- I would not like to see raw jabber logs included as part of the -- minutes. The signal-to-noise ratio is way too low in many -- meetings. -- -- Jabber logs written by a scribe do not do a good job -- representing the -- body language and the nuances of speech that may be important to -- really understand what a person said. I would also be -- concerned that -- there are side-discussions in jabber that are not relayed -- to the whole -- room; including those side conversations as a reflection -- of what was -- said in the meeting is simply misleading. -- -- It is the chair's job to provide a summary of the meeting for the -- mailing list to see what was discussed and decided. I -- do not think -- the chair should be allowed to evade this responsibility by simply -- posting a quick summary and the raw jabber logs to the -- mailing list as -- the official minutes. -- -- David Harrington -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- -- -- -- -Original Message- -- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 17, 2006 11:18 AM -- To: ietf@ietf.org -- Subject: Re: Meetings in other regions -- -- -- That said, and given the difficulties of balancing competing -- priorities in site location, it seems reasonable to me to make -- a decent, good-faith effort without getting overly bogged down -- in where should we meet? discussions, and really try to get -- the remote participation thing nailed down a little better. The -- ratio of good to bad remote meeting input has improved a lot -- over the past year or so but there are still too many working -- groups without a Jabber scribe in the room (which prevents remote -- listeners from providing inputs), etc. -- -- OK, this is only a thought, and I'm out of the process -- improvement business -- anyway, but I've been seeing a consistent improvement in the -- quality of -- jabber logs for at least two years, and I'm wondering if -- there are working -- groups who would be willing to try minutes = chair summary -- plus jabber -- logs for a few IETFs (without what we usually think of -- as detailed -- -- -- minutes), and see if this is actually workable. -- -- I'm a many-time repeat offender as WG note-taker, and am -- watching my notes -- look more and more like a jabber log with only one jabberer; -- the advantages -- of jabber (in my experience) are -- -- - it's nice for the note-taker to be able to participate in -- the meeting - as -- an extreme case, in the SIPPING Ad Hoc on Friday, Gonzalo and -- Mary handed me -- the mike about twenty times, but very litte of what I said -- appeared in the -- notes, and it's worse when someone is already talking when I -- stop talking. -- That's typical in my experience. With Jabber, people can type -- until I get -- back to my seat. -- -- - It's really nice when I misquote, or mis-attribute, -- something that was -- said and another jabberer corrects it right away. This is SO -- much better -- than the WG chair having to listen to the audio stream to -- check my notes -- after some number of days has elapsed (and sometimes all the -- chair can tell -- from the audio is that I got it wrong, without knowing
RE: RFC Editor Function SOW Review
Exactly. Where Dave and I disagree, I think, is that I consider getting from technically correct and coherent but not in English that is acceptable to non-native speakers who primary language also differs from that of the author/editor to be a community responsibility, while Dave considers it a WG (or other advocacy group) one... At least I hope I have that right. That work is arguably best done by professionals because it requires considerable skill; skill that improves with experience. There are several reasons I want to see it handled as a community responsibility rather than as a WG one, but the most important is that, if people have to be hired to do the work, I don't want to see our working groups turn into mini-consortia with their own budgets, funding sources, hired editors, etc. It seems to me, based on both thought experiments and experience with other standards bodies, that would lead to side effects we just do not want. john --On Monday, 24 July, 2006 09:07 -0700 Fleischman, Eric [EMAIL PROTECTED] wrote: I spent the first many years of my professional life overseas working as a Linguist writing and speaking other people's languages. Even though my own proficiency was inadequate by their standards, I relied upon talented native speakers to enhance my publications so that they became well written in the target language. This is what the IETF also needs to do. The IETF authors needn't be very proficient in English, but they need to be proficient enough to coherently explain their technical points so that others can understand them. What is needed is to ensure that somebody, with the authors' oversight, is enlisted to improve the drafts so that the ultimate IETF documents themselves are in very good English. Because the IETF is now International, all the IETF documents must be in well-written English because we now come from so many languages and cultures. It is hard enough dealing in foreign languages without exacerbating the problem for the non-native English speaker by asking them to understand garbled versions of English. If it is difficult for the native English speaker to understand, it is much worse for the non-Native speakers (unless they happen to speak the same language as the garbler). BTW, some native English speakers also produce horrid documents because they are poor writers. These individuals also need to leverage editors who can translate their thoughts into coherent English. ___ 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: IANA, Unicode, and the multilingual Internet
Dear Martin, Thank you for your comment. It makes plain we belong to two different worlds. My concern is the interoperability of these two worlds. My problem is your difficulty to realise that your world is not the only one on earth. Let go through your mail to try to understand why. At 11:17 24/07/2006, Martin Duerst wrote: At 04:05 06/07/23, JFC Morfin wrote: 4.3. IANA registries. In the case of IANA registries there is no market alternative [we saw that in the alt-root case]. The control of a IANA registry can therefore be strategic. Until now the IANA had three main areas: numbers, names, protocol parameters. The numbers/names are pure Internet issues but were considered sensible enough to be delegated to ICANN. The new area of languages This is not a new area. IANA has managed a language tag registry since around 1995 (see RFC 1766). But it is important to note that IANA just registers language tags (or since recently, language subtags), not languages. This is both true and untrue. The new language registries subtags and extensions have full autonomy in their area, while the former langtag registries was not much used (72 entries in 10 years). The capacity of the new registry is important (440 languages, 100 scripts, 250 country codes which can be organised together to build thousands of langtags). The capacity of extensions is limitless. Technology will reasticly support sociolects and idiolects, meaning billions of tags. It is also correct to say that the IANA just registers language subtags and not languages. This means labels used to build the designation of a language. This means that if you cannot tag (name with the RFC 3066 Bis format) a language, that language just do not exist in the digital system using that tagging. This may no be of importance in an obscure local application, this is not the same for the whole Internet. is not an Internet issue, RFC 1766, RFC 3066, as well as its approved successors (draft-ietf-ltru-registry, draft-ietf-ltru-initial and draft-ietf-ltru-matching) only deal with language tags on the Internet. It is difficult to understand how language tagging on the Internet would not be an Internet issue. Domain Names are an Internet issue. IP addresses also are. Their concept originates in the Internet. Languages concepts do not originate in the Internet technology. Language Tags permit the Internet technology to interface the Language reality. The importance of the Internet in the world life make a conflict between the Language reality and the Internet Language support a major political, societal and economic conflict. The point is to know who is the master and who is the slave: the man or the machine. The IETF or the people. Should the RFC adapt to users or users to RFCs. With in background the fact that if people are to adapt to RFC, they will have to adapt to the concepts and interests of those who wrote the RFC. RFC 3935 answers that point: people are to be influenced by the IETF in the way they design, use and manage the Internet for the Internet to work better. I accept that in a technical vision of the world you can think this is a good thing. I acknowledge that you may/can want to develop it. However, I cannot support you there: I have a significant (quasi universal) different vision. I serve the users rather than influencing them. Your vision is exclusive and wants to exclude mine (we saw it). Mine is to support everyone, including you - this is why I needed you to clearly define the way your system is to work. is far more important and sensible than names and numbers, I wouldn't be co-chair of the LTRU WG if I wouldn't believe that language tagging is important, but there are far more important issues (it's e.g. easy to show that 'charset' tagging is much more important than language tagging, because the consequences of failures are much greater). I am afraid you are trapped by your own conceptions and strategy. Language tagging or charsets are technical concepts. Reality is made of languages, graphemes, phonemes, etc. people, cultures, history, countries, etc. What you discuss here is related to the limitation of your concepts. You just tell that Language Tags (which are the IETF interface to languages) should consider charsets before scripts. You may remember that you opposed this I explained. We both know the reason why Unicode chose ISO 15924 and scripts rather than keyboards and charsets. And that reason is not technical. I do not share that reasons. I do not use ISO 15924 except for what it is: a list of tags you can use to qualify charsets. Also, I agree that language tagging occasionally can be a sensible issue (a look at the [EMAIL PROTECTED] mailing list would definitely give that impression), but by and large, most language tags are used in practice without any problems. This is a ... premature affirmation. Up to now there were 72 IANA language tags and a lose
Re: RFC Editor Function SOW Review
John C Klensin wrote: Exactly. Where Dave and I disagree, I think, is that I consider getting from technically correct and coherent but not in English that is acceptable to non-native speakers who primary language also differs from that of the author/editor to be a community responsibility, while Dave considers it a WG (or other advocacy group) one... At least I hope I have that right. Sounds correct to me. That work is arguably best done by professionals because it requires considerable skill; skill that improves with experience. It certainly requires skill. However it does not require some sort of formal certification and job title. The skill is available from many sources. There are several reasons I want to see it handled as a community responsibility rather than as a WG one, but the most important is that, if people have to be hired to do the work, I don't want to see our working groups turn into mini-consortia with their own budgets, funding sources, hired editors, etc. You are vastly too late for that, from a practical standpoint. The reality is that virtually all IETF efforts that succeed, these days, come from some sort of organized industry effort. Whether that organization is formal is irrelevant. In any event, industry is already spending quite a bit to get the technical work done, for any given specification. In that context, the incremental cost of the editing work is negligibility -- within the context of that single effort. Meta-point: The resistance to pushing meaningful responsibility to the groups supposed to do the work -- and enforcing that they do it well -- continues to strike me as quite dissonant with the community's claimed goals, both long-standing and recent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by [...]
Dean - So then its the ISOC's formal process to officially refuse to comply with Safe Harbor, the US DMCA and the EU's Security Requirements for electronic processes? Cool - I am betting that means the US Government cannot participate with them too, right? By the way - what State's or Country's laws are the IETF's documents governed under and why is this not in any of the IETF's documents including the Solicitation RFP itself??? My favorite is the Affidavit which comes with a perjury clause in it with no statement of who's perjury laws were being used? US? Virginia? California? who's ??? Todd Glassey - Original Message - From: Dean Anderson [EMAIL PROTECTED] To: Eliot Lear [EMAIL PROTECTED] Cc: todd glassey [EMAIL PROTECTED]; Thomas Narten [EMAIL PROTECTED]; Pete Resnick [EMAIL PROTECTED]; Frank Ellermann [EMAIL PROTECTED]; Sam Hartman [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, July 24, 2006 5:48 PM Subject: Re: Response to the Appeal by [...] This isn't true. The IETF, IESG, and IAB are activities of the ISOC. The ISOC is incorporated. A suit against the IETF, IESG, IAB activities names the ISOC. Losing such a suit, the ISOC complies with the court orders, pays the damages, and ultimately controls the money spent on IETF/IESG/IAB activities. --Dean On Thu, 20 Jul 2006, Eliot Lear wrote: todd glassey wrote: That requires a policy and approval by the ISOC - this is one of the onerous failings of the ISOC as well that it let the IETF define its own contractual processes and their recourse models. The IETF is a community trust, and the ISOC was formed to maintain that trust. The IETF let itself be governed by the ISOC on that basis, not the other way around. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'SIEVE Email Filtering: Spamtest and Virustest Extensions' to Proposed Standard (draft-ietf-sieve-spamtestbis)
The IESG has received a request from the Sieve Mail Filtering Language WG to consider the following document: - 'SIEVE Email Filtering: Spamtest and Virustest Extensions ' draft-ietf-sieve-spamtestbis-05.txt as a Proposed Standard to obsolete RFC 3685. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Matching of Language Tags' to BCP
The IESG has approved the following document: - 'Matching of Language Tags ' draft-ietf-ltru-matching-15.txt as a BCP This document is the product of the Language Tag Registry Update Working Group. The IESG contact persons are Ted Hardie and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt Technical Summary This document describes a syntax, called a language-range, for specifying items in a user's language preferences, called a language priority list. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with draft-ietf-ltru-registry-14, will become BCP 47, replacing RFC 3066. Working Group Summary Working group support for this document is strong. There was one objection raised during IETF Last Call, related to the scope and applicability of the work. This objection had previously been considered and rejected in the working group. Protocol Quality This document was reviewed for the IESG by Ted Hardie. The PROTO shepherd was Martin Duerst. Note to RFC Editor In Section 2: OLD: In a language range, each subtag MUST either be a sequence of ASCII alphanumeric characters or the single character '*' (%2A, ASTERISK). The character '*' is a wildcard that matches any sequence of subtags. The meaning and uses of wildcards vary according to the type of language range. NEW: In a language range, each subtag MUST either be a sequence of ASCII alphanumeric characters or the single character '*' (%x2A, ASTERISK). The character '*' is a wildcard that matches any sequence of subtags. The meaning and uses of wildcards vary according to the type of language range. In Section 3.3.2 OLD: Split both the extended language range and the language tag being compared into a list of subtags by dividing on the hyphen (%2D) character. Two subtags match if either they are the same when compared case-insensitively or the language range's subtag is the wildcard '*'. NEW: Split both the extended language range and the language tag being compared into a list of subtags by dividing on the hyphen (%x2D) character. Two subtags match if either they are the same when compared case-insensitively or the language range's subtag is the wildcard '*'. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
