Re: individual submission Last Call -- default yes/no.
What John says below is good sense and IMHO should put the discussion of this subject to bed (ignoring subthreads where people have gone off on to other topics without changing the subject field). The phrase Last Call has built-in semantics. If something is sufficiently straightforward that the overhead of creating a WG is pointless, and if the last call message carries the sort of text John suggests, I don't see an issue. Brian John C Klensin wrote: Hi. In the hope of making part of this discussion concrete and moving it a step forward, rather than (or in addition to) debates about philosophy, let me make two suggestions: (1) Last Calls for independent submission and similar standards-track (and BCP) documents should include, explicitly, (i) An indication that it is not a WG submission. (ii) An explicit request for comments on whether the material is appropriate for IETF standardization (independent of the correctness/ appropriateness of its technical content), as well as (iii) The usual request for comment on technical content. (2) Any explanations of why the document is relevant, what problems it solves, what individuals or groups are and are not supporting it, etc., that might help the community reach a conclusion about the second point above should be either part of the document itself or part of a supplemental informational document that is included in the Last Call. These suggestions are independent of discussions about defaults, etc., and would, I think, be helpful for all non-WG submissions, even though they will obviously be more important for some than for others. And, since the IESG decides what is Last Called and what is not, and about the content of Last Call announcements, I think it is something you can just do if you or the community think it would be helpful. 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
Re: IASA Finances - an attempt at some uplevelling
All of which suggests to me that Harald's contentious last sentence should simply be removed. btw I agree with all his other suggested changes. Brian John C Klensin wrote: --On Monday, 10 January, 2005 14:07 -0500 Leslie Daigle [EMAIL PROTECTED] wrote: John, I believe Harald meant ISOC-appointed members of the IAOC, and not folks on the IAOC who happen to be ISOC members. (Hopefully, everyone on the IAOC will be an ISOC member...). That said, I'm not entirely comfortable with the proposal. I don't want to belabour it, because I don't want to give particular importance to something that is intended to be an edge case. I would suggest that the right way to handle it is, either: . to note that this will be rife with potential for conflict of interest, and that IAOC members appointed (or ex officio) by ISOC are expected to recuse themselves from discussion of separation issues (this should amount to what Harald has said, but phrases it in terms of more normal operating procedures); or . define a new committee, that is not the IAOC, but the IETF-specific subset (+ others, as necessary). I'm in complete agreement with the above. And I think I prefer your second formulation, if only because the right group of people to serve on a disentangling committee may not be the same people who have been selected to sit on the IAOC, regardless of how they are selected. In an odd way, that also makes the question of what to put in this document easier. If we go back to the principle that un-doing this agreement requires a new BCP, that hypothetical document can specify the relevant arrangements and transition structure as needed under the circumstances. That has another implication that may be important: Presumably any decision to undo the ISOC model should originate (at least formally) within the IETF -- the IAOC, or a subset of the IAOC should not have the authority to do it on its own. If the IAOC members, or a subset of them, are unhappy with ISOC, that should be brought to the attention of the IETF. And, if an un-doing process starts with ISOC deciding to fold its tent or kick the IETF out, it is again not clear that the members of the IAOC, with or without restrictions, are the right ones to handle that process -- the IETF community would almost certainly need to be brought into the discussion. 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
IASA removability - rephrase IAOC role
I think I should apologize for including a modification to the IAOC role in the removability clause in a discussion of finances. It is not relevant to that topic. But the discussion pointed out to me that there is some strangeness here - in that the IAOC is described as having a role in the process for removing IASA from ISOC, while the ISOC president is on the IAOC. Current text: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IAOC shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IAOC and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any accrued funds, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. I think a more correct phrasing is to make this the IETF's responsibility, not the IAOC's. If the IETF decides to use some part of the IAOC in some fashion in the changeover phase, that's their privillege to decide at the time - one would think that this would be part of the BCP text. New phrasing: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IETF shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IETF and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any balance in the IASA accounts, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms will be negotiated between the IETF and ISOC. None of this text has been flagged as controversial in the last month of discussion, so I don't think it should be controversial now. And - again - I don't think we'll ever have to use it, but it's OK to have it written. OK? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: individual submission Last Call -- default yes/no.
Vernon Schryver wrote: [some lines re-wrapped] vs Please credit some of us with understanding the meaning of vs escalate in the intended sense of evoke to an authority that vs will issue a writ of mandamus. *I* certainly did not intend such a meaning. Maybe I used the wrong word; if so I apologise. I meant something along the lines of refer. My understanding of the purpose of the IETF/W3C Liaison group is, precisely, liaison over issues of importance to both the IETF and the W3C. There can be differences of emphasis in the two groups, due to the different (though, I hope, complementary) nature of the work being done by both. For example, the W3C is very concerned about the longevity of data and metadata. I don't know what is the prevailing IETF position, but quite a few of the contributors to the langtags discussion have treated longevity of data and metadata as being of no importance (cf the debate over how to handle changes to ISO 3166 Codes for the Names of Countries). I consider this to be a fundamental issue. vs Other words in Mr. Wolf's message including any course of vs action which would cause a parting of the ways were not lacking vs in forcefulness. Indeed. It would, self-evidently, be bad for the Internet were these various standards bodies not able to agree on a common course of action. The danger of such an outcome requires forceful language. vs Then there was the awesome list of authorities that the IETF vs list members is ignoring at its peril. vs See http://www1.ietf.org/mail-archive/web/ietf/current/msg33563.html Ignoring at its peril? I was simply demonstrating that standards bodies and individuals with long and respected track records have been involved for some years in the langtags work. I was responding to mails which claimed that there is no support for this work. vs When I read Mr. Wolf's message the first time, I was reminded of vs an IETF slogan about rejecting kings and presidents as well as vs ancient friction between the DDN protocol designers and users vs and the ISO. I see. The IETF embodies participation and democracy and all other standards groups are the preserves of hierarchical posturing? An interesting point of view. -- Misha Wolf Standards Manager Chief Architecture Office Reuters -- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA removability - rephrase IAOC role
Yep, I think that's the right fix. Leslie. Harald Tveit Alvestrand wrote: I think I should apologize for including a modification to the IAOC role in the removability clause in a discussion of finances. It is not relevant to that topic. But the discussion pointed out to me that there is some strangeness here - in that the IAOC is described as having a role in the process for removing IASA from ISOC, while the ISOC president is on the IAOC. Current text: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IAOC shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IAOC and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any accrued funds, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. I think a more correct phrasing is to make this the IETF's responsibility, not the IAOC's. If the IETF decides to use some part of the IAOC in some fashion in the changeover phase, that's their privillege to decide at the time - one would think that this would be part of the BCP text. New phrasing: Removability: While there is no current plan to transfer the legal and financial home of the IASA to another corporation, the IASA shall be structured to enable a clean transition in the event that the IETF community decides that such a transition is required and documents its consensus in a formal document (currently called a BCP). In such a case, the IETF shall give ISOC a minimum of six months notice before the transition formally occurs. During that period, the IETF and ISOC shall work together to create a smooth transition that does not result in any significant service outages or missed IETF meetings. All contracts executed by ISOC on behalf of IASA shall either include a clause allowing termination by ISOC with six months notice, or shall be transferable to another corporation in the event that the IASA transitions away from ISOC. Any balance in the IASA accounts, any IETF-specific intellectual property rights, and any IETF-specific data and tools shall also transition to the new entity. Other terms will be negotiated between the IETF and ISOC. None of this text has been flagged as controversial in the last month of discussion, so I don't think it should be controversial now. And - again - I don't think we'll ever have to use it, but it's OK to have it written. OK? Harald ___ 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 process/WG/BCP/langtags mess...
I generally agree with many of the observations about what the IETF process should probably be. I also observe that there is a process for individual submissions, which Mark and I have scrupulously followed. We ask that the IETF community consider our work on its merits, not just on its pedigree (or lack thereof). It is right to be conservative about what becomes a BCP, but not to the point of excluding good work, and we feel that our work is not a proprietary submission seeking to subvert the standards process. In fact we feel that we've been very considerate and open in the development of this draft in the language tagging community and continue to be open to comments and criticism, no matter the source. In this case we have developed an I-D which would like to obsolete an existing BCP which itself obsoletes a BCP. The I-D was developed using the exact same process, procedures, small-c community, and so forth that its predecessors used. I will not argue the subjective issues of whether the community working on this was large enough or the right one nor the procedural issue of whether enough notice was given to others. After that work has progressed for nearly a year and a half, though, we find ourselves in a Last Call. Certainly those individuals and groups not involved in the cut-and-thrust of this draft's development are entitled to an opportunity to consider and comment on our choices, including the requirements we chose to address and the suitability and compatibility of our solution. Procedural questions about how this should have happened are interesting and important to the IETF at large, but given the specific details of our draft's development, wouldn't it be responsible to separate the two discussions and focus on the draft at hand? I feel that the technical comments about our draft to date have mostly been related to compatibility with specific existing protocols or implementations. I feel that we have suitable ways to address these concerns (either via persuasion or via modifications to the draft). Neither Mark nor I are wild-eyed zealots or starry-eyed purists: we are willing to make adjustments and modifications that make sense in order to achieve the necessary consensus or revise or abandon aspects of the document that raise valid issues. I would like the community at large to consider this specific I-D--both the requirements for it and the technical merits of our solution--attempt to understand our choices and provide (objective) feedback that will allow us to achieve consensus for or against it (or a slight revision thereof). We are trying to work within the confines of the IETF's process to achieve what we see as the necessary progress on this issue. So what do we need to do to address (a) concerns about requirements for the draft and (b) concerns about technical objections? If we use the ietf-languages list to discuss the these sets of issues, then perhaps we can demonstrate the maturity of the draft and progress to BCP. Best Regards, Addison Addison P. Phillips Director, Globalization Architecture http://www.webMethods.com Chair, W3C Internationalization Core Working Group http://www.w3.org/International Internationalization is an architecture. It is not a feature. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: individual submission Last Call -- default yes/no.
Hi John, Your mail [1] puzzles me. I don't think I suggested that the W3C is developing language tags. On the contrary, I wrote [2]: | The W3C is highly dependent on the RFC 1766/3066 family of RFCs, | as language-handling in HTML and XML is delegated to these RFCs. | Within the W3C, the responsibility for keeping an eye on these | RFCs lies with the I18N WG. I also did not suggest most of the other things which you imply that I had suggested. The facts of the matter are: - various IETF protocols and data structures make use of language tags - various W3C protocols and data structures make use of language tags There are a number of important issues needing resolution, including the stability of language tags over time. The current draft attempts to deal with these. I note your characterisation of the IETF/W3C liaison (as only tackling formal projects that both bodies are engaged in, etc). You may be quite correct, though one might be forgiven for forming a different impression, looking at: http://lists.w3.org/Archives/Public/public-ietf-w3c/ [EMAIL PROTECTED] Mail Archives IETF/W3C coordination: identification of areas of overlap, coordination of reviews, and meeting coverage. and: http://lists.w3.org/Archives/Public/public-ietf-w3c/2002Jun/0001.html announcing [EMAIL PROTECTED] [too long to quote] and: http://www.w3.org/2001/11/StdLiaison#IETF [which lists I18N under W3C Activities affected] I have no idea where you got all the other strange ideas you appear to attribute to me (about overruling the IESG etc), so I won't respond to them. [1] http://www1.ietf.org/mail-archive/web/ietf/current/msg33603.html [2] http://www1.ietf.org/mail-archive/web/ietf/current/msg33553.html -- Misha Wolf Standards Manager Chief Architecture Office Reuters --- - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
From: Addison Phillips [wM] [EMAIL PROTECTED]
In fact we feel that we've been very considerate
and open in the development of this draft in the language tagging
community and continue to be open to comments and criticism, no
matter the source.
Based on what I have seen in this mailing list, I disagree.
I would like the community at large to consider this specific
I-D--both the requirements for it and the technical merits of our
solution--attempt to understand our choices and provide (objective)
feedback that will allow us to achieve consensus for or against it
(or a slight revision thereof). We are trying to work within the
confines of the IETF's process to achieve what we see as the necessary
progress on this issue.
If the advocates for this I-D were really trying to follow the IETF's
processes, they would have taken one of the suggestions for the next
step and temporarily (or permanently) retired from the field. It is
clear that there is no consensus to advance this document. Even its
authors have admitted that by talking about a new version.
As has been said repeatedly, a new version would require a new Last
Call. Last Calls are on documents, not promises to produce a new
document that might address objections to the current document. Long
time spent in IETF processes is not a reason to ignore the clear answer
from the IETF processes of No Consensus, even when the long time
actually is spent in the IETF processes. The IETF process involves
official IETF Working Groups and official IETF WG mailing lists. Time
spent in an unrelated mailing list is not part of IETF standards process
any more then the time spent by an Informational RFC author thinking
about things is part of the IETF standards process.
Besides, isn't the Last Call officially over? Isn't the topic of the
language tags BCP closed, dead, kaput, finished, and done until the
IESG and the individual submitters of the document choose the next step?
I can't see any significance for Mr. Phillips comment except as yet
more evidence that the default answer for individual submissions
must be ABSOLUTE NO! He is basically saying You must publish our
BCP because we followed all of the steps as we understood them and the
default result of that is surely to publish.
Vernon Schryver[EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
Vernon == Vernon Schryver [EMAIL PROTECTED] writes: Vernon If the advocates for this I-D were really trying to follow Vernon the IETF's processes, they would have taken one of the Vernon suggestions for the next step and temporarily (or Vernon permanently) retired from the field. It is clear that Vernon there is no consensus to advance this document. Even its Vernon authors have admitted that by talking about a new version. No, currently this draft is in Ted's hands. It makes no sense for people to withdraw drafts or to make any hasty decisions at all. In a situation where you get a lot of last call comments it is best for the pinvolved parties to get together and decide what to do next. Correct action is more important than prompt action. Many people suggested ways of moving forward. Deciding which of these is best will require some time. The process will work much better if the authors help make this decision than if the unilaterally withdraw their draft or do something like that. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Authors soliciting comments
Date: Tue, 11 Jan 2005 15:36:10 -0500 Subject: I-D ACTION:draft-baker-alert-system-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Structure of an International Emergency Alert System Author(s) : F. Baker, B. Carpenter Filename: draft-baker-alert-system-00.txt Pages : 19 Date: 2005-1-11 The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-baker-alert-system-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-baker-alert-system-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select Messaging, Email-Related, Mail Routing Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j0BLINWG015337 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 Asiapac +61 2 8446 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.6) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-phillips-langtags-08.txt
The last call on this draft has ended. I appreciate all of the technical comments raised in response to this draft. The IESG will work with the authors to resolve those issues and determine the next steps. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
Vernon == Vernon Schryver [EMAIL PROTECTED] writes: From: Sam Hartman [EMAIL PROTECTED] No, currently this draft is in Ted's hands. It makes no sense for people to withdraw drafts or to make any hasty decisions at all. Vernon That's fine, but does suggest some questions: Vernon - Is the Last Call over? The answer to this question is clearly yes. You can see this for yourself in the ID tracker. What this means is a bit unclear. If someone brought up a new comment that pointed out a new critical defect in the specification, the IESG would almost certainly consider the comment even though it was received after the last call period. However it is probably not useful to continue existing discussions of the draft. Vernon - If so, was its result no supporting consensus? That's hard to answer or put another way, things don't quite work in such a way that that question has an easy answer. Procedurally speaking the responsible AD (Ted in this case) decides what to do next. He can ask for revisions; he can talk to the authors; he can try to create a working group; he can tell the authors he will not sponsor the draft; he can issue a ballot and put the draft on the IESG agenda. Those options are intended to be a fairly exaustive list of what an AD could do after any last call and are not intended to express any opinion about the current document. So, at some level you will just have to wait to learn Ted's opinion of the situation; the rest of us are also waiting for the same thing. Note that there are procedural safeguards. If an AD brings a document to the IESG that is not ready, other IESG members can object. If the IESG approves a document that is not ready, the community can appeal the decision. If an AD proposes a new working group, the community, IAB and IESG get to review the proposed working group. I hope this helps you understand the process. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
From: Vernon Schryver [EMAIL PROTECTED] In fact we feel that we've been very considerate and open in the development of this draft in the language tagging community and continue to be open to comments and criticism, no matter the source. Based on what I have seen in this mailing list, I disagree. I'd be curious to know what has led to the impression that the authors have not been open to comments or criticism. He is basically saying You must publish our BCP because we followed all of the steps as we understood them and the default result of that is surely to publish. I am unable to see how you derive that from his message. Rather, he appears to be saying, if there is not enough consensus for acceptance of this draft, then surely we should be able to find a way for stakeholders to continue work together toward a draft that does achieve consensus. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
From: Vernon Schryver [EMAIL PROTECTED] Subject: Re: The process/WG/BCP/langtags mess... That's fine, but does suggest some questions: - Is the Last Call over? - If so, was its result no supporting consensus? - If the result was no supporting consensus, will the current document nevertheless be published as a BCP? - If the result was no supporting consensus, will a revision of the document be published as a BCP without a new Last Call? Last week I saw a comment that seemed to answer first question with Yes. If the answers to the other questions are not Yes, No, and No, then as others have said, the IETF has far more serious process problems than how to account for the expenses of the to be hired help. This is comment is a general one rather than being directed toward the particular case at hand. It seems to me that your comment is making a presumption, as a participant on the IETF list, regarding what the outcome of the question regarding result must be. Perhaps I am wrong, but I would have thought it is the role of the IESG to make that determination, not members of this list; and if that is the case I would certainly think it possible for them to weigh concerns that have been raised against responses provided and reach a conclusion that there has been adequate disposition of the comments raised. Again, I am not saying that in this case I think that is what the IESG will or might or should do; only that in general I would think it is something that they *could* do, in which case the outcome of their decision even when concerns have been raised cannot be assumed a priori. If outside groups can publish IETF BCPs without the let, leave, or hindrance of the IETF, then the honest thing to do is to get rid of all of that tiresome WG stuff. No outside group is doing this. On the other hand, if the answers are Yes, Yes, No, and No, then contrary to the other person's request, there is no good reason to talk about the language tags document here and now. I agree that a yes to the first question -- is the last call closed? -- would appear to be adequate grounds for there to be no further discussion on this list in relation to the I-D in question. Whether there may be grounds for discussing other process-related questions possibly including the area of work to which this I-D pertained is, of course, a separate question. Peter Constable ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
Date: 2005-01-11 13:33 From: Addison Phillips [wM] [EMAIL PROTECTED] Addressing some issues not covered by others: In this case we have developed an I-D which would like to obsolete an existing BCP which itself obsoletes a BCP. The I-D was developed using the exact same process, procedures, small-c community, and so forth that its predecessors used. I will not argue the subjective issues of whether the community working on this was large enough or the right one nor the procedural issue of whether enough notice was given to others. After that work has progressed for nearly a year and a half, though, we find ourselves in a Last Call. Certainly those individuals and groups not involved in the cut-and-thrust of this draft's development are entitled to an opportunity to consider and comment on our choices, including the requirements we chose to address and the suitability and compatibility of our solution. To be clear, it's a New Last Call which followed an earlier Last Call. Judging by the comments on the technical content and by the authors' comments, it appears that there is to be at least one more draft revision, and therefore presumably yet another New Last Call. One might ask whether hashing out details on the ietf and ietf-languages lists is an effective way to move forward (as opposed to a WG). Procedural questions about how this should have happened are interesting and important to the IETF at large, but given the specific details of our draft's development, wouldn't it be responsible to separate the two discussions and focus on the draft at hand? I feel that the technical comments about our draft to date have mostly been related to compatibility with specific existing protocols or implementations. I feel that we have suitable ways to address these concerns (either via persuasion or via modifications to the draft). Neither Mark nor I are wild-eyed zealots or starry-eyed purists: we are willing to make adjustments and modifications that make sense in order to achieve the necessary consensus or revise or abandon aspects of the document that raise valid issues. In large measure the technical issues and procedural issues have been discussed separately. They do, however converge inasmuch as the lack of an IETF WG has presumably been a factor in lack of IETF participation in the discussion prior to Last Calls, and the consequent lack of consideration of IETF protocols (including core Internet protocols). So what do we need to do to address (a) concerns about requirements for the draft and (b) concerns about technical objections? I believe that formation of an IETF working group as suggested by several commentators would address both issues. I have separately suggested that via an RFC 2026 section 6.5.2 comment sent to [EMAIL PROTECTED] on 2004-12-27. It has not yet appeared on the Appeals to IESG page (Harald, if you can't find it, let me know off-list, and I'll resend it). If we use the ietf-languages list to discuss the these sets of issues, then perhaps we can demonstrate the maturity of the draft and progress to BCP. The ietf-languages list, as also noted during recent discussion, is supposed to be for review of language-tag registrations, not for general discussion. The language-tag reviewer has also recently noted his displeasure with the general discussion. Again, setting up an IETF WG with its own mailing list would address that problem as well as the ones noted above. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Definitions, names, and confusion
In recent discussion of a proposed replacement of a BCP RFC, a couple of problems have reappeared: 1. There seems to be a fairly wide misunderstanding of what BCP RFCs are supposed to cover. Part of the problem is that Best Current Practice isn't a terribly good name for the sort of administrative procedures and policies that BCPs actually address. Many individuals apparently believe that discussions of how to administer user accounts and the like are suitable for BCP. It is clear from the RFC 2026 discussion that that isn't what BCP RFCs are about -- for those who bother to read 2026. Reinforcing the misinterpretation are comments referring to Next-Best Current Practice and/or Worst Current Practice. I suspect that there would be some resistance to changing the term BCP itself, so the only solution to this problem seems to lie in better education w.r.t. the true purpose and scope of BCP. 2. There seems to be a broad and deep lack of understanding of and appreciation for the importance of backwards compatibility. In searching the entire on-line collection of RFCs for an authoritative definition and in-depth discussion of the issue, I found none. I believe the IAB could provide a much-needed service to the Internet Community by developing such a definition and explanation, possibly including it in a revision of RFC 1958, ideally with BCP (rather than Informational) status. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: individual submission Last Call -- default yes/no.
Date: 2005-01-11 05:17 From: Misha Wolf [EMAIL PROTECTED] My understanding of the purpose of the IETF/W3C Liaison group is, precisely, liaison over issues of importance to both the IETF and the W3C. Since the draft-philips-... effort isn't an IETF effort, exactly who would represent the IETF, on what basis, and for what purpose? I don't know what is the prevailing IETF position, but quite a few of the contributors to the langtags discussion have treated longevity of data and metadata as being of no importance (cf the debate over how to handle changes to ISO 3166 Codes for the Names of Countries). I believe that (being of no importance) is a gross mischaracterization which does not represent what *anybody* involved in the discussion since the December New Last Call has said, much less the claimed quite a few. vs Then there was the awesome list of authorities that the IETF vs list members is ignoring at its peril. vs See http://www1.ietf.org/mail-archive/web/ietf/current/msg33563.html Ignoring at its peril? I was simply demonstrating that standards bodies and individuals with long and respected track records have been involved for some years in the langtags work. You specifically stated that the draft-philips-... work has been carried out as an informal IETF/W3C/Unicode collaboration, and proceeded to list 3 W3C participants, 1 Unicode Consortium participant, mentioned a W3C WG and a Unicode Consortium project, but *no* IETF participation and of course no IETF WG. That remarkable comment -- IETF [...] collaboration with no IETF participation -- occurred after considerable discussion of the process. It also occurred two days after the close of the New Last Call, so I have until this latest reference back to that peculiar statement declined to comment on it. Something is gravely wrong when an ad-hoc group believes that it is in collaboration with the IETF by ignoring published (RFC 2418) IETF procedures and protocols and by failing to advise or consult with established IETF groups likely to have an interest in the IETF standard which the ad-hoc group proposes to replace. When a public gross mischaracterization of New Last Call discussion is piled on top of such claims of collaboration, we've gone well beyond gravely wrong. I'm dumbfounded and can't find a term to adequately portray my shock and horror at such outrageous remarks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
--On Tuesday, 11 January, 2005 17:55 -0500 Sam Hartman [EMAIL PROTECTED] wrote: ... Procedurally speaking the responsible AD (Ted in this case) decides what to do next. He can ask for revisions; he can talk to the authors; he can try to create a working group; he can tell the authors he will not sponsor the draft; he can issue a ballot and put the draft on the IESG agenda. Those options are intended to be a fairly exaustive list of what an AD could do after any last call and are not intended to express any opinion about the current document. So, at some level you will just have to wait to learn Ted's opinion of the situation; the rest of us are also waiting for the same thing. Note that there are procedural safeguards. If an AD brings a document to the IESG that is not ready, other IESG members can object. If the IESG approves a document that is not ready, the community can appeal the decision. If an AD proposes a new working group, the community, IAB and IESG get to review the proposed working group. I hope this helps you understand the process. Sam, let me add one or two possibilities to your very helpful description and list of safeguards above and to Ted's shorter status summary. If the AD decides he or she (like you, I'm trying to be quite generic) won't sponsor the thing, the authors can go AD-shopping and try to convince someone else to pick it up. I wouldn't normally recommend that, if only because I'd assume that the relevant AD would have asked if anyone else wanted it and tried to do a handoff if that was appropriate, but the procedures clearly permit it. And, if the AD or IESG decide that the document isn't ready, the authors could try to organize a WG as an alternative to trying to revise the document among themselves and as a means of completely separating out the community support for doing something issue from the specific proposals of the document. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Confused about references to I-D when the RFC is published
I will admit to having been a little more focused, during AUTH48, on making sure that the document got back to saying what it had said when it entered the RFC Editor queue some 5 months earlier. Leslie. John C Klensin wrote: --On Sunday, 09 January, 2005 22:22 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: Last week, one RFC has been published with a reference to an I-D when the final RFC is already published. RFC 3958 says: [11] Atkins, D. and R. Austein, Threat Analysis Of The Domain Name System, Work in Progress, April 2004. while RFC 3833 is five months old. Now, I understand that RFC 3958 was probably approved before RFC 3833 was issued. But I thought (ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-proce ss.gif) that references were supposed to be updated by the RFC editor even after approval by the IESG? Yes. But this is also the sort of thing that authors are supposed to check carefully on RFC Editor 48 hour author's last call. Slip-ups happen; no one is perfect. 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
Re: Authors soliciting comments
Hi Fred, I've previously worked with the Bureau of Meteorology (BoM) here in Australia, and they propagate several of these type of warnings between meteorological, seismic and aviation agencies here and around the world using message switching systems. The Internet is used for dissemination in a number of ways. In the late 90's tcp/telenet sessions were in use on extranet/leased line links, and pager, fax and other direct to the public warning dissemination systems were in use. It's probably worth trying to get input from existing agencies tasked with this role in various countries, and some organizations (such as the World Meteorological Organization) may be interested in contributing time and effort in this direction, but I don't know. Perhaps there are also existing systems which may be used as a model. Unfortunately, I don't believe that there is an actively monitored tsunami service in the Indian ocean, which may have been able to transfer such warnings. The role of a generic, authenticated, internet-based warning system may be useful in furture though. Greg Daley Fred Baker wrote: Date: Tue, 11 Jan 2005 15:36:10 -0500 Subject: I-D ACTION:draft-baker-alert-system-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Structure of an International Emergency Alert System Author(s) : F. Baker, B. Carpenter Filename: draft-baker-alert-system-00.txt Pages : 19 Date: 2005-1-11 The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-baker-alert-system-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-baker-alert-system-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select Messaging, Email-Related, Mail Routing Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique
Re: Authors soliciting comments
Unfortunately, I don't believe that there is an actively monitored tsunami service in the Indian ocean, which may have been able to transfer such warnings. There is no such a system in the Indian Ocean. There is a big impending initiative to have one in place. -- Petre The role of a generic, authenticated, internet-based warning system may be useful in furture though. Greg Daley Fred Baker wrote: Date: Tue, 11 Jan 2005 15:36:10 -0500 Subject: I-D ACTION:draft-baker-alert-system-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Structure of an International Emergency Alert System Author(s) : F. Baker, B. Carpenter Filename: draft-baker-alert-system-00.txt Pages : 19 Date: 2005-1-11 The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-baker-alert-system-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-baker-alert-system-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select Messaging, Email-Related, Mail Routing Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j0BLINWG015337 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 Asiapac +61 2 8446 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.6) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ___ Ietf
Re: Authors soliciting comments
At 04:54 PM 01/12/05 +1100, Greg Daley wrote: Unfortunately, I don't believe that there is an actively monitored tsunami service in the Indian ocean, which may have been able to transfer such warnings. The role of a generic, authenticated, internet-based warning system may be useful in future though. That is rather an important thing to lack, and yes, I understand that to be the case as well. Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [manet] WG Review: Recharter of Mobile Ad-hoc Networks (manet)
Guys, The topic is no doubt interesting. We do, however, need to scope the work. Two routing protocols and a flooding mechanism are already enough for one WG. Options: a) wait until MANET is done and bring the topic then, and b) create another mailing list, bring the topic there, see if anything good comes out possibly ask for BOF. Talk to your WG chairs, please. -- Alex http://www.psg.com/~zinin Wednesday, December 29, 2004, 1:53:25 AM, Giorgio Mulas wrote: Hi All, Fully agree with Dario. Multicast! B.r. and happy new year Giorgio -- Giorgio Mulas | Researcher CEFRIEL Politecnico di Milano Via Fucini, 2 · 20133 Milano (Italy) p. +39 02 23954 265 f. +39 02 23954 465 e. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: venerdì 24 dicembre 2004 10.51 To: iesg@ietf.org; The IESG; IETF-Announce@ietf.org Cc: Ian Chakeres; manet@ietf.org; Joseph Macker Subject: Re: [manet] WG Review: Recharter of Mobile Ad-hoc Networks (manet) hi all, IMHO it the MANET charter should amplify its scope to address multicast. best regards and merry xmas! Dario The IESG [EMAIL PROTECTED] said: A modified charter has been submitted for the Mobile Ad-hoc Networks (manet) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by December 30th. +++ Mobile Ad-hoc Networks (manet) === Current Status: Active Working Group Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications: - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach. Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed. The MANET WG will also develop a scoped forwarding protocol that can efficiently flood data packets to all participating MANET nodes. The primary purpose of this mechanism is a simplified best effort multicast forwarding function. The use of this protocol is intended to be applied ONLY within MANET routing areas and the WG effort will be limited to routing layer design issues. The MANET WG will pay attention to the OSPF-MANET protocol work within the OSPF WG and IRTF work that is addressing research topics related to MANET environments. ___ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet -- ___ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ___ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The wais URI Scheme' to Historic
The IESG has received a request from an individual submitter to consider the following document: - 'The wais URI Scheme ' draft-hoffman-wais-uri-03.txt as a Historic 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 2005-02-08. Please note that this draft is part of a larger effort to provide scheme definitions for those schemes originally defined in RFC 1738, so that RFC 1738 may be marked obsolete. Discussion of this draft and that project has taken place on the [EMAIL PROTECTED] mailing list. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-wais-uri-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
