Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
On Dec 22, 2009, at 8:39 PM, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your interpretation to mean that the RFC Editor can, on their own initiative, fix the problem(s) that Julan has raised and that it does not require changes to the about-to-be-published document. Is that correct? Do others agree? (I hope so.) FWIW, I do. As long as those changes are stylistic, editorial, and not so substantive that they cause the various streams to be uneasy with those changes. And in reply to Brian: Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. That is what I intended with: I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input --Olaf (personal title) d/ On 12/22/2009 11:23 AM, Brian E Carpenter wrote: FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. ... For now, there are indeed weasel words such as: However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. -- Dave Crocker Brandenburg InternetWorking bbiw.net Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
On Mon, 21 Dec 2009, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Eternal Non-Existence of SINK.ARPA (and other stories) ' draft-jabley-sink-arpa-02.txt as a BCP I would like to see a requirement (or at least a recommendation) that DNS or application software must/should not have any special knowledge of the fact that SINK.ARPA does not exist; they should discover its nonexistence when and if they try to follow a reference to the name, in the same way that they discover the nonexistence of any other domain names. In the examples, I would like to see reinforcement of the above principle. For example, the should in Installing an MX record ... should cause compliant MTAs to ... is a prediction about the behaviour of compliant MTAs when encountering *any* nonexistent domain name; it is not a requirement for special treatment of the SINK.ARPA name, but some people might interpret the exmple as a requirement for special treatment. I don't like the name SINK much; calling something a sink implies that traffic can be sent to it, and that such traffic will be read and discarded, but that's not what's going on here. I prefer NONEXISTENT.ARPA or some variation on that theme. --apb (Alan Barrett) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: separate out SINK and registry, was Last Call: draft-jabley-sink-arpa
If it's a good idea to have a registry of DNS names with special meanings, I'd rather see one RFC that establishes and populates a registry of them, perhaps as an update to RFC 2606. Such a registry might also usefully include names that have special meanings within DNS names such as _service from 2782 and _domainkey from 4871. At this point I'm agnostic about the utility of adding SINK.ARPA to such a registry, since I don't know how much in practice the helpful rewriting of NXDOMAIN by some caches would interfere with its use. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
I have long held this view Jim -Original Message- From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest- boun...@rfc-editor.org] On Behalf Of Bob Hinden Sent: Tuesday, December 22, 2009 12:41 PM To: Russ Housley Cc: Olaf Kolkman; xml2...@lists.xml.resource.org; IETF discussion list; Bob Hinden; rfc-inter...@rfc-editor.org; dcroc...@bbiw.net Subject: Re: [rfc-i] Important: do not publish draft-iab-streams- headers-boilerplates-08 as is! On Dec 22, 2009, at 12:08 PM, Russ Housley wrote: Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Bob ___ rfc-interest mailing list rfc-inter...@rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
Date:Wed, 23 Dec 2009 09:15:01 -0800 (PST) From:IESG Secretary iesg-secret...@ietf.org Message-ID: 20091223171501.7bae33a6...@core3.amsl.com Given ... | There exist codecs that can be widely implemented and easily | distributed, but that are not standardized through any SDO; according to | reports, this lack of standardization and clear change control has | hindered adoption of such codecs in interactive Internet applications. (quoted from the proposed charter) it seems to me that the primary goal of this (proposed) WG should be to pick one (or perhaps more) of those, and standardise it (ie: document it). As long as you're not infringing anyone's IP by doing that, the problem looks solved, without the need to invent yet another... (it doesn't matter if the authors of the codec go and change it, that changed version would not be the IETF standard version, just the one in he RFC - until a revised RFC is published, of course.) kre ps: the proposed charter goes on for way too long about why encumbered technology isn't the right solution, if at all possible - most of that is not (or should not be) needed here. It isn't wrong, just unnecessary. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Internet Wideband Audio Codec (codec)
Hi Robert, Date:Wed, 23 Dec 2009 09:15:01 -0800 (PST) From:IESG Secretary iesg-secret...@ietf.org Message-ID: 20091223171501.7bae33a6...@core3.amsl.com Given ... | There exist codecs that can be widely implemented and easily | distributed, but that are not standardized through any SDO; according to | reports, this lack of standardization and clear change control has | hindered adoption of such codecs in interactive Internet applications. (quoted from the proposed charter) it seems to me that the primary goal of this (proposed) WG should be to pick one (or perhaps more) of those, and standardise it (ie: document it). As long as you're not infringing anyone's IP by doing that, the problem looks solved, without the need to invent yet another... (it doesn't matter if the authors of the codec go and change it, that changed version would not be the IETF standard version, just the one in he RFC - until a revised RFC is published, of course.) That's something for the working group to figure out. My experience: things are typically more complicated than they initially look like. kre ps: the proposed charter goes on for way too long about why encumbered technology isn't the right solution, if at all possible - most of that is not (or should not be) needed here. It isn't wrong, just unnecessary. WG charters are also written for those who have not followed the history of the work very closely. These folks typically need a bit more background information. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
Date:Wed, 23 Dec 2009 21:48:18 +0200 From:Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com Message-ID: 3d3c75174cb95f42ad6bcc56eb450204c...@fiesexc015.nsn-intra.net | That's something for the working group to figure out. | My experience: things are typically more complicated than they initially | look like. Yes, of course, but the proposed charter goes to great lengths to point out why solutions from the first and third of the three categories of existing codecs are no good, but it more or less ignored the middle category - then, it seemed to me, more or less demanded that a new codec (or perhaps codecs) be developed. That's the wrong approach, the emphasis should be on adopting something that exists, if at all possible, and only inventing something new if there really is no other choice. That's why I'd prefer the charter to be revised with that in mind. | WG charters are also written for those who have not followed the history | of the work very closely. These folks typically need a bit more | background information. Yes, but no-one needs that much ... (no need to delete all of that stuff about encumbered technology, just most of it) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Internet Wideband Audio Codec (codec)
Hi, I am not sure but are you suggesting that the IETF will define the requirements, metric and quality assessment requirements and all proposed codecs should provide the results and then the WG will choose the best codec bases without discussing the codec itself. This is what I would call a selection process (at least in ITU terms). The problem is that the IETF process allows anyone to contribute to existing work hopefully leading to a better the end result. What about the change control, does it stay with the original contributor or can the IETF modify the codec based on input from other parties, which means that the codec may change by the IETF anyhow. Thanks Roni Even -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Elz Sent: Wednesday, December 23, 2009 10:40 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: i...@ietf.org; ietf@ietf.org Subject: Re: WG Review: Internet Wideband Audio Codec (codec) Date:Wed, 23 Dec 2009 21:48:18 +0200 From:Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com Message-ID: 3d3c75174cb95f42ad6bcc56eb450204c...@fiesexc015.nsn-intra.net | That's something for the working group to figure out. | My experience: things are typically more complicated than they initially | look like. Yes, of course, but the proposed charter goes to great lengths to point out why solutions from the first and third of the three categories of existing codecs are no good, but it more or less ignored the middle category - then, it seemed to me, more or less demanded that a new codec (or perhaps codecs) be developed. That's the wrong approach, the emphasis should be on adopting something that exists, if at all possible, and only inventing something new if there really is no other choice. That's why I'd prefer the charter to be revised with that in mind. | WG charters are also written for those who have not followed the history | of the work very closely. These folks typically need a bit more | background information. Yes, but no-one needs that much ... (no need to delete all of that stuff about encumbered technology, just most of it) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Internet Wideband Audio Codec (codec)
Hi, I am not sure but are you suggesting that the IETF will define the requirements, metric and quality assessment requirements and all proposed codecs should provide the results and then the WG will choose the best codec bases without discussing the codec itself. This is what I would call a selection process (at least in ITU terms). The problem is that the IETF process allows anyone to contribute to existing work hopefully leading to a better the end result. What about the change control, does it stay with the original contributor or can the IETF modify the codec based on input from other parties, which means that the codec may change by the IETF anyhow. Thanks Roni Even -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Elz Sent: Wednesday, December 23, 2009 10:40 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: i...@ietf.org; ietf@ietf.org Subject: Re: WG Review: Internet Wideband Audio Codec (codec) Date:Wed, 23 Dec 2009 21:48:18 +0200 From:Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com Message-ID: 3d3c75174cb95f42ad6bcc56eb450204c...@fiesexc015.nsn-intra.net | That's something for the working group to figure out. | My experience: things are typically more complicated than they initially | look like. Yes, of course, but the proposed charter goes to great lengths to point out why solutions from the first and third of the three categories of existing codecs are no good, but it more or less ignored the middle category - then, it seemed to me, more or less demanded that a new codec (or perhaps codecs) be developed. That's the wrong approach, the emphasis should be on adopting something that exists, if at all possible, and only inventing something new if there really is no other choice. That's why I'd prefer the charter to be revised with that in mind. | WG charters are also written for those who have not followed the history | of the work very closely. These folks typically need a bit more | background information. Yes, but no-one needs that much ... (no need to delete all of that stuff about encumbered technology, just most of it) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Requirements Development RFP for Extension to the Data Tracker
Requirements Development RFP for Extension to the Data Tracker The IETF Administrative Oversight Committee (IAOC), on behalf of the IETF, announces this Request for Proposal to develop the requirements for data tracker extensions for Working Group Chairs and Internet-Draft Authors. The successful bidder will enter into a contract with the Internet Society. The current Data Tracker infrastructure provides support for the work of the Internet Engineering Steering Group (IESG), the IETF Secretariat, and through the ietf.org website provides information to the community at large. The current tools are written in Perl and Python and interface with a MySQL database. The primary goal of this project is to develop consensus on a set of requirements for extending the Data Tracker to capture and display the progression of Internet-Drafts (I-Ds) from the time they are accepted as candidate WG documents through to the time the WG Chair requests publication from the IESG, or are declared as being �Dead�, and provide authors, working groups, the leadership and the community the information needed to process, monitor and manage I-Ds. An additional goal is to provide transparency to all community participants into the progress of IETF WGs. One or more of this project�s deliverables may be used to issue an RFP for the design and development of these enhancements to the Data Tracker The RFP can be found at: http://iaoc.ietf.org/rfpsrfis.html Proposals must be received via email at rpellet...@isoc.org no later than January 18, 2010, 5:00 P.M. EST. All questions/inquiries must be submitted in writing and must be received no later than midnight, EST, January 7, 2010. Responses to questions and inquiries shall be posted on the IAOC website, iaoc.ietf.org/rfpsrfis.html by midnight, EST, January 11, 2010. The point of contact regarding this RFP is the IETF Administrative Director, Ray Pelletier. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Internet Wideband Audio Codec (codec)
A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by January 20, 2010. Internet Wideband Audio Codec (codec) - Last Modified: 2009-12-17 Proposed Chair(s): * TBD Real-time Applications and Infrastructure Area Director(s): * Robert Sparks rjspa...@nostrum.com * Cullen Jennings flu...@cisco.com Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings flu...@cisco.com Mailing Lists: General Discussion: co...@ietf.org To Subscribe: codec-requ...@ietf.org In Body: subscribe Archive: https://www.ietf.org/mailman/listinfo/codec Description of Working Group Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications. According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience. Objectives The goal of this working group is to develop a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. Core technical considerations include, but are not necessarily limited to, the following: 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the working group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology Optimizing for very low bit rates (typically below 2.4 kbps) and for non-interactive audio is out of scope because such work might necessitate specialized optimizations. Although the codec produced by the working group might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec. The goal of the working group is to produce only one codec. Based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace
