Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Wed Jun 8 05:57:15 2011, Pete Resnick wrote: On 6/7/11 11:00 PM, Peter Saint-Andre wrote: And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. Just to throw in my tuppence, once more: I'm entirely in favour of there being a cheaper, rougher, lower-quality grade of specification; I think this should be what Proposed Standard was originally intended to be; I think there is a pressing need for a specification grade to fill this niche within the IETF. In this, I think I'm in agreement with Pete. I am very much against trying to redefine - and at this stage it is a de jure redefinition, as it were - Proposed Standard *or any other RFC grade* to fill this gap. I think customer expectation of the RFC series is now for a much higher quality than RFC 2026 envisaged, and the net result of regrading PS would be that of lowering the quality of the specifications used in the field. In this, I think I'm in agreement with Peter. The best proposal I've seen - and I'd note that I can't recall now if this is Keith Moore's or Scott Bradner's, to my shame - is that of marking up specific I-D documents as being a Stable Snapshot. This proposal seems to have the following benefits: a) It satisfies the two paragraphs above in a non-conflicting manner. That is, it provides everything that RFC 2026's PS was intended to without being an RFC, with all that that moniker currently implies. b) It's fairly obvious, in my view, how to start to use the new grade, and how we might adapt to it in a smooth manner. Working Groups, authors, etc would be able to start to use it in a fairly ad-hoc manner, without the kinds of flag day changes to process that two-maturity-levels seems to imply. So if anyone has the patience for another I-D thrown into the soup, I'm willing to [re]write this one up, assuming the original instigator[s] of the proposal don't wish to. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
Vint Cerf wrote: setting aside interpretation and semantics for a moment, would there be utility in maintaining tables for each instance of Unicode? Yes, because developers will have different versions of Unicode available to them. It would also help developers to migrate by seeing what has changed between versions. v On Tue, Jun 7, 2011 at 10:45 PM, Paul Hoffman paul.hoff...@vpnc.org mailto:paul.hoff...@vpnc.org wrote: On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: I think this is an improvement but there is one issue about which we have slightly different impressions. I hope the difference can be resolved without needing yet more tedious arguments about documentation. Indeed, if such arguments are required, I'd prefer that we just forget about it. Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: 5.1. IDNA-Derived Property Value Registry IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the specifications in Sections 2 and 3 and not by copying the non-normative table found in Appendix B. If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. Changes to the rules (as specified in Sections 2 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [RFC5226]. Note that every reference to the registry is singular. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml doesn't mention 5.2 at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
Paul Hoffman wrote: On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: I think this is an improvement but there is one issue about which we have slightly different impressions. I hope the difference can be resolved without needing yet more tedious arguments about documentation. Indeed, if such arguments are required, I'd prefer that we just forget about it. Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. That was my impression as well when I reviewed RFC 5982 while on IESG. While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: 5.1. IDNA-Derived Property Value Registry IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the specifications in Sections 2 and 3 and not by copying the non-normative table found in Appendix B. If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. Changes to the rules (as specified in Sections 2 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [RFC5226]. Note that every reference to the registry is singular. There is a single registry, but multiple versions of Unicode. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml doesn't mention 5.2 at all. That might be an error created when the registry got setup by IANA. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
+1 --On Wednesday, June 08, 2011 12:50 +0100 Alexey Melnikov alexey.melni...@isode.com wrote: Vint Cerf wrote: setting aside interpretation and semantics for a moment, would there be utility in maintaining tables for each instance of Unicode? Yes, because developers will have different versions of Unicode available to them. It would also help developers to migrate by seeing what has changed between versions. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Contents of the IDNA Derived Properties registry (was; Re: Gen-ART LC review of draft-faltstrom-5892bis-04)
(Subject line changed to reflect my belief that this is not about 5892bis. I've also removed the copy to the gen-art list -- if this isn't about 5892bis, it isn't on their agenda, even though Roni's review may have partially stimulated the thread.) --On Tuesday, June 07, 2011 19:45 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property ... While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: ... Note that every reference to the registry is singular. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables .xml doesn't mention 5.2 at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. Paul, Just to be completely clear about the intent of my comment, while I'm disinclined to split hairs about whether registry (singular) could mean a collection of tables, I completely agree that, if such a historically-threaded collection were desired, it should have been crystal-clear in 5892. And it is not crystal-clear. I think this raises three issues: (1) Whether a historical thread is kept or not, having a registry of derived property values that does not identify which version of Unicode it reflects is of poor utility and a possible source of confusion. If I don't know to what version of Unicode the registry has been updated, I cannot comply with the IDNA requirement that, if I use derived property tables (rather than recalculating based on the rule set), those be consistent with the version of Unicode on my system (the level of difficulty associated with that rule has been discussed on this thread already; let's not revisit it). One can, of course, figure it out by comparing the code points listed as UNASSIGNED with changes in successive Unicode versions, but it seems to me to be much more useful to include Unicode version identification in the registry. I believe that is fully consistent with your reading of 5892. (2) Whether a collection of derived property tables, explicitly tied to versions of Unicode, is useful. Vint has already asked that question and gotten a couple of affirmative answers. Others might disagree, but it seems to me that we need to arrive at a conclusion somehow. (3) If we conclude that it is useful to identify the Unicode version under which a derived property table was compiled and/or to keep a historical thread of tables, how do we get from here (one table, no Unicode version identification) to there. My personal preference, strongly motivated by the amount of energy that has been consumed by the non-change in 5892bis, would be for the IESG to simply request that IANA make those changes; doing so is, IMO, clearly within their authority. If a separate document is needed, I guess I volunteer to write a short I-D. In any event and as suggested above, I don't see any changes in this area as appropriately being part of 5892bis. Tuning what IANA should be keeping in the registry and how it should be identified is not a topic that 5892bis addresses at all. Moreover, if we do need an RFC to make any changes that are desired, that RFC actually would update a standards-track RFC and would hence itself need to be standards-track. Different critter. So I suggest that: (i) We get 5892bis wrapped up and published. It says pretty much what it should say, it doesn't change the basic specification, and even those who don't like the decisions it represents appear to believe that we have spent enough time on it and that continued delay is problematic. (ii) The relevant ADs consider whether a document clarifying the registry content and/or identification information is needed and consult with IANA on that topic as appropriate. If the answer is yes, let's get that document posted and start debating what changes, if any, should be made using it as a foundation (rather than finding new weeds to drag 5892bis into). john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Contents of the IDNA Derived Properties registry (was; Re: Gen-ART LC review of draft-faltstrom-5892bis-04)
The discussion make it clear to me that the tasks for IANA are not clear. It seems that there needs to be a table for each supported version of Unicode. Thats document should state that clearly. It is a point where RFC 5892 seems to be vague, and we should take this opportunity to remove the ambiguity. This document or a future one needs to answer the following question: Who is responsible for generating a new table when the next version of Unicode comes out? Russ On Jun 8, 2011, at 8:32 AM, John C Klensin wrote: (ii) The relevant ADs consider whether a document clarifying the registry content and/or identification information is needed and consult with IANA on that topic as appropriate. If the answer is yes, let's get that document posted and start debating what changes, if any, should be made using it as a foundation (rather than finding new weeds to drag 5892bis into). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dhc-subnet-alloc-12.txt (Subnet Allocation Option) to Informational RFC
I have read parts of the document and I find it ok. The DHCP Server SHOULD allocate a subnet with prefix size less than or equal to the size P specified in the request. In other words, a subnet at least the size requested and possibly bigger. I agree, but prefix size less than or equal to the size P is not very clear, because (1) there is no P in the request but Prefix, size is hard to understand, etc. Maybe it should say the length of the allocated prefix should have a value non-zero and less than or equal to value Prefix in the Request; e.g. if the Request demands a prefix of length 4 the response MUST be of length any of 1, 2, 3 or 4. There is another point which I think is not discussed in this draft. Contrary to allocation of an address, always the Relay and sometimes the Server _must_ update their forwarding/routing tables, according to a specific rule [subnet,IPaddress], when this allocation of a subnet prefix is performed - otherwise packet forwarding won't work (packets don't reach the Host allocated an address from this prefix). typo qis on page 4. Alex Le 08/06/2011 15:39, The IESG a écrit : The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Subnet Allocation Option' draft-ietf-dhc-subnet-alloc-12.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/811/ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
I'm sorry, I seem to have goofed up during mail editing... I meant to write that cassifying 6to4 as historic is INappropriate use of the IETF process in the last sentence. -Martin Martin Rex wrote: George, Wesley wrote: It's time to remove the stabilisers on the IPv6 bicycle. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. In my personal perception, the historic status used to be a technical characterization to indicate that (1) a protocol or technology has been fully replaced by some newer protocol and there is no reason to continue using the original technology anymore because the successor can be used in each of the original usage scenarios today (2) the protocol/technology has been largely put out of use, and its active use has dropped to marginal levels (like less than 1% of the original active use) Personally, I have never conciously used anything related to IPv6 so far, so for me it is difficult to comment, but what has been said looks to me that neither (1) nor (2) apply to 6to4. The user base seems to have always been small, and most of the users of 6to4 simply did _not_ have an alternative -- and its current users still do _not_ have an alternative today. Classification of 6to4 as historic is appropriate use of the IETF process, because it would be a political, but not an accurate technical statement. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? KMThe best current use cases for 6to4 that I'm aware of are: KM- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. That doesn't require IPv6 connectivity to the outside world. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that works and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution. Further, I don't buy the separate tunnel to every host... thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice of tunnel broker, and through the magic of the internet, they're all connected to one another. KM - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. WEG So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it. KM - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT. WEG Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel. KMWidespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it. WEG So Widespread IPv6 has to have reliability and support equivalent to IPv4, yet you're saying that you can expect applications to rely on 6to4 in the meantime despite evidence that it's unreliable, and the virtual guarantee that it won't be supported by the upstream ISP? And you and I disagree about the definition of widespread. I do not think that widespread means every small ISP in every corner of the world supports it ubiquitously and at every price point. I think it means it's available for a majority (50%) of Internet service customers. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. KM With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good
Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsext-rfc2672bis-dname-22 Reviewer: Ben Campbell Review Date: 2011-06-07 IETF LC End Date:2011-06-09 IESG Telechat date: (if known) Summary: This draft does not seem to be quite ready for publication, in that it professes to obsolete RFC 2672, but does not cover all the material from that RFC or explain the absence of the missing material. I also have a few editorial comments that should be considered prior to final publication. Major issues: This draft professes to obsolete RFC2672, but there are multiple sections of that RFC that are not replicated here, nor are their absence explained. I assume, since this draft obsoletes RFC2672, it is expected to completely replace it where an implementor would no longer be expected to read 2672. -- section 4.2 of RFC2672, Processing by Resolvers, is not replicated here, or if it is, it's in a substantially different form. -- section 5, examples of use is not replicated here. Similar examples are mentioned in the introduction, but the detail is removed. None Minor issues: None Nits/editorial comments: -- IDNits has some comments, please check. -- Abstract: This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. The heading says this obsoletes 2672 and updates the other two. It's probably worth explicitly using those words here. -- 3.1, 1st paragraph: Relevant includes the following cases: Awkward sentence. Maybe Relevant cases include the following:? -- 3.1, 5th paragraph: is synthesized and included in the answer section What synthesized it? The server? (passive voice obscures responsibility) -- ... The DNAME has an RRSIG A _signed_ DNAME has an RRSIG, right? -- 4, 4th paragraph: ...should be revised... This document actually executes the revision, right? Better to say this document revises... rather than should be revised -- ..., 7th paragraph: ...replaced with the word DELETED. Won't that just leave the word deleted hanging on page without explanation? Wouldn't it be better to just simply delete it? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Review of draft-ietf-ccamp-gmpls-vcat-lcas-13
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ccamp-gmpls-vcat-lcas Reviewer: Kathleen Moriarty Review Date: June 7, 2011 IETF LC End Date: IESG Telechat date: (if known) Summary: The document is ready with nits listed below. Major issues: Minor issues: Nits/editorial comments: Consider breaking the first sentence of the abstract into two sentences. From: This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. To: This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). The LCAS can be used for hitless dynamic resizing of the inverse multiplex group. Consider changing the dashes to commas in the paragraph before section 2.4: From: Identification of the VCG and its associated members. This provides information that allows the endpoints to differentiate multiple VCGs and to tell what members - label switched paths (LSPs)- to associate with a particular VCG. To: Identification of the VCG and its associated members. This provides information that allows the endpoints to differentiate multiple VCGs and to tell what member, label switched paths (LSPs), to associate with a particular VCG. Section 3: There is a mix of dashes and double dashes used at the start of definitions. Please make the usage consistent (the last one only has one dash). Consider a : instead of double dashes. Last sentence before section 4: Add a comma: From: SONET VCAT group) which is composed of 7 virtually concatenated VC- 4s (or STS-3c). To: SONET VCAT group), which is composed of 7 virtually concatenated VC- 4s (or STS-3c). Consider breaking the last sentence of the second to last paragraph of Section 4.2 up into multiple sentences: A node that receives a Path message that contains changed fields will process the full Path message and, based on the new value of NVC, it will add a component signal to the VCAT group, and switch the new timeslot based on the new label information. There is a stray . Before the last sentence of section 5 and the sentence is indented and I don't think that was intentional. . Conceptual containment relationship between VCG, VCAT calls, control plane LSPs, and data plane connections. Section 5.1, last bullet is another definition, look for consistency in how they are formatted. ___ Gen-art mailing list gen-...@ietf.orgmailto:gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
setting aside interpretation and semantics for a moment, would there be utility in maintaining tables for each instance of Unicode? v On Tue, Jun 7, 2011 at 10:45 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: I think this is an improvement but there is one issue about which we have slightly different impressions. I hope the difference can be resolved without needing yet more tedious arguments about documentation. Indeed, if such arguments are required, I'd prefer that we just forget about it. Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: 5.1. IDNA-Derived Property Value Registry IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the specifications in Sections 2 and 3 and not by copying the non-normative table found in Appendix B. If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. Changes to the rules (as specified in Sections 2 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [RFC5226]. Note that every reference to the registry is singular. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml doesn't mention 5.2 at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Summary for IESG last call to 5892bis draft
Dear all, AD suggests that we send a last call summary to the list. Below is the summary for IESG last call to 5892bis draft. Any comments are welcome. Jiankang Yao as a co-chair of APPSAWG --- Summary: The IESG last call for draft-faltstrom-5892bis-04.txt ended on 6 June. Most participants support the publication of this draft. Nobody explicitly say that they object the publication of this draft. Below are some questions or issues discussed during the IESG last call - issue1: About the text of the first paragraph of the Introduction Peter Saint-Andre:The first paragraph of the Introduction contains a few infelicities and grammatical errors, and I suggest some modifying. Clarification from John C Klensin: We should leave the editing work or modifying work to RFC Editor. -- issue2: About the old IDNAbis WG's decision Clarification from John C Klensin: the WG concluded that Unicode changes of character properties that affected IDNA needed to be evaluated in the IETF on a case-by-case basis as to whether they were important enough to justify an addition to that exceptions table or whether the balance fell on the side of keeping the table small. --- issue3: About the IANA consideration section Roni Even: I am not sure how the IANA consideration section is in-line with the IANA consideration section of RFC5892. Maybe some clarification text would be helpful. Clarification from Paul Hoffman: We think that the IANA considerations here are, in fact, what RFC 5892 was designed for. That is, RFC 5892 says that the registry will be updated (IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2). We are not updating either 5892, nor the registry, by publishing 5892bis. We are simply giving IETF consensus advice about what we think the expert reviewer who updates the registry should consider. We can change the IANA considerations to reflect that: IANA will update the derived property value registry according to RFC 5892 and property values as defined in The Unicode Standard version 6.0, regardless of the content of this RFC. issue4: Add the IANA IDNA registry or replace the old one? Comment from John C Klensin: My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. Comment from Paul Hoffman: While John's interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. Note that every reference to the registry is singular. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml doesn't mention 5.2 at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. *We are waiting for John and Paul reaching the agreement about this issue*** isse5: About non-backward-compatible changes of the table of derived property values Roni Even: Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. Clarification from Paul Hoffman: We intended that as non-backwards-compatible;we can change the wording to make that explicit. --- issue6: About the reference of the IANA registry for derived property value Roni Even: The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done? Clarification from Paul Hoffman: Section 2 of the draft is pretty clear here: No change to RFC 5892 is needed based on the changes made in Unicode 6.0. 5892bis(RFC) will not be listed in the registry. --- issue7: About the impacts on the current implementation of RFC 5892 (the relationship between the rules and the tables) Simon Josefsson：If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. If it marks updating RFC5892, I am afraid that I has
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Summary for IESG last call to 5892bis draft
Well, a little miscommunication; I had meant to send the summary to the APPSAWG where the document was discussed, but sending it to the IETF list is OK too. Since it's here, one comment: On 6/8/11 2:04 AM, Jiankang YAO wrote: issue4: Add the IANA IDNA registry or replace the old one? [...] *We are waiting for John and Paul reaching the agreement about this issue*** I think we have gotten agreement from folks (including but not limited to doc authors and ADs involved in the conversation) that we'll go ahead with this document and write a quick new document clarifying that what 5892 meant was that IANA should *add* a new table to the registry and (with the older one) label it as to from which version of Unicode the table was generated. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On 2011-06-09 04:17, james woodyatt wrote: On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. In any case, I don't see the politics, unless (for example) declaring RFC 1267 Historic was politics too. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Hi - From: james woodyatt j...@apple.com To: ietf@ietf.org Cc: v6...@ietf.org Sent: Wednesday, June 08, 2011 9:17 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. On the other side of the argument, declaring RFC 1227 historic had little (I'm being generous) impact on its continued use. The folks that needed it kept using it, in some cases long after the IETF's replacement for it became widely available. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I'm much more worried about the important part that you didn't quote, that moving 6to4 to historic is a technically inaccurate statement. How about downgrading it (rfc3056+rfc3068, I assume) from Proposed to Experimental, acknowledging the fact that consumers will likely have to set it up themselves, it is rarely going to work out of the box and might not be available in all implementations. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
compromise on the 6to4-Historic debate
I really think that the right answer is to write an applicability statement for 6to4 that: - refers to the existing documents about 6to4 problems - points out use cases for 6to4 which work well, and others that work less well - emphasizes that 6to4 is a short-term solution and was always intended to be such Deprecating 6to4 and declaring it Historic are premature and overkill, but an applicability statement seems entirely appropriate to me. Beyond that, the question of anycast advertisement for 6to4 relay routers (RFC 3068) is a tough one. I'd like to find a way to be able to keep them, because there's a huge utility in being able to automatically configure such things. But everybody acknowledges the problems that are caused when relay routers are advertised in BGP that don't actually get the traffic there. If there's not a way to weed out the bad ones that is easy for operators to implement, maybe RFC 3068 really should be deprecated. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 4:33 AM, TJ wrote: Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). snip It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. That fails, 20% of time. Seems unlikely that it's going to go away anytime soon, draft or no, that said it seems unwise to keep telling the users and implementors to use it. by default. Just my $.02, /TJ ... ready for world IPv6 Day? ___ 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: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 8 Jun 2011, at 21:19, Keith Moore wrote: Nor, bluntly, is it about a few big content providers or whomever else you want to label as important. The internet is a hugely diverse place, and you don't get to dismiss the concerns of people whom you want to label as red herrings. Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. That's about as much as Teredo, it's a hell of a lot more than native v6. As long as 6to4 is one of the major ways that people get IPv6 connectivity (and it clearly is), it's premature to declare 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. Our observation point is as a university on an academic/research network that is native dual-stack. We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected. Hence little if any need for transition methods. This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time. We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since. Perhaps it would be useful to see your use cases more clearly documented with examples. Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 be deprecated. We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is under 1% of our total IPv6 traffic. I don't know where you see 90%; I assume it's an environment with home-to-home networks, with no broker or IPv6 VPN use? That's excellent news. But the current proposal on the table to deprecate 6to4 is premature, confusing, and harmful to real users. The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it? The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from product? It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not take away the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. This draft does redundantly make some recommendations that are also made in I-D.ietf-v6ops-6to4-advisory, which is the companion document with technical content intended for audiences other than the IETF itself. These recommendations mainly say that 6to4 SHOULD NOT be enabled by DEFAULT. Beyond that, the principle point of this draft is to flip a categorization flag that nobody outside IETF cares about. The practical effect of that will be to free the authors of future working group drafts from a procedural requirement to consider whether 6to4 poses any special problems for the subjects of future standards efforts. I'm okay with that, actually, but I have a hard time imagining how it helps them avoid being pragmatic about what's actually deployed in the real world. Reality must take precedence over public relations, as Professor Feynman said. After much consideration on this draft, I have concluded that every moment IETF spends arguing over it is one that would be put to better use discussing almost anything else... even which cute word we should use for the colon-separated fields in the IPv6 address presentation format. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 7:05 PM, Tim Chown wrote: On 8 Jun 2011, at 21:19, Keith Moore wrote: Nor, bluntly, is it about a few big content providers or whomever else you want to label as important. The internet is a hugely diverse place, and you don't get to dismiss the concerns of people whom you want to label as red herrings. Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. That's about as much as Teredo, it's a hell of a lot more than native v6. As long as 6to4 is one of the major ways that people get IPv6 connectivity (and it clearly is), it's premature to declare 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. Our observation point is as a university on an academic/research network that is native dual-stack. We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected. Hence little if any need for transition methods. This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time. I'd love it if we all saw a lot more native IPv6 traffic soon. Just to clarify, the 40% is not from my measurement. It's an approximation to figures I've seen quoted elsewhere. Like you, I'm sure this figure will vary from place to place. I haven't tried to do any measurement myself, because the amount of traffic is not a good indicator of overall usefulness. On the other hand, if any transit provider anywhere in the world is seeing 40% of v6 traffic as 6to4, that is a pretty good indication that somebody (besides myself) is using it. For that matter, the very fact that operators are observing problems with relay routers is another indication that people are using 6to4. Why would they be using it if they didn't want to? I realize that some platforms enable 6to4 by default, but not all of them do. And I've already said I support having hosts and routers ship with 6to4 disabled by default. We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since. Perhaps it would be useful to see your use cases more clearly documented with examples. I've already given examples. People keep looking for more specific examples in an argument where any specific example can be dismissed as irrelevant. It's not any one specific example that matters, it's the fact that people are using 6to4 and there's not an obviously better replacement that's available to them. The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it? NATs are harmful to real users too, and they do a lot more harm than 6to4 does. When will we deprecate them? When will we declare them Historic? It's misleading to talk about only the harm being done by 6to4 without acknowledging the benefits of 6to4 or the lack of a suitable alternative. And to say that 6to4 does harm is misleading. Is it 6to4 that's doing the harm, or people who advertise routes to relay routers that don't function properly? Why are people blaming the 6to4 protocol for configuration errors made by network operators? The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from product? Historic doesn't stop someone who can write his own code. But if it results in implementations removing support for 6to4, declaring 6to4 as Historic will stop people who use those implementations. It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4. I disagree with that assessment, because it's only considering the case of using 6to4 when IPv4 would work just fine. That's not an appropriate metric. Nobody who has native IPv6 connectivity needs to use 6to4 to reach native IPv6 destination addresses. But a deeper problem is the notion that a single set of address selection rules will work well for all, or even most, applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: compromise on the 6to4-Historic debate
In message 92fb2780-5f10-4173-a982-12e114bff...@network-heretics.com, Keith M oore writes: I really think that the right answer is to write an applicability statement f or 6to4 that: - refers to the existing documents about 6to4 problems - points out use cases for 6to4 which work well, and others that work less we ll - emphasizes that 6to4 is a short-term solution and was always intended to be such Deprecating 6to4 and declaring it Historic are premature and overkill, but an applicability statement seems entirely appropriate to me. Beyond that, the question of anycast advertisement for 6to4 relay routers (RF C 3068) is a tough one. I'd like to find a way to be able to keep them, beca use there's a huge utility in being able to automatically configure such thin gs. But everybody acknowledges the problems that are caused when relay route rs are advertised in BGP that don't actually get the traffic there. If ther e's not a way to weed out the bad ones that is easy for operators to implemen t, maybe RFC 3068 really should be deprecated. Keith Have broken 6to4 relays is *good* for the long term health of the Internet. Applications should cope well with one address of a multi-homed server being unreachable. Billions of dollars have been wasted because this has not been seen as a basic requirement for applications. It really isn't any harder in most cases to do this right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: compromise on the 6to4-Historic debate
On Jun 8, 2011, at 11:35 PM, Mark Andrews wrote: Have broken 6to4 relays is *good* for the long term health of the Internet. Applications should cope well with one address of a multi-homed server being unreachable. Billions of dollars have been wasted because this has not been seen as a basic requirement for applications. It really isn't any harder in most cases to do this right. Not that I disagree with the idea that applications should be able to fail over from one address to another, but ... why do you assume that the server is multihomed? The problem with the broken 6to4 relay on an anycast address is that the application (or user, or site) doesn't get to choose a different relay. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dhc-subnet-alloc-12.txt (Subnet Allocation Option) to Informational RFC
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Subnet Allocation Option' draft-ietf-dhc-subnet-alloc-12.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/811/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' to Proposed Standard (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt)
The IESG has approved the following document: - 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ Technical Summary In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). Working Group Summary There was nothing contentious about this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? At the moment the shepherd is not aware of any protocol implementations, and no vendors have directly indicated they plan to implement, although he assumes that all RAMs implementations will ultimately include this, as it is essentially a mandatory part of RAMs. The reviewers are listed elsewhere in the PROTO writeup. There were no external reviews of the types mentioned, because there is no material requiring such review. Personnel Keith Drage is the document shepherd Gonzalo Camarillo is the responsible area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-payload-rfc3016bis-01.txt (RTP Payload Format for MPEG-4 Audio/Visual Streams) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for MPEG-4 Audio/Visual Streams' draft-ietf-payload-rfc3016bis-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, for new system designs [RFC3640] is preferred, which does not have these restrictions. This document obsoletes RFC 3016. A revision of RFC 3016 was required because of some misalignments between RFC 3016 and the 3GPP PSS specification regarding the RTP payload format for MPEG-4 Audio. Changes from RFC 3016 are summarized in Section 11. Issues on backward compatibility to RFC 3016 are discussed in Section 1.3. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3016bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3016bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'URN Namespace for the Defence Geospatial Information Working Group (DGIWG)' to Informational RFC (draft-reed-urn-dgiwg-03.txt)
The IESG has approved the following document: - 'URN Namespace for the Defence Geospatial Information Working Group (DGIWG)' (draft-reed-urn-dgiwg-03.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 Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-reed-urn-dgiwg/ Technical Summary This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Defence Geospatial Information Working Group (DGIWG). DGIWG defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the Defence Geospatial Information Working Group (DGIWG) Registry System (DRS). Working Group Summary This document is not the product of a working group. Document Quality In accordance with RFC 3406, the namespace identifier request has been reviewed on the URN-NID mailing list, and all feedback has been addressed. Personnel The Document Shepherd / Responsible Area Director is Peter Saint-Andre. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
