Re: [Ltru] Re: WG Review: Recharter of Language Tag Registry Update (ltru)
Doug Ewell wrote: On Tue, 22 Aug 2006 10:23:54 -0400, IESG Secretary iesg dash secretary at ietf dot org wrote: A modified charter has been submitted for the Language Tag Registry Update (ltru) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by August 29th. ... Goals and Milestones: September 2006 Submit first WG draft of registry procedure update September 2006 Submit first WG draft of registry data update January 2007 Submit registry procedure update draft for IETF Last Call January 2007 Submit registry data update draft for IETF Last Call As the likely editor of the registry data update document, I'd like to request that the milestones for the first drafts be extended to October, or perhaps even November, and that the milestones for Last Call drafts remain at least 3 months after the first drafts (e.g. moving them to February if the first drafts arrive in November). Having experienced many lengthy delays in LTRU 1.0, which pushed the original milestones out by many months, I'd like to make sure we have a reasonable chance of hitting the LTRU 2.0 dates. There are several issues to be discussed within the WG before realistic first drafts can be written. The decision on the new charter will not be made until at least August 29, leaving only 32 days to discuss these issues and write drafts before the first milestone. I concur. Note also that if the ISO process is delayed for any reason, the completion timelines will also have to move; ISO does not have a stellar track record of keeping schedules either. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Fwd: IETF Process discussions - next steps]
I was quite surprised to discover that this message is not in the mailing list archive, so I am repeating it. A copy certainly reached the newtrk WG prior to its closure. Original Message Subject: IETF Process discussions - next steps Date: Thu, 10 Aug 2006 11:41:47 +0200 From: Brian E Carpenter [EMAIL PROTECTED] Organization: IBM To: IETF discussion list ietf@ietf.org Here are my conclusions from the plenary discussion and the General Area open meeting at IETF 66. 1. Conclusions from plenary discussion on Newtrk issues (draft-carpenter-newtrk-questions-00.txt) A clear theme in the plenary discussion in Montreal was declare victory. Unfortunately, in reading the notes and listening to the audio recording, and reading subsequent emails, it is also clear that different speakers meant different things by this phrase - anywhere from clarifying today's standards track, through reducing it to two or one stages, to simply sitting down and shutting up. Although on the order of 40 people out of several hundred in the plenary appeared to believe that formal changes to the standards process should be made, and some people are ready to do work (thanks!) there was no firm consensus for a given direction (as there never has been in the Newtrk WG). One useful observation was that there is nothing in present rules and procedures to prevent the writing and publication of overview standards documents (ISDs in Newtrk parlance), as long as they fit into RFC 2026 rules as Applicability Statements. A need was observed for lightweight documentation of the real world deployment status of individual standards, as concrete feedback from running code. Again, no rule prevents this today, but neither do we have guidelines as to the format, status and indexing of such documents. My conclusions are that: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. 1.2. For complex standards where a normative or informative overview document would be beneficial, nothing in today's rules and procedures prevents interested parties from writing and submitting such documents within the rules set by RFC 2026, and such efforts should be welcomed. 1.3. The community should be encouraged to produce documentation of deployment and interoperability of individual IETF standards, even if there is no proposal to advance them on the standards track. Such documents should be directed towards efforts to update IETF standards and/or to document errata and operational issues. A more systematic framework than today's implementation reports would be beneficial. 1.4. The newtrk WG should be closed. 2. Conclusion from GenArea mini-BOF on IESG structure and charter. It seemed clear in the room that people felt there was not a serious enough problem with RFC 3710 to justify a significant effort. There was some support for undertaking at least the first step: * List Tasks that Currently Gate on the IESG in order to document whether there is in fact a problem worth solving. My conclusion is to ask John Leslie to lead a small team to carry out this very specific task for the information of the community. 3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418) It seems there is some feeling that the RFC is beginning to show its age, and would be worth updating. My conclusion is that the best first step is to ask Margaret Wasserman to lead a small team to survey participants and build a list of issues that need updating. Of course, any actual update to RFC 2418 would then have to follow normal IETF consensus process. 3. Conclusion from GenArea mini-BOF on mailing list management procedures. (draft-galvin-maillists-00.txt) It seems clear from recent experience with RFC 3683 that something needs to happen in this area and that feelings run deep on this issue. However, the energy to work on this in the community is limited despite some support in the mini-BOF for doing so. My conclusion is, as experiments under draft-hartman-mailinglist-experiment are possible immediately, there is no urgency to start an organized effort right now - but it should be considered over the coming months. Meanhwile I would like to ask Jim Galvin to update his draft according to the discussion, for future reference. A suggestion was made during the meeting to rapidly declare RFC 3683 obsolete. Brian Carpenter General Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Fwd: IETF Process discussions - next steps]
It is still unclear to me what the proposed course of action is. The current situation is not acceptable. HTTP is by any rational definition a standard. Yet according to the process document it is merely a draft standard. I therefore declare the process document to be a silly thing which is clearly at odds with reality and is being ignored. There are only two paths forward that I consider sustainable 1) The IESG catches up on the backlog of declaring draft standards to be standards. 2) The IESG proposes a process for doing this. At present the IESG is approving an average of less than one protocol a year as a standard. And of the recent choices only the URI spec is of first rank significance. At the moment the IESG is simultaneously failing to do its function under the present process and refusing to allow its function to be changed under a new process. Empirically we have a two stage process. The fact that IP over NetBios is a 'standard' and HTTP 1.1 is not demonstrates the lack of a correlation between the standards status and the deployment status. If you look at what is actually accepted as a standard it is quite interesting. Most are protocols that are functionally obsolete such as IP over OSI, or irrelevant (Echo, chargen, quote of the day. FTP, Telnet). FTP and Telnet both lack an acceptable security layer and should be considered HISTORIC. The obsolete version of SMTP is considered 'standard'. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:17 AM To: IETF discussion list Subject: [Fwd: IETF Process discussions - next steps] I was quite surprised to discover that this message is not in the mailing list archive, so I am repeating it. A copy certainly reached the newtrk WG prior to its closure. Original Message Subject: IETF Process discussions - next steps Date: Thu, 10 Aug 2006 11:41:47 +0200 From: Brian E Carpenter [EMAIL PROTECTED] Organization: IBM To: IETF discussion list ietf@ietf.org Here are my conclusions from the plenary discussion and the General Area open meeting at IETF 66. 1. Conclusions from plenary discussion on Newtrk issues (draft-carpenter-newtrk-questions-00.txt) A clear theme in the plenary discussion in Montreal was declare victory. Unfortunately, in reading the notes and listening to the audio recording, and reading subsequent emails, it is also clear that different speakers meant different things by this phrase - anywhere from clarifying today's standards track, through reducing it to two or one stages, to simply sitting down and shutting up. Although on the order of 40 people out of several hundred in the plenary appeared to believe that formal changes to the standards process should be made, and some people are ready to do work (thanks!) there was no firm consensus for a given direction (as there never has been in the Newtrk WG). One useful observation was that there is nothing in present rules and procedures to prevent the writing and publication of overview standards documents (ISDs in Newtrk parlance), as long as they fit into RFC 2026 rules as Applicability Statements. A need was observed for lightweight documentation of the real world deployment status of individual standards, as concrete feedback from running code. Again, no rule prevents this today, but neither do we have guidelines as to the format, status and indexing of such documents. My conclusions are that: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. 1.2. For complex standards where a normative or informative overview document would be beneficial, nothing in today's rules and procedures prevents interested parties from writing and submitting such documents within the rules set by RFC 2026, and such efforts should be welcomed. 1.3. The community should be encouraged to produce documentation of deployment and interoperability of individual IETF standards, even if there is no proposal to advance them on the standards track. Such documents should be directed towards efforts to update IETF standards and/or to document errata and operational issues. A more systematic framework than today's implementation reports would be beneficial. 1.4. The newtrk WG should be closed. 2. Conclusion from GenArea mini-BOF on IESG structure and charter. It seemed clear in the room that people felt there was not a serious enough problem with RFC 3710 to justify a significant effort. There was some support for undertaking at least the first step: * List Tasks that Currently Gate on the IESG in order to document whether there is in fact a problem worth solving. My conclusion is to ask John Leslie to lead a small team to carry out this very specific task for the information of the
Re: [Fwd: IETF Process discussions - next steps]
Brian E Carpenter wrote: I was quite surprised to discover that this message is not in the mailing list archive, so I am repeating it. A copy certainly reached the newtrk WG prior to its closure. Original Message Subject: IETF Process discussions - next steps Date: Thu, 10 Aug 2006 11:41:47 +0200 From: Brian E Carpenter [EMAIL PROTECTED] Organization: IBM To: IETF discussion list ietf@ietf.org Here are my conclusions from the plenary discussion and the General Area open meeting at IETF 66. 1. Conclusions from plenary discussion on Newtrk issues (draft-carpenter-newtrk-questions-00.txt) IMO, there are IETF-wide and area-wide standards-track advancement issues are varying importance. I think each AD should at least consider (and hopefully write down) what the advancement policy is for their area. For example, we have learned through experience that advancement of MIB modules is quite problematic, even though it is very straight-forward to define and evaluate the interoperability requirements. Vendors have been rather reluctant to respond to implementation surveys. (This isn't that surprising, since SW engineers usually have to fill out the surveys, and we hate to write documentation :-) Even when this seemingly harmless survey is returned, many respondents say they don't believe this effort is of any value. So the reports are inaccurate and difficult to obtain. Worse yet, decisions to keep or deprecate MIB objects are based on these reports. In the Entity MIB WG, we actually found our efforts to deprecate some MIB objects (per SOP) during advancement to be harmful to interoperability. I believe we now have an unofficial don't ask, don't advance policy. That is, the WG Chairs won't attempt to advance RFCs containing MIB modules beyond Proposed Standard anymore, and the ADs won't ask them to do so. Yet, I believe there is some value for operators to know the difference between a mature MIB module like RMON-MIB and the first version of a MIB module like RAQMON-MIB. The SMI sort of provides that info, but not very clearly to non-experts. Andy A clear theme in the plenary discussion in Montreal was declare victory. Unfortunately, in reading the notes and listening to the audio recording, and reading subsequent emails, it is also clear that different speakers meant different things by this phrase - anywhere from clarifying today's standards track, through reducing it to two or one stages, to simply sitting down and shutting up. Although on the order of 40 people out of several hundred in the plenary appeared to believe that formal changes to the standards process should be made, and some people are ready to do work (thanks!) there was no firm consensus for a given direction (as there never has been in the Newtrk WG). One useful observation was that there is nothing in present rules and procedures to prevent the writing and publication of overview standards documents (ISDs in Newtrk parlance), as long as they fit into RFC 2026 rules as Applicability Statements. A need was observed for lightweight documentation of the real world deployment status of individual standards, as concrete feedback from running code. Again, no rule prevents this today, but neither do we have guidelines as to the format, status and indexing of such documents. My conclusions are that: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. 1.2. For complex standards where a normative or informative overview document would be beneficial, nothing in today's rules and procedures prevents interested parties from writing and submitting such documents within the rules set by RFC 2026, and such efforts should be welcomed. 1.3. The community should be encouraged to produce documentation of deployment and interoperability of individual IETF standards, even if there is no proposal to advance them on the standards track. Such documents should be directed towards efforts to update IETF standards and/or to document errata and operational issues. A more systematic framework than today's implementation reports would be beneficial. 1.4. The newtrk WG should be closed. 2. Conclusion from GenArea mini-BOF on IESG structure and charter. It seemed clear in the room that people felt there was not a serious enough problem with RFC 3710 to justify a significant effort. There was some support for undertaking at least the first step: * List Tasks that Currently Gate on the IESG in order to document whether there is in fact a problem worth solving. My conclusion is to ask John Leslie to lead a small team to carry out this very specific task for the information of the community. 3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418) It seems there is some feeling that the RFC is beginning to show its age, and would be worth updating. My conclusion is that the best first step is to ask Margaret
Last Call: 'Label Switching Router Self-Test' to Proposed Standard (draft-ietf-mpls-lsr-self-test)
The IESG has received a request from the Multiprotocol Label Switching WG to consider the following document: - 'Label Switching Router Self-Test ' draft-ietf-mpls-lsr-self-test-06.txt as a Proposed Standard 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-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-self-test-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Extensions to GMPLS RSVP Graceful Restart' to Proposed Standard (draft-ietf-ccamp-rsvp-restart-ext)
The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Extensions to GMPLS RSVP Graceful Restart ' draft-ietf-ccamp-rsvp-restart-ext-05.txt as a Proposed Standard 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-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals' to Proposed Standard
The IESG has approved the following documents: - 'Definition of Events For Modem, FAX, and Text Telephony Signals ' draft-ietf-avt-rfc2833bisdata-08.txt as a Proposed Standard - 'RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals ' draft-ietf-avt-rfc2833bis-15.txt as a Proposed Standard These documents are products of the Audio/Video Transport Working Group. The IESG contact persons is Cullen Jennings A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-15.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-08.txt Technical Summary draft-ietf-avt-rfc2833bis: This document defines the RTP Payload format for telephony events over RTP and the usage of DTMF in this payload format. It also establish a registry in which further telephony events using this payload format may be registered in. The document also defines an RTP Payload format for tones used in telephony systems. The payload format is capable of describing single, multiple or modulated tones. draft-ietf-avt-rfc2833bisdata: This document defines 31 additional events to be used with the RTP payload format for telephony events defined in draft-ietf-avt-rfc2833bis. The defined event cover the usage with a number of ITU specifications such as V.8, V.8 bis, V.21, V.25, V.32/V.32bis, and T.30. Working Group Summary: There is consensus in the WG to publish these documents. Protocol Quality: These documents are updates of RFC 2833 which is obsoleted. The implementation experience for RFC 2833 has been taken into account in these updates. The documents have been reviewed by both IETF and ITU-T Study Group 16. The media types were reviewed on ietf-types list in November 2005. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Forward Error Correction Grouping Semantics in Session Description Protocol' to Proposed Standard (draft-ietf-mmusic-fec-grouping)
The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'Forward Error Correction Grouping Semantics in Session Description Protocol ' draft-ietf-mmusic-fec-grouping-05.txt as a Proposed Standard 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-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec-grouping-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
