draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
John, On Sat, 2010-01-09 at 12:25 -0500, John R. Levine wrote: for the record, sink.arpa document was my idea and Joe volunteered to help it has nothing to do with his day time job but is related to something that Joe cares about, having explicit documentation of special cases. In that case, could you work with him to add language to the draft that explains why SINK.ARPA provides something usefully different from FOO.INVALID? The draft has this language: Various top-level domains are reserved by [RFC2606], including INVALID. The use of INVALID as a codified, non-existent domain was considered. However: o INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; o the contents of the root zone are derived by interaction with many inter-related policy-making bodies, whereas the administrative and technical processes relating to the ARPA zone are much more clearly defined in an IETF context; o the use of ARPA for purposes of operational infrastructure (and, by inference, the explicit non-use of a particular name in ARPA) is consistent with the purpose of that zone, as described in [RFC3172]. The reason I keep harping on this is that this looks to me a lot more like a documentation problem than a technical problem. The first bullet might be considered a documentation problem, but the other two are not. You may not think they are valid, but that is a separate discussion, right? -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Minutiae, was Re: Last Call: draft-jabley-reverse-servers ...
John, On Wed, 2010-01-06 at 17:13 -0500, John C Klensin wrote: I am extremely concerned about getting into a situation in which the IETF spends time debating issues that are basically minutiae, designing (or fine-tuning) procedures or naming schemes in a committee of a few thousand. *Getting* into a situation? The IETF spends a great deal of its time in such activities, and has at least for the last 10 years or so (there may have been a golden age before that, although it seems unlikely to me). I think the reality is that there are certain technical issues that: 1. Are simple enough that everyone can understand them 2. Have no completely obvious solution These issues invite long, pointless threads discussing them. Things that require a lot of time to understand the details tend to only have a small handful of experts who discuss them, because there aren't that many people who have the time and/or motivation to get up to speed. Things that have a clear solution tend to only have a few net kooks who argue (loudly, repeatedly, rudely) against this solution. I think a number of process and other efforts have been made over the decades to try to improve the signal-to-noise ratio of IETF discussions. I don't know how successful these have been - perhaps the IAB has metrics on this? I have no further proposals, except perhaps less wringing of hands over the fact that we seemly waste a lot of time arguing over not-so-important stuff. Oh, and we might also remind people who have drafts caught up in a vortex of endless nitpicking that it's not their fault, and there is nothing wrong with their drafts. (Good luck Joe!) :) -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC and 2010?
Christian Huitema wrote: I am trying to prepare a draft using XML2RFC online, and I am getting the error xml2rfc: error: I can't synthesize a date in 2009 around input line 58 Context (format: file_basename:line_in_file:#elem_num:elem ...): CGI5001.1:53:#1:rfc category=std docName=draft-ietf-behave-address-format-03.txt ipr=trust200902 obsoletes=2765 Any idea why? What's the date element in /rfc/front? Best regards, Julian PS: the docName attribute should not contain the file extension, but that's an orthogonal issue... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
Shane Kerr writes: Various top-level domains are reserved by [RFC2606], including INVALID. The use of INVALID as a codified, non-existent domain was considered. However: o INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Hm. Then why doesn't this document supersede 2606's imprecise specification with a better one? o the contents of the root zone are derived by interaction with many inter-related policy-making bodies, whereas the administrative and technical processes relating to the ARPA zone are much more clearly defined in an IETF context; That can be put that more clearly: The IETF doesn't have sufficient authority over the root zone to publish 2606 and ensure its continued accuracy. My answer to that is that if so, then most of 2606 is broken, and it's necessary to much fix more than just the paragraph that defines .invalid. o the use of ARPA for purposes of operational infrastructure (and, by inference, the explicit non-use of a particular name in ARPA) is consistent with the purpose of that zone, as described in [RFC3172]. Ie. if .invalid has to be dumped, the replacement should be in .arpa. I can accept that. _If_ it has to be dumped. Maybe .invalid was a bad choice in the first place. But that's water under the bridge. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC and 2010?
Christian Huitema [mailto://huit...@microsoft.com] writes: I am trying to prepare a draft using XML2RFC online, and I am getting the error xml2rfc: error: I can't synthesize a date in 2009 around input line 58 Context (format: file_basename:line_in_file:#elem_num:elem ...): CGI5001.1:53:#1:rfc category=std docName=draft-ietf-behave- address-format-03.txt ipr=trust200902 obsoletes=2765 Any idea why? I can get the same thing by using a date element like date year=2009 and making xml2rfc fill in the rest. Change it to date year=2010 :-). -- Christian Huitema ___ 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: draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
On Mon, 2010-01-11, Arnt Gulbrandsen wrote: Ie. if .invalid has to be dumped, the replacement should be in .arpa. I can accept that. _If_ it has to be dumped. Maybe .invalid was a bad choice in the first place. But that's water under the bridge. My understanding was that the intended usages are slightly different: *.invalid could be used in places that if it accidentally got out onto the internet it would do no harm to any legitimate domains. It was also acceptable for a resolver to recognize that .invalid was invalid and short circuit the DNS lookup. sink.arpa seems to be intended to allow for recursive lookup and a proper NXDOMAIN to be returned as normal. I think that it is specifically intended NOT be treated specially by resolvers. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC and 2010?
Glen Zorn wrote: Christian Huitema [mailto://huit...@microsoft.com] writes: I am trying to prepare a draft using XML2RFC online, and I am getting the error xml2rfc: error: I can't synthesize a date in 2009 around input line 58 Context (format: file_basename:line_in_file:#elem_num:elem ...): CGI5001.1:53:#1:rfc category=std docName=draft-ietf-behave- address-format-03.txt ipr=trust200902 obsoletes=2765 Any idea why? I can get the same thing by using a date element like date year=2009 and making xml2rfc fill in the rest. Change it to date year=2010 :-). ... Yes. Both xml2rfc and rfc2629.xslt allow you to default year/month/day, but only as long as the values you *do* provide match the current date. For IDs, my recommendation is to *always* set all three elements, so that when the document is regenerated later again, it will have the proper submission date. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC and 2010?
Julian Reschke [mailto:julian.resc...@gmx.de] writes: ... I can get the same thing by using a date element like date year=2009 and making xml2rfc fill in the rest. Change it to date year=2010 :-). ... Yes. Both xml2rfc and rfc2629.xslt allow you to default year/month/day, but only as long as the values you *do* provide match the current date. For IDs, my recommendation is to *always* set all three elements, so that when the document is regenerated later again, it will have the proper submission date. I'm a little puzzled by this: why would I want to regenerate a draft? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC and 2010?
Glen Zorn wrote: I can get the same thing by using a date element like date year=2009 and making xml2rfc fill in the rest. Change it to date year=2010 :-). ... Yes. Both xml2rfc and rfc2629.xslt allow you to default year/month/day, but only as long as the values you *do* provide match the current date. For IDs, my recommendation is to *always* set all three elements, so that when the document is regenerated later again, it will have the proper submission date. I'm a little puzzled by this: why would I want to regenerate a draft? ... Maybe you only have the XML source under version control, and you want to check the actual text you submitted? (without relying on somebody else having it archived). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
At 04:36 11/01/2010, Arnt Gulbrandsen wrote: Shane Kerr writes: Various top-level domains are reserved by [RFC2606], includingINVALID. The use of INVALID as a codified, non-existent domainwas considered. However: o INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Hm. Then why doesn't this document supersede 2606's imprecise specification with a better one? That is a decent suggestion, not sure how well it will be accepted. We tried to be much more precise in what sink.arpa is than invalid specification. My suggestion would be to say that any NEW uses of .invalid as a non existing name MUST use sink.arpa. As for old uses if possible they should migrate to sink.arpa. there is no inter operability issue that I can think of only lag in changing code. As for .invalid its intended use seems to be more of a documentation use than protocol use. Note: As for .invalid the definition seem to me be more of a document .invalid is intended for use in on-line construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. Obvious at a glance implies human to me. o the contents of the root zone are derived by interaction with many inter-related policy-making bodies, whereas the administrative and technical processes relating to the ARPA zone are much more clearly defined in an IETF context; That can be put that more clearly: The IETF doesn't have sufficient authority over the root zone to publish 2606 and ensure its continued accuracy. My answer to that is that if so, then most of 2606 is broken, and it's necessary to much fix more than just the paragraph that defines .invalid. I prefer not to do 2606 rewrite, I can agree to update 2606 saying .invalid SHOULD NOT be used on the wire. o the use of ARPA for purposes of operational infrastructure (and, by inference, the explicit non-use of a particular name in ARPA) is consistent with the purpose of that zone, as described in [RFC3172]. Ie. if .invalid has to be dumped, the replacement should be in .arpa. I can accept that. _If_ it has to be dumped. Maybe .invalid was a bad choice in the first place. But that's water under the bridge. Arnt __ Historical note: RFC2606 was done in hurry to get the names into document before ICANN had really started to function. Speculation: Even if the current ICANN is unlikely to allow wild card in the root zone, that may change == .invalid suddenly exists. IETF/IAB can prevent addition of wild card to .arpa. Action: Next version of sink.arpa should say that .arpa MUST NOT have a wild card as that will render sink.arpa. useless. Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Minutiae, was Re: Last Call: draft-jabley-reverse-servers ...
--On Monday, January 11, 2010 10:21 +0100 Shane Kerr sh...@isc.org wrote: John, On Wed, 2010-01-06 at 17:13 -0500, John C Klensin wrote: I am extremely concerned about getting into a situation in which the IETF spends time debating issues that are basically minutiae, designing (or fine-tuning) procedures or naming schemes in a committee of a few thousand. *Getting* into a situation? The IETF spends a great deal of its time in such activities, and has at least for the last 10 years or so (there may have been a golden age before that, although it seems unlikely to me). Well, yes. I should perhaps have said open up yet another set of opportunities. I think the reality is that there are certain technical issues that: 1. Are simple enough that everyone can understand them s/can understand/believes that they understand/ 2. Have no completely obvious solution s/$/ and, even if they do, that obvious solution, while consistent with general understanding, raises complications or issues that are not so easy to understand/ These issues invite long, pointless threads discussing them. Things that require a lot of time to understand the details tend to only have a small handful of experts who discuss them, because there aren't that many people who have the time and/or motivation to get up to speed. Things that have a clear solution tend to only have a few net kooks who argue (loudly, repeatedly, rudely) against this solution. My modifications above are intended to suggest that there is a third case: a simple approach that seems to be a clear solution to those who actually don't understand the issues (but think they do) and that appears to raise other issues (if not be outright wrong) to those who think they have a more in-depth understanding of the issues and possible side-effects. Where we get into trouble isn't just the ranting, it is the fundamental disconnect about what constitutes an adequate understanding of the problem. For this case, the community has traditionally given IANA a lot of discretion about selecting particular names and numbers. There are some important reasons for that, as well as just avoiding noise. Moving into a situation in which we require IETF consensus for name selection or alteration is actually a fairly big deal (having IANA consult the community to see if anyone sees bad side effects is another matter entirely and both reasonable and precedented). I think a number of process and other efforts have been made over the decades to try to improve the signal-to-noise ratio of IETF discussions. I don't know how successful these have been - perhaps the IAB has metrics on this? I have no further proposals, except perhaps less wringing of hands over the fact that we seemly waste a lot of time arguing over not-so-important stuff. Let's save that discussion for another time, but I think it would be safe to say that, typically, the community waits until there is actually a crisis before making any significant changes and then tends to get in a hurry and apply partial solutions that end up causing new sets of problems. Oh, and we might also remind people who have drafts caught up in a vortex of endless nitpicking that it's not their fault, and there is nothing wrong with their drafts. (Good luck Joe!) :) right. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hi, Regardless of the exact status of the PLC IPR, I don't think it would be a good idea to just say that the Internet should just follow ITU-T standards with a 20-year lag. As it has been already shown with the codec proposals received to date, it should be possible to create RF codecs that are *much* better than G.722 and G.711. Jean-Marc Quoting Steve Underwood ste...@coppice.org: On 01/11/2010 11:00 PM, Christian Hoene wrote: Dear Herve Taddei, Besides, I don't think you would have any trouble to propose at ITU-T some new appendices to G.711 and G.722 that could fit your goals. An appendix is non normative (a bit like the informative reference to G.711 PLC in iLBC). By the way, if I am not wrong, some basic ITU-T G.722 PLCs are RF. This was my understanding, too. The G.722 spec is 23 years old, so it would be difficult for any of the patents on that spec to still be valid. The ITU patent database does list US patent 5528629 as related to G.722, but I assume this is an error. The patent dates from so long after G.722 came out, and its contents do not appear relevant to G.722. However, the recent additions for PLC are: G.722 (1988) App IV - Broadcom has claims G.722 Appendix III - Broadcom has claims G.722 Appendix IV - France Telecom has claims. Have you seen any clear statements that those patents may be used royalty free? Steve ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-allbery-afs-srv-records
Cyrus Daboo wrote: Hi, --On January 8, 2010 7:28:51 AM -0800 The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS SRV Resource Records for AFS ' draft-allbery-afs-srv-records-03.txt as a Proposed Standard This spec needs to wait on the IANA SRV registry document (draft-ietf-tsvwg-iana-ports) that is being revised and also blocking a couple of SRV-related drafts I have been working on too. Once that is done it should register its new services using the new procedure. -- Cyrus Daboo I do not think so. Rationale: This draft aligns perfectly with the present RFCs, and it has been pro-actively aligned with draft-gudmundsson-dnsext-srv-clarify-00 (disclaimer: of which I am a co-author) and the last working copy of draft-ietf-tsvwg-iana-ports circulated early in December (unfortunately an updated official version is still not out yet). draft-ietf-tsvwg-iana-ports aims at feeding into the new unified Service Names and Port Numbers IANA registry all existing, well documented use cases, including a big bunch of non-IETF service names held so far in a private registry. A new RFC or I-D accepted for publication wouldn't matter much in the multi-thousands of entries to be populated in the new registry, and the services for which this draft now specifies DNS SRV record based service discovery have been registered in the present Port Numbers registry since almost two decades. Past experience seems to indicate that processes in TSVWG aren't very fast; I would be positively surprised if tsvwg-iana-ports would make it faster than the average 4 years or so in TSVWG. It therefore seems not reasonable to penalize other useful work that is carefully crafted to align with present and -- as far as can be expected -- ongoing work on a revised IANA registry, and stall that work indefinitely. Last year, three documents have passed the IESG performing unreasonable assignments, or even have been directed to do so, in the RFC 952 (ARPANET Hosts File and DNS WKS record) IANA registry (as discussed on apps-discuss and tsvwg). We now need to do extra work to back out these inappropriate additions before freezing that WKS registry (one of the tasks to be fulfilled by the Service registries cleanup draft Olafur and I am working on, as agreed upon at IETF in Hiroshima. In contrast, there is no 'damage' done by a document like the AFS SRV Usage draft under IETF LC, since the services for which this draft now specifies DNS SRV based service discovery have been IANA- registered (and assigned default port numbers) many many years ago. The draft does not change these registrations in any way, and the entries will be carried over by IANA to the new registry per the planned procedures for the implementation of tsvwg-iana-ports. Further, AFAICS, our proposals to add specific fields related to the support of service discovery to the new registry have not been accepted; we have not even be confirmed that it indeed will be possible to file, as specifically tagged references in that new registry, documents detailing service discovery procedures for existing application protocols that do not change these applications/services. Thus, according to the current state-of-work-in-progress, the draft under IETF LC at most could perform a contact information update, if it were approved after tsvwg-iana-ports. Therefore, I support publishing this document, essentially as is, and without delays. IMO, we should not hold off such work that could well live without the new Service Names and Port Numbers registry. The issues I had found in that memo in the past all have been resolved in the most recent draft iterations. Because of the impending delays with tsvwg-iana-ports, IANA considerations have been cut off the current draft intentionally. A dummy IANA Cons. section might perhaps be supplied for conformance to the formal rules. I'm sure the authors are willing to provide the proper registration if and when that new registry will be finalized, should that still be deemed necessary after the data harvesting by IANA for the initial population of that registry. Please note well that there are many (hundreds, if not thousands) of much more obscure entries to be imported into the new registry that will cause much more work for IANA than the four entries affected by this draft. Procedural note: There als are precedents for RFCs published with new registrations during pending fundamental revision of a registry. For instance, RFC 5333 has been published recently (and known deficiencies in it have been accepted) although the Enumservices registry is currently undergoing major changes, simply because the implementation plan of the new registry foresees migration of all existing registrations to the new format and the registered objects were deemed necessary and useful. Kind regards, Alfred Hönes. --
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hi, I'm not sure royalties are the *least* of out problems, but I certainly agree with Stephan that annoyances go further than just royalties. I understand that BCP79 restricts what we can say about that in the charter, but at least mentioning the problem as Stephan suggests is a good idea IMO. In some sense, this is again part of the making it easy to redistribute. Jean-Marc Stephan Wenger wrote: Hi, Russ' language is an improvement. But let's not forget that there are encumbrances that have nothing to do with paying royalties, but are equally problematic from an adoption viewpoint. Examples: 1. Co-marketing requirement: need to put a logo of the rightholder company on one's products acknowledging using the protected technology. 2. Unreasonable (from the viewpoint of the adopter) reciprocity requirements: one of many examples would be if you use this technology, you agree not to assert, against me or my customers, any of your patents. Otherwise your license terminates.. 3. Requirement for a postcard license. Such a requirement may rule out open source implementations under certain open source licenses. I believe strongly that a charter that discusses IPR issues should mention at least those three aspects, and/or provide sufficiently vague language to allow for an appropriate reaction to those and other encumbrances that may show up. Royalties are the least of our problems. Regards, Stephan Disclaimer: I have clients that would have problems with all three encumbrances mentioned above. On 1/7/10 11:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 1/7/10 9:46 AM, Russ Housley wrote: Andy: Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the working group. I appreciate the potential difficulty of guaranteeing the unencumbered status of any output of this group. However, I would like this statement to be stronger, saying that this group will only produce a new codec if it is strongly believed by WG rough consensus to either be unencumbered, or freely licensed by the IPR holder(s), if any. I do not think that anyone wants the outcome to be yet another encumbered codec. I think these words are trying to say what you want, but they are also trying to be realistic. Does the following text strike a better balance? Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adapting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties. That seems reasonable. Although I was only the BoF co-chair, I'll volunteer to hold the pen on edits to the proposed charter. Peter ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Yes, it very nicely captures the spirit of the BoF's charter discussion to date. Mike - Original Message - From: codec-boun...@ietf.org codec-boun...@ietf.org To: Russ Housley hous...@vigilsec.com Cc: co...@ietf.org co...@ietf.org; ietf@ietf.org ietf@ietf.org; i...@ietf.org i...@ietf.org Sent: Fri Jan 08 21:43:49 2010 Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) I like that. On 2010-01-08 18:14, Russ Housley wrote: Good improvement. I'd go a slide bit further: Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adapting encumbered technologies; however, the working group will try to avoid encumbered technologies that would hinder free redistribution in any way. Russ On 1/7/2010 3:13 PM, Jean-Marc Valin wrote: Hi, I'm not sure royalties are the *least* of out problems, but I certainly agree with Stephan that annoyances go further than just royalties. I understand that BCP79 restricts what we can say about that in the charter, but at least mentioning the problem as Stephan suggests is a good idea IMO. In some sense, this is again part of the making it easy to redistribute. Jean-Marc Stephan Wenger wrote: Hi, Russ' language is an improvement. But let's not forget that there are encumbrances that have nothing to do with paying royalties, but are equally problematic from an adoption viewpoint. Examples: 1. Co-marketing requirement: need to put a logo of the rightholder company on one's products acknowledging using the protected technology. 2. Unreasonable (from the viewpoint of the adopter) reciprocity requirements: one of many examples would be if you use this technology, you agree not to assert, against me or my customers, any of your patents. Otherwise your license terminates.. 3. Requirement for a postcard license. Such a requirement may rule out open source implementations under certain open source licenses. I believe strongly that a charter that discusses IPR issues should mention at least those three aspects, and/or provide sufficiently vague language to allow for an appropriate reaction to those and other encumbrances that may show up. Royalties are the least of our problems. Regards, Stephan Disclaimer: I have clients that would have problems with all three encumbrances mentioned above. On 1/7/10 11:08 AM, Peter Saint-Andrestpe...@stpeter.im wrote: On 1/7/10 9:46 AM, Russ Housley wrote: Andy: Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the working group. I appreciate the potential difficulty of guaranteeing the unencumbered status of any output of this group. However, I would like this statement to be stronger, saying that this group will only produce a new codec if it is strongly believed by WG rough consensus to either be unencumbered, or freely licensed by the IPR holder(s), if any. I do not think that anyone wants the outcome to be yet another encumbered codec. I think these words are trying to say what you want, but they are also trying to be realistic. Does the following text strike a better balance? Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adapting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties. That seems reasonable. Although I was only the BoF co-chair, I'll volunteer to hold the pen on edits to the proposed charter. Peter ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
Jean-Marc, FWIW, I agree with the other encumbrances issues that Stephan raises. The Co-Marketing requirement assumes that a logo (or other acknowledgement form) has marketing VALUE to the rightholder. In that sense, such a requirement has a worth (i.e., has some value related to money) that is the equivalent of a monetary payment for some. Indeed, many companies would reject use of the technology for this reason (this has been the case for some audio codecs already). The co-marketing encumbrance does NOT affect the easiness or hardness of the redistribution per se ... but rather the attractiveness of the receiving company to accept it. These annoyances are sticky wickets indeed ... limited only be creativeness of people to put non-monetary conditions on the technology after-the-fact (as is their right). FWIW#2 - I think you have probably addressed the issue as far as feasible for now. Ciao, Michael Ramalho -Original Message- From: codec-boun...@ietf.org [mailto:codec-boun...@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, January 07, 2010 3:13 PM To: Stephan Wenger Cc: co...@ietf.org; Russ Housley; ietf@ietf.org; i...@ietf.org Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec) Hi, I'm not sure royalties are the *least* of out problems, but I certainly agree with Stephan that annoyances go further than just royalties. I understand that BCP79 restricts what we can say about that in the charter, but at least mentioning the problem as Stephan suggests is a good idea IMO. In some sense, this is again part of the making it easy to redistribute. Jean-Marc Stephan Wenger wrote: Hi, Russ' language is an improvement. But let's not forget that there are encumbrances that have nothing to do with paying royalties, but are equally problematic from an adoption viewpoint. Examples: 1. Co-marketing requirement: need to put a logo of the rightholder company on one's products acknowledging using the protected technology. 2. Unreasonable (from the viewpoint of the adopter) reciprocity requirements: one of many examples would be if you use this technology, you agree not to assert, against me or my customers, any of your patents. Otherwise your license terminates.. 3. Requirement for a postcard license. Such a requirement may rule out open source implementations under certain open source licenses. I believe strongly that a charter that discusses IPR issues should mention at least those three aspects, and/or provide sufficiently vague language to allow for an appropriate reaction to those and other encumbrances that may show up. Royalties are the least of our problems. Regards, Stephan Disclaimer: I have clients that would have problems with all three encumbrances mentioned above. On 1/7/10 11:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 1/7/10 9:46 AM, Russ Housley wrote: Andy: Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the working group. I appreciate the potential difficulty of guaranteeing the unencumbered status of any output of this group. However, I would like this statement to be stronger, saying that this group will only produce a new codec if it is strongly believed by WG rough consensus to either be unencumbered, or freely licensed by the IPR holder(s), if any. I do not think that anyone wants the outcome to be yet another encumbered codec. I think these words are trying to say what you want, but they are also trying to be realistic. Does the following text strike a better balance? Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adapting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties. That seems reasonable. Although I was only the BoF co-chair, I'll volunteer to hold the pen on edits to the proposed charter. Peter ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-allbery-afs-srv-records
Alfred Hönes a...@tr-sys.de writes: I'm sure the authors are willing to provide the proper registration if and when that new registry will be finalized, should that still be deemed necessary after the data harvesting by IANA for the initial population of that registry. I'm happy to revise this document for any SRV record changes in the future and produce new RFCs as needed to align with new procedures. Unsurprisingly, I selfishly would prefer not to wait on significant re-engineering of SRV record management if it's going to take some time. As Alfred says, I don't think this document adds new problems that would have to be taken into account by such work. It tries to align as closely as possible with how SRV records are used for other existing services. I suspect I'd argue that Cyrus's work also shouldn't be blocked. :) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
I wonder how far away from the original discussion about the charter we already are. Many of these discussions should happen in a future working group. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hi Jean-Marc, I don't think anything has been shown, with respect to IPR and RF properties of the current input proposal documents. And I don't believe anything conclusive will be shown, ever. At best, arguably, nothing substantial has been shown against an RF claim of the input proposals. Arguably, because the Skype assurance in https://datatracker.ietf.org/ipr/1164/ is hardly a strongly worded, binding, non-assert or license. Theoretically, even the 23 year timeframe (of publication of G.722) does not (yet) provide full certainty under US law against patent encumbrances; though the position of a G.722 user is probably very strong now. Look up prosecution laches if you want to know how I came to these conclusions. I completely agree that we should not exclusively rely on 20 year old technologies on a mission to make the Internet work better, not even on the grounds of patent fears. Expect me to use this argument occasionally :-) Stephan On 1/11/10 7:32 AM, Jean-Marc Valin jean-marc.va...@usherbrooke.ca wrote: Hi, Regardless of the exact status of the PLC IPR, I don't think it would be a good idea to just say that the Internet should just follow ITU-T standards with a 20-year lag. As it has been already shown with the codec proposals received to date, it should be possible to create RF codecs that are *much* better than G.722 and G.711. Jean-Marc Quoting Steve Underwood ste...@coppice.org: On 01/11/2010 11:00 PM, Christian Hoene wrote: Dear Herve Taddei, Besides, I don't think you would have any trouble to propose at ITU-T some new appendices to G.711 and G.722 that could fit your goals. An appendix is non normative (a bit like the informative reference to G.711 PLC in iLBC). By the way, if I am not wrong, some basic ITU-T G.722 PLCs are RF. This was my understanding, too. The G.722 spec is 23 years old, so it would be difficult for any of the patents on that spec to still be valid. The ITU patent database does list US patent 5528629 as related to G.722, but I assume this is an error. The patent dates from so long after G.722 came out, and its contents do not appear relevant to G.722. However, the recent additions for PLC are: G.722 (1988) App IV - Broadcom has claims G.722 Appendix III - Broadcom has claims G.722 Appendix IV - France Telecom has claims. Have you seen any clear statements that those patents may be used royalty free? Steve ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ 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: draft-jabley-sink-arpa vs foo.invalid
o INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Hm. Then why doesn't this document supersede 2606's imprecise specification with a better one? Agreed. The current bits on the wire for .INVALID, i.e., none, match any plausible improved specification, after all. o the contents of the root zone are derived by interaction with many inter-related policy-making bodies, whereas the administrative and technical processes relating to the ARPA zone are much more clearly defined in an IETF context; That can be put that more clearly: The IETF doesn't have sufficient authority over the root zone to publish 2606 and ensure its continued accuracy. My answer to that is that if so, then most of 2606 is broken, and it's necessary to much fix more than just the paragraph that defines .invalid. Here's some proposed language which I believe accurately describes the current situation: o RFC 2680 documents a binding agreement between the IETF and ICANN with regard to the operation of the IANA. In particular, Section 4.3 requires ICANN's management of the root zone to comply with the IETF's assignments of domain names for technical uses, such as those described in RFC 2606. Some people believe that ICANN or its successor may unilaterally break this agreement, although there is no evidence to support or refute this hypothesis. o the use of ARPA for purposes of operational infrastructure (and, by inference, the explicit non-use of a particular name in ARPA) is consistent with the purpose of that zone, as described in [RFC3172]. o Some people believe that ICANN is less likely to mess with .ARPA than with .INVALID, although there is no evidence to support or refute this hypothesis. Also, based on recent mail here: o DNS caches and proxies have in a few cases been observed to replace nonexistent names with synthesized records, typically the A record of a web server, in violation of standards and best practices. Some people believe that noexistent names in .ARPA are less likely to be replaced than names in .INVALID, although there is no evidence to support or refute this hypothesis. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
What China blocks or doesn't block is quite irrelevant to what kind of service we can expect on the IETF meeting network in Beijing, as has previously been carefully explained. We have a document that has been humorously referred to as the Host Requirements Document. Enough said. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Mon, 11 Jan 2010, Paul Hoffman wrote: At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 11:18 AM, Paul Hoffman wrote: At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark So, are there likely to be problems with paper copies of the magazine at customs? Is it available at English-language newsstands? What other sorts of publications should our attendees leave at home for fear of violating national standards with which me might not be familiar? Are thre likelto be be digital media searches of the sort feared at US and UK customs checkpoints? I suppose DVDs with copies of Pure Heart. Clear Mind episodes would be right out. We wouldn't want to end up like this guy: http://www.amnesty.org/en/appeals-for-action/end-persection-falun-gong-practitioner What other land mines are we likely to step on by accident? Who is going to provide training to the community to keep these sorts of incidents from happening? Sorry, I seem to be just chock full of snarky questions today. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On 1/11/2010 10:11 AM, Dean Willis wrote: What other sorts of publications should our attendees leave at home for fear of violating national standards with which me might not be familiar? This sort of pre-reality schadenfreude can't possibly serve any constructive purpose. Really, it would be nice to have this list spared from such inventive, inflammatory fantasies. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Sorry, my has been shown statement was about making something much better than G.722/G.711. The IPR part is something that would need to be discussed within a future WG (subject to BCP79 and all). Jean-Marc Quoting Stephan Wenger st...@stewe.org: Hi Jean-Marc, I don't think anything has been shown, with respect to IPR and RF properties of the current input proposal documents. And I don't believe anything conclusive will be shown, ever. At best, arguably, nothing substantial has been shown against an RF claim of the input proposals. Arguably, because the Skype assurance in https://datatracker.ietf.org/ipr/1164/ is hardly a strongly worded, binding, non-assert or license. Theoretically, even the 23 year timeframe (of publication of G.722) does not (yet) provide full certainty under US law against patent encumbrances; though the position of a G.722 user is probably very strong now. Look up prosecution laches if you want to know how I came to these conclusions. I completely agree that we should not exclusively rely on 20 year old technologies on a mission to make the Internet work better, not even on the grounds of patent fears. Expect me to use this argument occasionally :-) Stephan On 1/11/10 7:32 AM, Jean-Marc Valin jean-marc.va...@usherbrooke.ca wrote: Hi, Regardless of the exact status of the PLC IPR, I don't think it would be a good idea to just say that the Internet should just follow ITU-T standards with a 20-year lag. As it has been already shown with the codec proposals received to date, it should be possible to create RF codecs that are *much* better than G.722 and G.711. Jean-Marc Quoting Steve Underwood ste...@coppice.org: On 01/11/2010 11:00 PM, Christian Hoene wrote: Dear Herve Taddei, Besides, I don't think you would have any trouble to propose at ITU-T some new appendices to G.711 and G.722 that could fit your goals. An appendix is non normative (a bit like the informative reference to G.711 PLC in iLBC). By the way, if I am not wrong, some basic ITU-T G.722 PLCs are RF. This was my understanding, too. The G.722 spec is 23 years old, so it would be difficult for any of the patents on that spec to still be valid. The ITU patent database does list US patent 5528629 as related to G.722, but I assume this is an error. The patent dates from so long after G.722 came out, and its contents do not appear relevant to G.722. However, the recent additions for PLC are: G.722 (1988) App IV - Broadcom has claims G.722 Appendix III - Broadcom has claims G.722 Appendix IV - France Telecom has claims. Have you seen any clear statements that those patents may be used royalty free? Steve ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
--On Monday, January 11, 2010 12:11 -0600 Dean Willis dean.wil...@softarmor.com wrote: ... What other sorts of publications should our attendees leave at home for fear of violating national standards with which me might not be familiar? Are thre likelto be be digital media searches of the sort feared at US and UK customs checkpoints? ... Dean, Many of us have been to China multiple times. I am not aware of anyone who has been granted a business or professional visa, and who has gone and behaved professionally, having nearly the problems with entry or exit that have been typical of the US in recent years (even returning US citizens). I've encountered some long lines, bad multilingual signage, and miscellaneous confusion on occasion, but China clearly has no monopoly on those. However, if you are feeling this threatened about the situation, I would encourage you to make comments on your visa application that are harshly critical of the Chinese government. The visa will probably be denied on that basis (almost any government that requires that visas be issued prior to arrival would do the same thing), and then you would get to complain about being excluded from the meeting -- that would be lots more fun than making things up to be frightened about. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hannes, To me the discussion suggests that what is missing in the charter is a requirement for a gap analysis document after finalizing the requirements. There was an email from Cullen on January 7th discussing this point Roni Even -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, January 11, 2010 6:25 PM To: co...@ietf.org; ietf@ietf.org; i...@ietf.org Subject: RE: [codec] WG Review: Internet Wideband Audio Codec (codec) I wonder how far away from the original discussion about the charter we already are. Many of these discussions should happen in a future working group. Ciao Hannes ___ 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: China blocking Wired?
Dean, Get real. When have you EVER had any reading material inspected by ANY authority ANYWHERE in the world? OK, so I am not aware of your particular reading habits and yes, I *can* imagine that *some* material *might* attract the attention of customs officials in any given part of the world, but it would have to be pretty extreme and you would have to literally wave it in front of their faces. WIRED Magazine does NOT in any way fall into the sort of material I am imagining, and I think you know that. We should obviously obey the laws of the country in which we have our meeting, but dreaming up worst case scenarios isn't helpful. Really. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Mon, 11 Jan 2010, Dean Willis wrote: So, are there likely to be problems with paper copies of the magazine at customs? Is it available at English-language newsstands? What other sorts of publications should our attendees leave at home for fear of violating national standards with which me might not be familiar? Are thre likelto be be digital media searches of the sort feared at US and UK customs checkpoints? I suppose DVDs with copies of Pure Heart. Clear Mind episodes would be right out. We wouldn't want to end up like this guy: http://www.amnesty.org/en/appeals-for-action/end-persection-falun-gong-practitioner What other land mines are we likely to step on by accident? Who is going to provide training to the community to keep these sorts of incidents from happening? Sorry, I seem to be just chock full of snarky questions today. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 12:41 PM, John C Klensin wrote: Many of us have been to China multiple times. I am not aware of anyone who has been granted a business or professional visa, and who has gone and behaved professionally, having nearly the problems with entry or exit that have been typical of the US in recent years (even returning US citizens). I've encountered some long lines, bad multilingual signage, and miscellaneous confusion on occasion, but China clearly has no monopoly on those. Thanks, John! I feel very reassured. How about some practical guidance for the folks who haven't been there multiple times, beyond Behave professionally and don't do anything stupid. We have lots of people who don't know they're being stupid because in their world, what they're doing is absolutely normal and they have absolutely no expectation of consequences. These sorts of things can be subtle. A friend's brother was arrested in the UAE last year for possession of melatonin, which is a common over-the-counter sleep therapy in most of the world but is apparently considered a major narcotic in their airport (although you can supposedly buy it OTC in stores in-country). He was very surprised at this, having never even thought it might be an issue. If we were meeting in Dubai, I'd expect medications to be a major problem. But we're not meeting in in Dubai, but China, and China quite likely has equivalent surprises in store. Quite possibly, neither you nor I have ever run afoul of them due to a combination of luck and discretion (which I occasionally DO exercise). But also quite possibly, they'll trip up some of our colleagues. Unlike the US, whose border- liabilities are fairly well understood by IETFers, I'm pretty sure we generally don't know what the likely problems are in China. We need to find out, and we need to educate our community about them. If we (the IETF) can't even figure out what China is doing to Internet traffic, how are we supposed to understand the laws that aren't in our area of expertise? If they think Wired Magazine is dangerous enough that it must be blocked, chances are that they'd find the contents of my home PC appalling (I do too, it runs Windows XP). How about what's on Alice's laptop? For example: As I understand it, one is allowed to bring only one camera and one computer, not two of each. Will this affect camera-and- computer loving IETFers? Possibly, if it's still true. Does the camera in your cell phone count against the quota? How about the one built in a Macbook? I'm much more concerned about the prohibition that goes Printed matter, films, photos, gramophone records, cinematographic films, loaded recording tapes and video- tapes,compact discs (videoaudio), storage media for computers and other articles which are detrimental to the political, economic, cultural and moral interests of China. That's pretty nebulous. It reads to me like leave behind all personal digital media, just in case which is what I generally do. I travel in a fairly sanitized mode, for numerous reasons. Will the average IETFer do this? If not, what, if anything, is likely to surprise them? How many IETFers are going to lose their currency-exchange receipts and consequently be unable to legally turn their excess yuan back into dollars? Or is this still even a problem? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On 2010-01-12 07:11, Dean Willis wrote: On Jan 11, 2010, at 11:18 AM, Paul Hoffman wrote: At 10:32 PM -0600 1/10/10, Dean Willis wrote: Very interesting, from an IETF-hosting perspective. snarkI cannot imagine going to an IETF meeting and not being able to read Wired magazine while I am there./snark So, are there likely to be problems with paper copies of the magazine at customs? Is it available at English-language newsstands? Well, it is just as relevant to suggest that you don't take the last Economist for 2009 to Malaysia for the next APRICOT meeting (naked Adam and Eve on the front cover) and don't carry pseudoephedrine tablets on your next vacation in New Zealand. Oh, and don't travel to the Anaheim IETF from Nigeria. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC and 2010?
Hi - From: Julian Reschke julian.resc...@gmx.de To: Glen Zorn g...@net-zen.net Cc: 'Christian Huitema' huit...@microsoft.com; 'The IETF' ietf@ietf.org Sent: Monday, January 11, 2010 3:16 AM Subject: Re: XML2RFC and 2010? ... Maybe you only have the XML source under version control, and you want to check the actual text you submitted? (without relying on somebody else having it archived). ... That will only work if one also has the generating tool and library files (such as the bibliography data) under version control as well, and if one trusts the tool suite to have no other date-dependent behaviour. From a configuration management perspective, those are some huge ifs. I think one would be safer keeping both the source and the submitted generated files under version control. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hi, We fully share the points 1) and 2) stated in the e-mail below from Cullen since implementing and deploying a new codec in networks (gateways, service plate-forms, mediaservers...) and in terminals represents high costs for service providers, manufacturers and chipset providers in terms of development, deployment and testing with risks to create bugs and problems affecting customers. Furthermore, this multiplies the problems of interoperability with already deployed codecs and the transcoding needs to be addressed with related costs (gateways) and quality degradations. Therefore, the 3 stages mentionned are essential to be run sequentially: (1) get consensus on the requirements, (2) see if an existing codec meets the requirements, and (3) specify a new codec only if none are found in stage 2. Initially the WG would be chartered for (1) and when that was done it would be re-charted for (2) and so on. Requirements established first in stage 1 shall be sent for stage 2 to other SDOs as stated in the current version of the Charter: The working group will communicate detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements (however in the current version of the Charter, it is inconsistent to state first that the goal of the WG is to develop of a new codec and to state some lines after that existing codecs will be considered...) Based on the answers collected from these SDOs, conclusion for stage 2 shall be delivered and constitute the input and prerequisit for any decision to continue in stage 3 to produce a new codec and re-Charter the Group for this We therefore propose to limit the Charter to stage 1 and re-formulate it as follows : - Developers of Internet audio applications and operators of Internet audio services have expressed the need for 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. 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 produce a set of requirements for an 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. Once the first requirement establishment stage completed, the working group will then communicate detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to jointly analyse and determine if existing standardized codecs meet the requirements or can be efficiently adapted to meet them. This work will constitute a second stage that will be discussed and agreed with the relevant SDOs and the WG Charter will be updated accordingly If no existing standardized codec fullfill the requirements nor can be easily adapted to meet them, the working group will analyse and decide if such codec can be produced which may constitute the last stage of the work for which the WG will be re-chartered again. In completing its
Re: China blocking Wired?
On Jan 11, 2010, at 1:21 PM, Ole Jacobsen wrote: Dean, Get real. When have you EVER had any reading material inspected by ANY authority ANYWHERE in the world? OK, so I am not aware of your particular reading habits and yes, I *can* imagine that *some* material *might* attract the attention of customs officials in any given part of the world, but it would have to be pretty extreme and you would have to literally wave it in front of their faces. WIRED Magazine does NOT in any way fall into the sort of material I am imagining, and I think you know that. That's a pretty naive position, Ole. I've had training manuals confiscated at the Canadian border, had my laptop data searched in a couple of places, had my bags detained for setting off chemical detectors (although returned after secondary searching), had a science- fiction paper-back book confiscated (apparently the cover image was pornographic, although they didn't bother to arrest me, and thankfully, I had already finished the book), and probably quite a few other events over the years. I've even had the sorts of jobs where everything on my person, including papers, got inspected by guards when I was going in and out of the workplace each day. I'm really surprised you haven't had events like this yourself. We should obviously obey the laws of the country in which we have our meeting, but dreaming up worst case scenarios isn't helpful. Really. Sometimes it is hard for outsiders to understand those laws you so blithely say we should obey. Laws can and do catch people by surprise. One of the most effective ways to prevent surprise is by as king what if questions. Do you not think it is reasonable to subject the real- world to the same sort of scenario analysis that we would demand of a transport protocol? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On 1/11/2010 11:52 AM, Dean Willis wrote: How about some practical guidance for the folks who haven't been there multiple times, beyond Behave professionally and don't do anything stupid. We have lots of people who don't know they're being stupid because in their world, what they're doing is absolutely normal and they have absolutely no expectation of consequences. Methinks you are implicitly suggesting that the IETF's pages for a site should include some getting along in the site's country guidance as an on-going requirement. Methinks this is an excellent idea. Happily, Doing Business in... types of books are common, as is online information. For example: Chinese Etiquette http://www.goingtochina.com/misc/chinese_etiquette.htm China (especially see the Appearance, Behavior and Communications sections) http://www.cyborlink.com/besite/china.htm Chinese Culture http://chinese-school.netfirms.com/businessculture.html But also quite possibly, they'll trip up some of our colleagues. Unlike the US, whose border-liabilities are fairly well understood by IETFers, Probably not as well understood as we might think, and less so, now, with the newly-explicit policy of being unpredictable. Historically, inconsistencies from one US airport to another have been pretty common. It's really great fun to have a staffer at one airport firmly instruct me on how to avoid future problems at security, with what I carry and how I pack it, given conflicting, firm instruction that I'll get a few months later at another airport. Here's an example, from my personal repertoire: How many batteries is acceptable for you to carry? Is it the same at every airport? How can yo find out the answer? If we (the IETF) can't even figure out what China is doing to Internet traffic, how are we supposed to understand the laws that aren't in our area of expertise? Go to pick someone up at San Francisco International, at International Arrivals. There are signs that shout that this is only for immediate pickup. There is a solid line, away from the curb. Cross that line, and stop at the curb, with the passenger not already standing there -- that is, if you expect to wait a (very) short time -- and you will get a ticket. Not a warning, but a ticket. There is nothing in the signage to tell you this. Not knowing local laws is a pervasive problem. On 1/11/2010 11:55 AM, Brian E Carpenter wrote: Oh, and don't travel to the Anaheim IETF from Nigeria. Let's be fair. Traveling to Orange County even from San Francisco is pretty risky, if they find out you are from Northern California. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On 2010-01-11, at 14:52, Dean Willis dean.wil...@softarmor.com wrote: Unlike the US, whose border-liabilities are fairly well understood by IETFers, Seriously? I cross the US-Canada border all the time, and I'm a citizen of both countries, and I can still barely keep up with the constant, apparently random revocations niggly little details of local conventions at each crossing since last I crossed there. That people whose native language isn't English are totally flummoxed by the US rules is amply demonstrated to me every time I enter the US. Not to mention US citizens who cannot _believe_ that these rules apply to them. I don't want to get into a (IMO fatuous) debate about which geopolitical arrangement is more troubling than others. I merely want to point out that it's just nonsense to use the current US conventions as an example of those obviously well understood. -- Andrew Sullivan a...@shinkuro.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
Dean, Oddly, I've had none of the experiences you've had and I've been known to travel a bit (1.6 million miles on United, top frequent flier honors on 3 carriers (UAL, NWA, JAL) simultaneously, etc.), including to quite a few places where folks from the US weren't particularly popular. The only place I've had secondary screening has been in the US (most recently last week flying from IAD to LAX). The only country in which I've had to even power on equipment to demonstrate it isn't a prop has been the US. I've never had anything confiscated. Well, OK, I did have a nail cuticle clipper (with a 1/4 inch blade) confiscated in Singapore but somehow I was able to survive. This really isn't that hard. Unless you have diplomatic or some other treaty-based immunity, you are subject to the laws of the country you are in and it is your responsibility to be aware of those laws. Some countries follow the rule of law more than others and some countries are more corrupt than others. China is better than some, worse than others. That's reality. If you don't like this, don't go. Regards, -drc On Jan 11, 2010, at 12:21 PM, Dean Willis wrote: On Jan 11, 2010, at 1:21 PM, Ole Jacobsen wrote: Dean, Get real. When have you EVER had any reading material inspected by ANY authority ANYWHERE in the world? OK, so I am not aware of your particular reading habits and yes, I *can* imagine that *some* material *might* attract the attention of customs officials in any given part of the world, but it would have to be pretty extreme and you would have to literally wave it in front of their faces. WIRED Magazine does NOT in any way fall into the sort of material I am imagining, and I think you know that. That's a pretty naive position, Ole. I've had training manuals confiscated at the Canadian border, had my laptop data searched in a couple of places, had my bags detained for setting off chemical detectors (although returned after secondary searching), had a science-fiction paper-back book confiscated (apparently the cover image was pornographic, although they didn't bother to arrest me, and thankfully, I had already finished the book), and probably quite a few other events over the years. I've even had the sorts of jobs where everything on my person, including papers, got inspected by guards when I was going in and out of the workplace each day. I'm really surprised you haven't had events like this yourself. We should obviously obey the laws of the country in which we have our meeting, but dreaming up worst case scenarios isn't helpful. Really. Sometimes it is hard for outsiders to understand those laws you so blithely say we should obey. Laws can and do catch people by surprise. One of the most effective ways to prevent surprise is by as king what if questions. Do you not think it is reasonable to subject the real-world to the same sort of scenario analysis that we would demand of a transport protocol? -- Dean ___ 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: XML2RFC and 2010?
Randy Presuhn wrote: ... That will only work if one also has the generating tool and library files (such as the bibliography data) under version control as well, and if one trusts the tool suite to have no other date-dependent behaviour. From a configuration management perspective, those are some huge ifs. I think one would be safer keeping both the source and the submitted generated files under version control. ... The output of the tool shouldn't change unless the input changes. And yes, I also think that references either need to be in-line, or version controlled with the source :-). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 11:36 AM, Andrew Sullivan wrote: Seriously? I cross the US-Canada border all the time, and I'm a citizen of both countries, and I can still barely keep up with the constant, apparently random revocations niggly little details of local conventions at each crossing since last I crossed there. I'm in the same situation and I've frequently got dogs with me, and the understanding of what's okay and what's not varies not only by which border crossing I'm using but also by which agent - they have problems keeping up with policies and especially policy changes, too. That said, I've got a very good idea of what to expect and how it will go. In all these years I've only been really surprised once, and it was by a Canadian customs agent, not an American. What Dean said seems tautologically true to me, at least for people who travel. On the other hand, I've found that a policy of Don't be a jerk to the people in the booth has been sufficient even in places that were completely unfamiliar to me and is a reasonable substitute for specific knowledge. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
On Jan 11, 2010, at 2:24 PM, Dave CROCKER wrote: Methinks you are implicitly suggesting that the IETF's pages for a site should include some getting along in the site's country guidance as an on-going requirement. Methinks this is an excellent idea. Happily, Doing Business in... types of books are common, as is online information. For example: Chinese Etiquette http://www.goingtochina.com/misc/chinese_etiquette.htm China (especially see the Appearance, Behavior and Communications sections) http://www.cyborlink.com/besite/china.htm Chinese Culture http://chinese-school.netfirms.com/businessculture.html Excellent idea. Specifically, the IETF-type information should be focussed on those things that are likely to impact IETFers, as opposed to conventional business-folks, at a given destination. We aren't average business travelers: We dress more casually, carry much more electronic equipment, often sport unusual haircuts, have a broader array of medical conditions and food issues, have potentially more diverse reading habits, and so on. We're also a lot more likely to form in clusters that engage in loud debates about politically- sensitive topics. And obviously, we aren't ordinary tourists. How many ordinary tourists show up with a backpack full of wireless access points? Is that legal in China? I don't know, but I'm pretty sure one or more of us will do it. And frankly, we're probably more blasé about international travel than well prepared business people might be. The pickpockets in Paris had an absolute field day with IETFers. I'm sure they were quite grateful for our lack of preparedness, relaxed-fit casual pants pockets, richly loaded wallets and expensive cell phones. We seem to have an assumption that every place is pretty much like every other place, they're all happy to see us, and one hotel conference room is the same as all the others. The risks that a typical IETFer might encounter in Beijing are probably different from what you or I or Ole might encounter, given our ages, fairly conservative appearances, and past travel experiences. I think it might be very useful to think through the possibilities and see if we can pre-empt some of them. I did do a quick scan on the references you thoughtfully provided above, and I found the Appearance, Behavior, and Communications) reference especially interesting, because I just can't imagine a pack of IETFers complying with that set of rules. This is starting to sound like it might be a good Wiki project. Who knows, maybe the IETF can collaborate to produce some useful IPR that isn't an RFC ;-)? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China blocking Wired?
I try not to follow up to postings on this topic, but since I can comment on specifics... Many of us have been to China multiple times. I am not aware of anyone who has been granted a business or professional visa, and who has gone and behaved professionally, having nearly the problems with entry or exit that have been typical of the US in recent years (even returning US citizens). I've encountered some long lines, bad multilingual signage, and miscellaneous confusion on occasion, but China clearly has no monopoly on those. For example: As I understand it, one is allowed to bring only one camera and one computer, not two of each. Will this affect camera-and- computer loving IETFers? Possibly, if it's still true. Does the camera in your cell phone count against the quota? How about the one built in a Macbook? Nope. I entered China in November (Shanghai, for an IPv6 transition workshop the week before IETF 76) with the same two computers that I usually carry to IETF meetings - my work laptop, and an ASUS netbook that I use to drive projectors (which also has a webcam built in), and a cell phone that has a camera built-in, along with my camera. I was admitted to China with no discussion of any of these items. Past performance is not an indicator of future topics of interest, but that's the way it went. Thanks, Spencer, who is amazed that the lines to enter the US from Matamoros are longer than the lines to enter China in either Hong Kong or Shanghai... and move more slowly, even for US citizens! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Review of draft-ietf-behave-turn-uri-05
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-behave-turn-uri-05 Reviewer: Spencer Dawkins Review Date: 2010-01-11 IETF LC End Date: 2010-01-13 IESG Telechat date: (not known) Summary: This draft is almost ready for publication as a Proposed Standard. I have a couple of minor questions, shown below in sections 3 and 6.1. Nits and readability comments aren't actually part of the review - they're for the author and editors... Spencer 1. Introduction The TURN specification [I-D.ietf-behave-turn] defines a process for a TURN client to find TURN servers by using DNS SRV resource records, but this process does not let the TURN server administrators provision the preferred TURN transport protocol between the client and the server and for the TURN client to discover this preference. Spencer (readability): s/for/does not allow/ ? This document defines an S-NAPTR application [RFC3958] for this purpose. This application defines RELAY as an application service tag and turn.udp, turn.tcp, and turn.tls as application protocol tags. Another usage of the resolution mechanism described in this document would be Remote Hosting as described in [RFC3958] section 4.4. For example a VoIP provider who does not want to deploy TURN servers could use the servers deployed by another company but could still want to provide configuration parameters to its customers without explicitly showing this relationship. The mechanism permits one to implement this indirection, without preventing the company hosting the TURN servers from managing them as it see fit. Spencer (nit): s/see/sees/ [I-D.petithuguenin-behave-turn-uri-bis] can be used as a convenient way of carrying the four components needed by the resolution mechanism described in this document. 3. Resolution Mechanism An Allocate error response as specified in section 6.4 of [I-D.ietf-behave-turn] is processed as a failure as specified by [RFC3958] section 2.2.4. The resolution stops when a TURN client gets a successful Allocate response from a TURN server. After an allocation succeeds or all the allocations fail, the resolution context MUST be discarded and the resolution algorithm MUST be restarted from the beginning for any subsequent allocation. Servers blacklisted as described in section 6.4 of [I-D.ietf-behave-turn] SHOULD NOT be used for the specified duration even if returned by a Spencer (minor): I'm not sure why SHOULD NOT is appropriate here. If this isn't MUST NOT, I'm not sure it should be 2119 language. Is this just saying if you include blacklisted servers, good things will probably not happen? subsequent resolution. First the resolution algorithm checks that the parameters can be resolved with the list of TURN transports supported by the application: Spencer (readability): I'm surprised that the following information is not shown as a table - Table 1 is showing something a lot more straightfoward, so I know you guys know how to create tables! o If secure is false and transport is defined as udp but the list of TURN transports supported by the application does not contain UDP then the resolution MUST stop with an error. o If secure is false and transport is defined as tcp but the list of TURN transports supported by the application does not contain TCP then the resolution MUST stop with an error. o If secure is true and transport is defined as udp then the algorithm MUST stop with an error. o If secure is true and transport is defined as tcp but the list of TURN transports supported by the application does not contain TLS then the resolution MUST stop with an error. o If secure is true and transport is not defined but the list of TURN transports supported by the application does not contain TLS then the resolution MUST stop with an error. o If transport is defined but unknown then the resolution MUST stop with an error. 5. If the first NAPTR query in the previous step does not return any result then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. The SRV algorithm is applied by using each transport in the filtered list of TURN transports supported by the application for the Protocol, host for the Name, turn for the Service if secure is false or turns for the Service if secure is true. The same transport that was used to generate a list of tuples is used with each of this tuples for contacting the TURN server. The SRV algorithm Spencer (nit): s/this/these/ recommends doing an A query if the SRV query returns an error or no SRV RR; in this case
Re: China blocking Wired?
Hi, I just tried in Beijing China, everything is fine while accessing www.wired.com Thanks, Zhen On Mon, Jan 11, 2010 at 12:32 PM, Dean Willis dean.wil...@softarmor.comwrote: According to this article (links to Wired): http://snurl.com/u1gr0 Wired Magazine was or is being blocked by the Chinese national firewall, and they don't know why. Very interesting, from an IETF-hosting perspective. -- Dean ___ 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: China blocking Wired?
Title: Re: China blocking Wired? At 11:31 AM +0800 1/12/10, Zhen Cao wrote: Hi, I just tried in Beijing China, everything is fine while accessing www.wired.com That doesn't mean everything is fine: Dean can still come up with a list of hypothetical problems that would affect the China meeting (but could, of course, never affect meetings in other locations). --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Internationalized Domain Names in Applications (IDNA): Protocol' to Proposed Standard
The IESG has approved the following document: - 'Internationalized Domain Names in Applications (IDNA): Protocol ' draft-ietf-idnabis-protocol-18.txt as a Proposed Standard This document is the product of the Internationalized Domain Names in Applications, Revised Working Group. The IESG contact persons are Lisa Dusseault and Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idnabis-protocol-18.txt Technical Summary The Internationalized Domain Names for Applications (IDNA) revisions are intended to reduce significantly IDNA dependency on specific versions of the Unicode character coding system. The Working Group produced the following documents representing a revision to the earlier IDNA2003 proposed standard [only RFC 3490 is specifically affected]: Definitions: draft-ietf-idnabis-defs-11.txt Protocol: draft-ietf-idnabis-protocol-16.txt Bi-Di: draft-ietf-idnabis-bidi-06a.txt Tables: draft-ietf-idnabis-tables-07.txt Rationale: draft-ietf-idnabis-rationale-13.txt Mappings: draft-ietf-idnabis-mappings-04.txt Of these, Definitions, Protocol, Bi-Di and Tables are normative; Rationale is informative and mappings is optional (Informational). Working Group Summary The initial impetus for the revisiting of the IDNA2003 proposed standards emerged in written form in RFC4690. An informal technical team worked to develop a framework for consideration that was later discussed, edited, and ratified to create the IDNABIS working group in 2008. Readers will note that this is nearly 2010 but the new specifications bear the label IDNA2008 because the work was started in that year. The documents resulting from the IDNABIS Working Group effort have been extensively discussed over a two year period by the WG and by interested parties especially language experts in the Chinese, Japanese and Hangul spaces, speakers of Hebrew, Indic languages as well as a working group of expert Arabic speakers. The WG has had the participation of several Unicode consortium representatives. There was controversy during the development of these documents but a rough consensus has formed around the recommendations. There was an impasse relating to mapping of Unicode characters into other Unicode characters prior to the generation of a punycode equivalent string to produce an A-label [please see the Definitions document]. This was resolved by introducing the non-normative mappings document observing ways in which this aspect of dealing with internationalized domain names might be approached. The principal rationale for re-visiting the IDNA2003 recommendations arose from field experience and a recommendation from the IAB [RFC4690]. A major objective was to re-specify the standard in such a way as to make it independent of changes to the Unicode code set (something that evolves more or less continuously). The method for achieving this is to use the Unicode properties feature (per code-point/character) to determine whether the code point should be allowed, disallowed or used only under certain conditions in domain name labels. There remains the problem of deployment in a world of web servers, browsers and other applications using domain names that may have already implemented the IDNA2003 recommendations. Implementation tactics for dealing with the old and new specifications may vary. Perfect backward compatibility with IDNA2003 was not possible (without simply replicating it, negating the rationale for the redefinition effort of IDNA2008). This is particularly true of the special characters esszet or sharp-S used in German and the final sigma used in Greek. These were mapped into other valid Unicode characters under IDNA2003 but allowed in IDNA2008 because the Unicode code points for these were introduced in the interim between IDNA2003 and IDNA2008 standardization efforts. Registries have several implementation choices including bundled registration of previously mapped and newly allowed characters or rejection of conflicting new registrations. The treatment of languages that are expressed in Right-to-Left form (see Bi-Di document) has been revised relative to IDNA2003 and it is believed that the revision is clearer and more precise in its form and limitations on the use of numeric characters, for example. Document Quality There are test implementations of the rules proposed by IDNA2008 but no released operational software. Such implementations have awaited the achievement of rough consensus on the controversial parts of the new proposals. Inputs from special expert bodies such as a Korean expert language group, an informal Arabic speakers group, and a number of individual commentators from the Unicode community, among others, have contributed to the documents as they now exist. Multiple implementations of the Tables rules have confirmed the stability of the definitions under distinct implementations. ___ IETF-Announce
Protocol Action: 'ESSCertIDv2 update for RFC 3161' to Proposed Standard
The IESG has approved the following document: - 'ESSCertIDv2 update for RFC 3161 ' draft-ietf-pkix-rfc3161-update-09.txt as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3161-update-09.txt Technical Summary The time stamping protocol defined in RFC 3161 requires that the CMS SignedData (RFC 3852), used to apply a digital signature on the time-stamp token, include a signed attribute that identifies the signer's certificate. This document updates RFC 3161 and allows the use of ESSCertIDv2 defined in RFC 5035 to specify the hash of a signer certificate when the hash is calculated with a function other than SHA-1. The update provided by this draft is motivated by interoperability concerns and to facilitate migration to other hash algorithms. Work Group Summary This draft is the second attempt by the PKIX working group to specify an update of RFC 3161 to accommodate the ESSCertIDv2 identifier in RFC 3161 time stamps. Prior to this draft, another author (Denis Pinkas) submitted a draft that would have replaced RFC 3161. The workgroup rejected this draft on the basis that it introduced many material changes to the original RFC that were not viewed as necessary. As a result, this very brief document was created to provide just the necessary updates of ESSCertIDv2. The protocol update portions of this document were very simple and not controversial. The Security Considerations section proved to be a significant challenge, as WG members demonstrated different opinions regarding the nature and severity of the threat mitigated by this protocol update. There was also some disagreement over whether this threat was within the scope of this document. The WG agreed on the present wording after considerable debate. Document Quality The document is very brief and is clearly written. Personnel Steve Kent is the Document Shepherd and Tim Polk is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Framework for Metric Composition' to Informational RFC
The IESG has approved the following document: - 'Framework for Metric Composition ' draft-ietf-ippm-framework-compagg-09.txt as an Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-framework-compagg-09.txt Technical Summary This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics which are useful in practice. Working Group Summary The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noticing. Protocol Quality This is a framework document, implementations for specific situations (spatial, temporal, etc) will be discussed in future documents. Personnel Henk Uijterwaal (h...@ripe.net) is the Document Shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection' to Informational RFC
The IESG has approved the following document: - 'Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection ' draft-ietf-fecframe-dvb-al-fec-04.txt as an Informational RFC This document is the product of the FEC Framework Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-04.txt Technical Summary The Annex E of the DVB-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection: 1-D parity code base layer, and a Raptor code enhancement layer. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet loss at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and the Raptor code which are specified in separate documents Working Group Summary There were no seriously contentious issues during the WG process. The only controversy stemmed from some individuals who did the work in SMPTE and defied this approach in the DVB spec, who felt the IETF should not be doing this work. But there were industry requests for an IETF definition of the DVB spec and so this work progressed. Document Quality Any DVB-compliant implementation will be compliant with the DVP-IPTV AL-FEC specification as well. Personal Document Shepherd Greg Shepherd Responsible Area Director - Magnus Westerlund ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition' to Informational RFC
The IESG has approved the following document: - 'The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition ' draft-xli-behave-ivi-07.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xli-behave-ivi-07.txt Technical Summary This document defines IVI, an early precursor to the standard IPv4 - IPv6 translation solutions worked on in the BEHAVE WG. Working Group Summary This is a submission from outside working groups. It is intended for publication as a record of what has been defined before the standard comes out. The draft has a normative dependency to the standard version and as such will not come out before the standard. Document Quality This mechanism has been implemented and deployed in the CERNET network in China. Personnel There is no Document Shepherd. The responsible Area Director is Jari Arkko. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-dolmatov-cryptocom-gost2814789-08.txt
The IESG has no problem with the publication of 'GOST 28147-89 encryption, decryption and MAC algorithms' draft-dolmatov-cryptocom-gost2814789-08.txt as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18976rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost2814789-08.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, message authentication. Working Group Summary This is not the product of an IETF WG; it is an independent submission to the RFC Editor. RFC Editor Note The IESG has not found any conflict between this document and IETF work. No IESG note is needed. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-dolmatov-cryptocom-gost34102001-08.txt
The IESG has no problem with the publication of 'GOST R 34.10-2001 digital signature algorithm' draft-dolmatov-cryptocom-gost34102001-08.txt as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18661rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dolmatov-cryptocom-gost34102001-08.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification. Working Group Summary This is not the product of an IETF WG; it is an independent submission to the RFC Editor. RFC Editor Note The IESG has not found any conflict between this document and IETF work. No IESG note is needed. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definition of Master Key between PANA Client and Enforcement Point' to Proposed Standard
The IESG has approved the following document: - 'Definition of Master Key between PANA Client and Enforcement Point ' draft-ohba-pana-pemk-04.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohba-pana-pemk-04.txt Technical Summary This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. Working Group Summary This is an output of the PANA working group. Document Quality The document has been reviewed by Jari Arkko and the main design approach verified with the Security ADs. Personnel The Document Shepherd is Alper Yegin. The responsible Area Director is Jari Arkko. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Defining Well-Known URIs' to Proposed Standard
The IESG has approved the following document: - 'Defining Well-Known URIs ' draft-nottingham-site-meta-05.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.txt Technical Summary This proposal creates a well-known Web site location for information like 'robots.txt' and P3P information, any information that is metadata about the Web site. The alternative to this proposal is to continue with one-off well-known names. Working Group Summary This is not a WG product. The open discussion focused on narrow points like the exact characters making up the well-known name, and on points that can be extended in the future like standardized file formats for site meta-data. Document Quality The W3C community has been well-informed and involved in discussions on this document. There's already discussion about using the recommended path for the Mozilla auto-configuration feature under development. Personnel Lisa Dusseault is the Document sponsor. IANA Expert proposed to be Eran Hammer-Lahav (e...@hueniverse.com). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
