From ajs@shinkuro.com Wed Apr 7 12:02:48 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39323A6955 for ; Wed, 7 Apr 2010 12:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_50=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvDTHpyW309M for ; Wed, 7 Apr 2010 12:02:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 68A343A68F3 for ; Wed, 7 Apr 2010 12:02:42 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C8F791ECB4E8 for ; Wed, 7 Apr 2010 19:02:37 +0000 (UTC) Date: Wed, 7 Apr 2010 15:02:36 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100407190235.GL485@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eAnxKwVhzStH6fSc" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] Proposed response to ICANN per dns-dir meeting @ Anaheim X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:02:48 -0000 --eAnxKwVhzStH6fSc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, I'm attaching the latest version of a draft response to ICANN's "synchronized domains" plan. My understanding is that Olafur has arranged to forward this to the IESG for their consideration as to whether they will adopt it as an IESG position. Given the short timeline, I'd be astonished if they did. I've therefore been planning that we'll actually be sending this as a group of interested IETF DNS people -- i.e. as individuals. I've contacted some other people around the DNS community to ask whether they'll sign. So far, Paul Hoffman and Paul Vixie have both said yes. Jim Reid has said yes conditionally; he has to clear it with someone first. It would be super if each of you could let me know whether this response can be sent to ICANN over your name. I have to travel on Tuesday, so it would be better if we could post sooner rather than later. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --eAnxKwVhzStH6fSc Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="response-20100407b.txt" Content-Transfer-Encoding: 8bit Thank you for posting, and for the opportunity to comment on, the "Proposed Implementation Plan for Synchronized IDN ccTLDs" (henceforth, the Plan). We are individuals who work on the DNS protocol and on DNS operations, as participants in the Internet Engineering Task Force. We have read the document carefully, and we have some concerns. These concerns lead us to suggest some changes that we'd like to see in the Plan. Summary We believe that the Plan as written is unimplementable consistent with the safe and stable operation of the global DNS. We do not believe a general-purpose plan is a good idea at this time. Given that there is this general-purpose plan, however, we offer a number of suggestions for how it should be rewritten to avoid the problems it presents for the DNS. Before we begin, we want to note a difficulty in the language of the Plan that is not exactly related to the DNS. We believe that one of the motivators for this Plan is to permit synchronized domains in Simplified and Traditional Chinese, both of which use the same language and reside in the same Unicode script. To avoid using the word "script" in a way we don't understand, we will use the somewhat loose term "linguistic encoding", or LE for short, to refer to the Unicode code points relevant to each case at hand. That is, the Plan talks about the case "where more than one official language or script exists within a country/territory, and where requests for multiple corresponding strings are considered equivalent." Supposing there were two such "language[s] or script[s]", we imagine them to be representable in Unicode code point ranges LE1 and LE2 respectively, where the two sets differ by at least one code point. We recognize that this is a little awkward, but we are not linguistics experts and want to confine our remarks to the DNS. So, in our examples, we suppose that TLD1 is expressed in LE1, and TLD2 is expressed in LE2, but that TLD1 and TLD2 are otherwise "considered equivalent" by some relevant population. Similarly, in our examples, a fully-qualified domain "le1.le1.TLD1" is a name made up of three labels, all expressed in LE1; a fully qualified name "le2.le1.TLD2" would be a name made up of three labels, the first and last of which are expressed in LE2 and the middle of which is expressed in LE1. It is also perhaps somewhat unfortunate that the Plan as written is sometimes ambiguous about whether these synchronized IDN ccTLDs are really one TLD, or two. This situation arises partly because of the historically widespread conflation of the administrative and technical boundaries in the DNS, and is by no means unique to this Plan, so we do not propose to fix it. Nevertheless, we wish to be crystal clear: there is today in the DNS but one way to make two different labels at the top level be anything other than different top level domains, and that is to make one a DNAME of the other in the root zone. In any other case, the two labels are, technically speaking, different zones (because they have independent SOA and NS RRsets). For practical purposes, of course, that might not matter. But it does no service to obscure this technical detail, because wherever there is a zone boundary, there is automatically an opportunity for divergence between the zones. One final point before we turn our attention to the Plan: nothing we say here should be interpreted as our support for any general-purpose synchronized domain mechanism. We doubt very much the wisdom of adopting a general-purpose mechanism at present. There is currently an effort in the IETF to understand the requirements for a mechanism or mechanisms to satisfy this need, and the initial evidence suggests that there are completely different kinds of problems facing us. One mechanism may not do. Moreover, it is obvious that there is not much experience with the latest IDNA documents, since those have only just been published as RFCs. In our opinion, therefore, if there is a specific need that is being addressed by this policy, it would be immeasurably better to address only that specific need and use the experience thereby gained as part of the responsible formulation of a general policy. All of that said, it is a general-purpose plan that ICANN has posted for public comment, so we will address that general-purpose plan. A. Issues with the text as written There are several terms in the document that are used in a way that does not make sense in today's DNS. The Plan also requires the requester to commit to enforcing the conditions laid out in the document. In our opinion, such a commitment would be harmful, because the requester would thereby commit to making the DNS behave differently than it actually does. In the Plan, for two domains to be "synchronized", they must "resolve to the same address or value." (There are some other conditions, but for the purposes of the DNS, this is the important one.) The Plan requires a requester to commit to ensuring synchronization of everything below the synchronized TLDs. The first problem with the requirement is that it is nowhere defined what it is for a domain to resolve to a "value". Strictly speaking, domains do not resolve to an address, either. So as written, the requirement just can't be met, though that might be fixed by using (precisely) the well-established terms for how resolution works in the DNS. The next problem with the requirement is that there are features of the DNS used today to provide answers that differ according to varying conditions on the network. These features are exploited by operators, sometimes using CNAMEs and DNAMEs; and therefore even if we fix the definition of "synchronized" as suggested above, such synchronization might not be what we want. We take it for granted that additional security for the DNS, and the deployment of DNS Security Extensions (DNSSEC), must not be prevented by the Plan. DNSSEC depends on RRSIG resource records. Any RRSIGs all the way down two synchronized trees are guaranteed to be different. RRSIGs are generated in part using the fully-qualified name over which the signature is generated. Since those RRSIGs are by definition part of the zone file, it is plain that we cannot just say that the right hand (RDATA) portion of every Resource Record must be the same. Another problem is that "synchronization" appears to suggest that there are data in two locations (the independent zones), copied between those locations. This is problematic in two ways: 1. It does not admit of a solution where one zone is just an alias for the other zone, using provisioning mechanisms like DNAME. 2. It leaves ambiguous exactly what is to be synchronized under the synchronized IDN ccTLD: a. Should DNS names in the zones underneath the two synchronized zones be exactly (bit-for-bit) equivalent to one another? For example, for a fully qualified domain name of the form le1.le1.tld1, must there always and only be a synchronized entry le1.le1.tld2? b. Should all and every label under TLD1 be expressed in LE1 and all and every label under TLD2 be expressed in LE2? For example, for a fully qualified domain of the form le1.le1.tld1 must there always and only be a synchronized entry le2.le2.tld2? c. Should every label at every level of the DNS be expressed in both LE1 and LE2 (the combinatorial case)? For example, for a fully qualified domain name of the form le1.le1.le1.tld1, would it be necessary also to have le1.le1.le1.tld2, le2.le1.le1.tld2, le2.le2.le1.tld2, le2.le2.le2.tld2, le1.le2.le2.tld2, and so on? The Plan requires a requester to commit to "enabling convergence" at every level. This description of things is in many ways better than the other language, because it exposes a crucial fact about the way synchronized TLDs will interact with DNS caches on the Internet: even supposing the zones at the authority servers are always synchronized, there is every reason to suppose that stale data for one of the synchronized zones will persist in caches while data for the other does not. So the plan appears not to be trying to require that DNS caches are synchronized. Unfortunately, that appearance is marred somewhat by the requirement for the requester to include "information about the steps the requester will take to remove any divergence that might occur." This could be read to require the requester to try to avoid divergence across the entire DNS. In any case, some divergence is just a necessary part of the loose coherence of the DNS, because different authority servers for a frequently-updated zone are entirely likely to have different versions of the zone data. In the requirements section, number 2.1, of the Plan, the requester is required to include a description of the requester's plan to "[e]nable through a technical mechanism that synchronized domains resolve to the same address or value in each level of the DNS tree." Apart from the "address or value" issue discussed above, the difficulty here is that there are very few widely-deployed and well-understood mechanisms of the sort requested. There is in fact current work before the DNS Extensions Working Group at the IETF to try to address that gap in the existing functionality. It is therefore not clear what a technical mechanism of this sort would be, nor what the criteria for evaluation of such a mechanism (as required in the evaluation section, number 4) would be. B. Proposed changes or additions to the Plan Because "resolution to the same address or value" is so problematic, we suggest the Plan be changed to define expectations in terms of user experience -- especially since user expectation is the basis for the justification for these synchronized domains. We believe that such changes should be followed by another comment period, because it will be impossible for the DNS community to evaluate the final plan without seeing it first. Our suggestions below try to make the Plan more precise, unfortunately at the expense of readability. We have endeavoured, however, to retain the spirit of the original plan while providing criteria that are measurable by tests in the DNS when those tests are appropriate, and by appeal to language experts when questions about language are to be answered. To achieve our goal, we suggest that "resolution" revert to its technical meaning in the DNS, and that the Plan differentiate between the kinds of things that may resolve differently, and the kinds of things that must resolve the same. We offer the following replacement text: 2.1 Synchronized IDN ccTLDs […] and where requests for corresponding multiple strings are considered equivalent, and users of the community accessing domains under any of the strings expect that such domains will lead to "the same place" on the Internet. These are referred to as synchronized IDN ccTLDs. More formally, synchronized domains have the following properties: a. competent members of the relevant linguistic community or communities regard the domains as equivalent. b. competent members of the relevant linguistic community or communities regard names under each such domain as being "in the same language" as the domain in question. This need not require that each label actually be a word in some natural language, and need not require that every label be made up exclusively of some subset of Unicode characters; but members of the relevant linguistic community must not regard a label as unusable by the community. c. for two synchronized domains s1 and s2, for every {name, class, RRTYPE, RDATA} tuple at any level under s1, there is exactly one corresponding tuple at any level under s2; and conversely. This test is applied at the relevant master server(s) for the name in question. For DNS data proper (rather than control data), the corresponding tuple's class, RRTYPE, and RDATA must be the same. The relationship is transitive to additional domains, so that more than two domains might be synchronized at the same time. For DNS control data, such as SOA, NS, DS, and RRSIG records, the RDATA obviously cannot be the same. These must diverge from one another only to the extent required by proper operation of the DNS, subject to DNS operator policy. The three properties, together, determine the degree of synchronization between or among domains. This degree of synchronization is called "convergence". To the extent that two zones differ, they are said to be divergent. Because of property (3), two ccTLDs will be synchronized if and only if everything beneath them is synchronized. Some divergence is a necessary effect of the loose coherence of the DNS; this divergence is called "transient divergence", because in principle it eventually goes away. Divergence that does not naturally return to convergence is called "persistent divergence". This use of "convergence" and "divergence" is slightly different than the way the words are sometimes used in DNS contexts, since they are sometimes used to refer to the extent to which the set of authority servers for a given DNS zone agree in their answers. It would probably be better to come up with a different pair of words here and define them more precisely, but we do not have a suggestion for such a word at present. Note that, by criterion number 2.1.b, combinatorial synchronization is not the target of this meaning of synchronization: we are supposing that the goal is to help different communities who express "the same word" in different characters to be able to use DNS labels more naturally, so we suppose that the linguistic encoding to be used at every level does not change (this is option 2.b as we outline it in section A of our remarks, above). If combinatorial synchronization is needed, then a different definition is also needed. The same criterion 2.1.b rules out using DNAME, because of the way the DNAME substitution points to a different tree in the DNS (DNAME would be an implementation of option 2.a as we outline in section A). CNAMEs for every resource record in a synchronized domain to another one of the synchronized names would work (though it would be critical to avoid loops, and this might have unhappy effects for mail services and so on). We also suggest that the requirements be altered. Here is some suggested replacement text: 2. Documentation of adequate and verifiable procedures that the requester will use to enable convergence at every level below the IDN ccTLD, including information about the steps the requester will take to remove any divergence that might occur. Such documentation must include descriptions of the registry’s plans to: 2.1. Enable synchronized domains to converge; 2.2 Require in a registration policy that each delegation beneath the synchronized ccTLDs require the same policy of synchronization and enforcement for every delegation beneath it; 2.3 Ensure compliance with the registration policy for synchronized domains; 2.4 Provide timely reports on synchronized IDN ccTLD experiences following the delegation and implementation of the synchronized IDN ccTLDs; 2.5 Migrate in a safe, stable and timely manner to an improved technical standard for the delegation and management of synchronized IDN ccTLDs if established, and applicable for such delegations. 2.6 Determine an acceptable level of transient divergence between synchronized zones, including initial targets for acceptable transient divergence and the methodology by which those targets will be modified over time given additional data from the deployment of the synchronized ccTLDs. We suggest the following change to the Evaluation of Requests section of the Plan: 5.3. Plans for enforcement mechanisms to effectively remove persistent divergence should it occur. Finally, we suggest the following changes to the Terms and Conditions section of the Plan: 2. If any persistent divergence should occur, the Synchronized IDN ccTLD manager shall take immediate steps to remove that divergence. We note that none of our suggestions take into account differences in TTL values for RRsets in the synchronized zones. Neither do we here say anything about DNSSEC signature lifetimes or any policies about DNSSEC keys, for zones where DNSSEC is going to be used; nor whether DNSSEC must be deployed in every synchronized zone if one of the zones is to deploy it. It might be argued that all of these issues are important in ensuring a uniform experience for the target communities of the synchronized TLDs, and that they therefore ought to be considered. Certainly, divergent TTL policies in two synchronized domains will make the actual experience of users on the Internet diverge, and will lead to the impression of persistent divergence even if the authority servers converge. In our comments here, we have attempted to be as conservative as possible in outlining the minimal conditions for synchronization, so we have avoided attempting to constrain the effects on DNS caches. It might be better, however, if agreements required convergence of all DNS timing parameters in the synchronized zones. We hope that our suggestions are helpful to ICANN in ensuring that Synchronized IDN ccTLDs are deployed in a manner consistent with the stability and security of the global DNS, and in a way that enables communities not well served by traditional ASCII DNS labels to use the Internet more easily and without unfortunate surprises. We thank you for the opportunity to offer our comments. Respectfully, [signatories] --eAnxKwVhzStH6fSc-- From ogud@ogud.com Thu Apr 8 11:40:07 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281DE3A6812 for ; Thu, 8 Apr 2010 11:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM-o4Sjezo7r for ; Thu, 8 Apr 2010 11:40:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B33853A677D for ; Thu, 8 Apr 2010 11:40:05 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38Ie1Wg002844 for ; Thu, 8 Apr 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 8 Apr 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100408_184001_080614.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-6man-dns-options-bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:40:07 -0000 Count: 226 Network Working Group J. Jeong, Ed. Internet-Draft Brocade/ETRI Obsoletes: 5006 (if approved) S. Park Intended status: Standards Track SAMSUNG Electronics Expires: October 7, 2010 L. Beloeil France Telecom R&D S. Madanapalli Ordyn Technologies April 5, 2010 IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis draft-ietf-6man-dns-options-bis-00 Abstract This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS search list to IPv6 hosts. From isoma@jellybaby.net Thu Apr 8 14:09:50 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BD43A694D for ; Thu, 8 Apr 2010 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_05=-1.11, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKpeJwURtj80 for ; Thu, 8 Apr 2010 14:09:50 -0700 (PDT) Received: from nebula.c8h10n4o2.org.uk (nebula.c8h10n4o2.org.uk [IPv6:2001:41c8:1:4f3c::2]) by core3.amsl.com (Postfix) with ESMTP id 334D43A67A4 for ; Thu, 8 Apr 2010 14:09:47 -0700 (PDT) Received: from consume.c8h10n4o2.org.uk ([2002:5102:5b62:1::1]) by nebula.c8h10n4o2.org.uk with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Nzyyl-00076Z-53 for dns-dir@ietf.org; Thu, 08 Apr 2010 22:09:35 +0100 From: Tim Bannister Content-Type: multipart/signed; boundary=Apple-Mail-2-396000253; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 8 Apr 2010 22:09:36 +0100 Message-Id: To: dns-dir@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Mon, 12 Apr 2010 07:47:01 -0700 Subject: [dns-dir] draft-huang-ipv6cp-options-00 *-DNS-Address X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:18:46 -0000 --Apple-Mail-2-396000253 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi,=20 I'm writing out of concern over = http://tools.ietf.org/html/draft-huang-ipv6cp-options-00 and the = implications this has for resolver configuration. I'll admit though that = I'm not representing any big vendor or have any influence over how PPP & = IPv6 might get deployed. IPv4 systems commonly configure two addresses for DNS resolution, and = then either use these in a round-robin fashion or by using the secondary = address as a fallback (RFC 1877). Typical operator experience is that = the primary host sees lots of load and the secondary host is mostly = idle. A fault with the primary host affects all users. There are = workarounds such as advertising two hosts at random from a larger set, = but these work around an issue rather than address it. draft-huang-ipv6cp-options-00 proposes copying the same mechanism to = IPV6CP, broadly intact. I think this is an opportunity to improve a = configuration mechanism that could be with us for a fairly long time. = PPP doesn't really give hosts much room to negotiate capabilities, so = whatever gets chosen here will probably stay as a lowest common = denominator. I'd like to see a mechanism that allows for a larger number of = nameservers (at least four) to be advertised, and I'd prefer this to be = without regard to priority. --=20 Tim Bannister =96 isoma@jellybaby.net --Apple-Mail-2-396000253 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJmjCCBEYw ggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYw EQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwz LTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAi hiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55uuUMc YL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV67APpp8z hZrTcY5Qj5ndYjCCBUwwggQ0oAMCAQICECWa4VHSickPA1mYFKq/eCswDQYJKoZIhvcNAQEFBQAw gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0x MDAzMDcwMDAwMDBaFw0xMTAzMDcyMzU5NTlaMIIBFTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRgwFgYDVQQDFA9UaW0gSiBCYW5uaXN0ZXIxIjAgBgkqhkiG9w0B CQEWE2lzb21hQGplbGx5YmFieS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ ZoY3OalranUczY5+dfZXTaHi71pL32EJxibv0UoSj7sTGdCxpK2Q0apC6PQlH4zyNb9BFkPVBWtc u1OAWsbxdpf9UoFaEKznvbjehfe15I7tv28MTIy50PRyVsNiupSoTCM69WkkdLMrbEQGYacfJzqs bCvP5TBjsV08Sg/7JxGpGyA1qJRZrHlfs/2/6YO3+RTYNLkbkRihoBOAMOuyFg56nuEQMyDVqRPe 5SOQg/X5EcUe4FIc8wu9Wr+qEKK6yYZTBKx0qWcyXcUcLOTLvk9oHux2QCrcg/5lNUEaid0yfk7V YAFP077oP4PTBl6RAxrok+SQQe+TkCcCO4+tAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAE PTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8E QzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURp Z2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAHuNDKNNtF/84D2QRpGMULZ44wEjRyvT5tcA Yg3ZdHOdENDrS28W21xNgO/i4QWPfO3YUDHefyIctFr3aqjlL3VxrryOOLvwGWvoBqe0w+smTPlV 9y77LKICmZaVMoLRzf8GPGyPGXqleT8vFq/QT0P4ol6054z1oFSIutJF10lT2P5HDkN+9ClrrbzP DVd7du1JyNrbXhO9tfT8R2w1fFBtjV2yHHtx/5mXHGZvp0f/e3WP+3g/ba4ROr7QN5JAAnYdHOue /LwvB9lHIoSqjAz7V/9qvodvnKVxuMuX+lQhJK88oEGTSSX6l2NkRQm8jFdOlaT2L/NlaxyDCbhG czsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEcyAhAlmuFR0onJDwNZmBSqv3grMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDQwODIxMDkzNlowIwYJKoZIhvcNAQkE MRYEFICV7VbRGhuhBTFo0HIuHQRDJnCyMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICECWa4VHSickPA1mYFKq/ eCswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAlmuFR0onJDwNZmBSqv3grMA0GCSqGSIb3DQEBAQUABIIB AJLDpkr83T3Sqmjku9UbL66s1Oz7Tw3Eyfg5LTcnj0xPwQz/xXLzeN5p4rQKvnM9FBprFKV+SsuC uD3t4FAdOxcg2KCAkeKh8u4/1jEbqaAodEu7qmzhnFaT48/MYgRg8q8DenfW5tTrKXTEfvT5Mar7 1JswnwQdvlqJREanBZCuDaxBZiKekSb1N8K5rAvuvln4WPUOgIpG7R/YFglUs8rUOXemOCjBmi/x LOxkO8mHFcuYw2kR4ejwglZnETHCJXVjmi1XoqhYRVLJsWXm2N6zLj6B1Aqt0QsHI/IaO+3V16DU tcRUgraL0pVVUKv1zCUcyLkJ8gu2ESnOIfiMd6QAAAAAAAA= --Apple-Mail-2-396000253-- From ajs@shinkuro.com Mon Apr 12 09:22:50 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DFE3A6A73 for ; Mon, 12 Apr 2010 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6eOsYXo+sT0 for ; Mon, 12 Apr 2010 09:22:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 173D928C15C for ; Mon, 12 Apr 2010 09:16:45 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E680A1ECB401 for ; Mon, 12 Apr 2010 16:16:39 +0000 (UTC) Date: Mon, 12 Apr 2010 12:16:38 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100412161637.GO11706@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Cgrdyab2wu3Akvjd" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] Solicitation for subscribers in response to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:22:50 -0000 --Cgrdyab2wu3Akvjd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, The previous draft response to ICANN appears to have been obviated by ICANN's clarifying remarks, which appear in the Q&A they posted and in Tina Dam's remarks on the blog. Accordinly, I've prepared a different response to ICANN. I'd like to hear from people who want to subscribe their name to this when I send it. If you don't say that you want your name on it, I won't attach yours. Jim Reid has authorized me to add his name, so there will be at least one other person listed at the bottom. Obviously, suggestions for changes to the text are also welcome. I'm running out of time to work on this, however. I won't have much time today, and tomorrow I leave for a trip to Washington. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --Cgrdyab2wu3Akvjd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="response-20100409b.txt" Thank you for posting, and for the opportunity to comment on, the "Proposed Implementation Plan for Synchronized IDN ccTLDs" (henceforth, the Plan). Thank you also for the clarifications you posted in the form of a set of Questions and Answers on 8 April, 2010. We are individuals who work on the DNS protocol and on DNS operations, as participants in the Internet Engineering Task Force. We have read the documents carefully. We are pleased that the Plan has nothing to do with the DNS protocol, and that you have made it clear that whatever delegations are made from the root zone are simply different DNS delegations with no interdependencies. We understand that synchronization is to be understood entirely in terms of user expectation, and that users' experiences could be made consistent in any number of ways, including by using completely different servers to address the needs of different communities. In light of that, we have two suggestions. First, it would be enormously helpful in the present case, and in similar future cases, if ICANN did not use the terms "resolve" and "address" when the ordinary meaning of those terms is not what is intended. The Q&A web page continues to use the unfortunate expression "to resolve to the same address or value". In the Internet context, "resolve" almost always entails an entanglement with the DNS. Similarly, in the Internet context, "address" almost always means an IPv4 or IPv6 address. For a name to resolve to an address, therefore, means that there be an entry in the DNS such that a lookup of the name results in a response containing the target IPv4 or IPv6 address. Since the Q&A web page is clear that there is no such requirement, given that the two delegations are completely distinct in the DNS, ICANN should use other terms to make its point or risk continuing confusion. We have not been able to understand what it means for something to resolve to "a value". Second, question and answer 9 in the Q&A should be updated. The answer there says, "DNS responses must produce equivalent results. . ." We would prefer that language be removed or somehow altered, because despite the disclaimers immediately following it, it could be misinterpreted as a constraint of what may be part of any of the zone data in question. It needs to be clearer that the test of synchronization is that users should not be surprised and not that there be any congruence of answers in the DNS. Most users have no direct experience of the DNS, and there need be no requirement of any kind on DNS responses. The example should be modified to include the case where delegations under S1 and S2 have similar names, but where the addresses at those names are different. As long as the results the user experienced were the same, (e.g. because the different servers each served localized but otherwise-equivalent content), that would be consistent with ICANN's stated condition for synchronization. It should also be made clearer that the target systems are not only web systems, but any systems; so MX records and such should also be part of the examples. Thank you for this opportunity to contribute to the completion of ICANN's Fast Track process. Sincerely, [signatories] --Cgrdyab2wu3Akvjd-- From peter@denic.de Mon Apr 12 13:31:33 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F83E28C19A for ; Mon, 12 Apr 2010 13:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX6tLtPq5TyM for ; Mon, 12 Apr 2010 13:31:32 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 72DBE28C1A1 for ; Mon, 12 Apr 2010 13:31:31 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1O1QHz-0004LL-VQ; Mon, 12 Apr 2010 22:31:24 +0200 Received: from localhost by x27.adm.denic.de with local id 1O1QHz-000199-Rb; Mon, 12 Apr 2010 22:31:23 +0200 Date: Mon, 12 Apr 2010 22:31:23 +0200 From: Peter Koch To: Andrew Sullivan Message-ID: <20100412203123.GS10562@x27.adm.denic.de> Mail-Followup-To: Andrew Sullivan , dns-dir@ietf.org References: <20100412161637.GO11706@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100412161637.GO11706@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: dns-dir@ietf.org Subject: Re: [dns-dir] Solicitation for subscribers in response to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 20:31:33 -0000 Andrew, all, > results in a response containing the target IPv4 or IPv6 address. > Since the Q&A web page is clear that there is no such requirement, > given that the two delegations are completely distinct in the DNS, > ICANN should use other terms to make its point or risk continuing > confusion. We have not been able to understand what it means for > something to resolve to "a value". it appears to me that this is acknowledging the fact that "addresses" aren't the only data stored in the DNS, but also MX-RRs, NAPTRs - ugly as they are - or some yet-to-be-defined fancy new type. Now that the explanatory text explains that "addresses" are no longer meant to be "addresses" but something (maybe even URLs, maybe more abstract) that leads to "similar user experience", the distinction between addresses and values no longer has much value (apologies for the pun). What I find concerning is that the text is somewhere between misleading and incomprehensible without the Q&A part. In fact, these aren't clarifying but actually constituting the meaning the applicant would have to subscribe to. > Second, question and answer 9 in the Q&A should be updated. The > answer there says, "DNS responses must produce equivalent > results. . ." We would prefer that language be removed or somehow > altered, because despite the disclaimers immediately following it, it > could be misinterpreted as a constraint of what may be part of any of > the zone data in question. It needs to be clearer that the test of > synchronization is that users should not be surprised and not that > there be any congruence of answers in the DNS. Most users have no > direct experience of the DNS, and there need be no requirement of any > kind on DNS responses. The example should be modified to include the > case where delegations under S1 and S2 have similar names, but where > the addresses at those names are different. As long as the results > the user experienced were the same, (e.g. because the different > servers each served localized but otherwise-equivalent content), that > would be consistent with ICANN's stated condition for synchronization. > It should also be made clearer that the target systems are not only > web systems, but any systems; so MX records and such should also be > part of the examples. Thanks for adding this. Still this reads a bit like minor word smithing nits. In my opinion one would either accept the text and Q&A "clarifications", since all these additional suggestions are in line with the inconsistency provided so far -- or it needs a major overhaul. The meta issue here is that "user experience" is at least as fuzzy a term as "confusingly similar". That said, if we'd extend the comments to the Q&A and the Blog entry, we might want to clarify the status of the proposed BNAME RR type and any expectations that may arise from its availability. -Peter From ajs@shinkuro.com Mon Apr 12 13:37:05 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8621D3A685B for ; Mon, 12 Apr 2010 13:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSfWpo6c+4HE for ; Mon, 12 Apr 2010 13:37:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 825B93A677C for ; Mon, 12 Apr 2010 13:37:04 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6AFE41ECB401 for ; Mon, 12 Apr 2010 20:36:58 +0000 (UTC) Date: Mon, 12 Apr 2010 16:36:56 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100412203656.GY11706@shinkuro.com> References: <20100412161637.GO11706@shinkuro.com> <20100412203123.GS10562@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="JsihDCElWRmQcbOr" Content-Disposition: inline In-Reply-To: <20100412203123.GS10562@x27.adm.denic.de> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Solicitation for subscribers in response to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 20:37:05 -0000 --JsihDCElWRmQcbOr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've had some comments back, so a modified version is attached. That said, On Mon, Apr 12, 2010 at 10:31:23PM +0200, Peter Koch wrote: > smithing nits. In my opinion one would either accept the text and Q&A > "clarifications", since all these additional suggestions are in line > with the inconsistency provided so far -- or it needs a major overhaul. . . .this is half the basic problem. The other half is that whereas the other documents are backed up by Board resolutions, the Q&A does not appear to have the force of the Board behind it. So officially, of course, only the Plan is really what's up for consideration. I think it would be churlish to pretend that, however. > That said, if we'd extend the comments to the Q&A and the Blog entry, > we might want to clarify the status of the proposed BNAME RR type > and any expectations that may arise from its availability. See the attached & see if it suffices. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --JsihDCElWRmQcbOr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="response-20100412b.txt" Thank you for posting, and for the opportunity to comment on, the "Proposed Implementation Plan for Synchronized IDN ccTLDs" (henceforth, the Plan). Thank you also for the clarifications you posted in the form of a set of Questions and Answers on 8 April, 2010. We are individuals who work on the DNS protocol and on DNS operations, as participants in the Internet Engineering Task Force. We have read the documents carefully. Prior to the posting of the Q&A, we had several concerns about what might be entailed for the DNS by the Plan. The Q&A, however, makes clear that the Plan is exclusively focussed on administrative arrangements, and has no implications for the DNS protocol. We therefore understant that under the plan, whatever delegations are made from the root zone are simply different DNS delegations with no interdependencies. We understand that synchronization is to be understood entirely in terms of user expectation, and that users' expectations could be more or less satisifed in any number of ways, including by using completely different servers to address the needs of different communities. In light of that, we have two suggestions. First, it would be helpful in the present case, and in similar future cases, if ICANN did not use the terms "resolve" and "address" when the ordinary meaning of those terms is not what is intended. Both the Plan and the Q&A web page use the expression "to resolve to the same address or value". In the Internet context, "resolve" almost always entails an entanglement with the DNS. Similarly, in the Internet context, "address" almost always means an IPv4 or IPv6 address. For a name to resolve to an address, therefore, means that there be an entry in the DNS such that a lookup of the name results in a response containing the target IPv4 or IPv6 address. Since the Q&A web page is clear that there is no such requirement, given that the different delegations are completely distinct in the DNS, ICANN should use other terms to make its point or risk continuing confusion. It is not clear to us what it means for something to resolve to "a value". We are aware that there are many DNS resource records that do not contain addresses (NAPTR records, for instance), and that this is perhaps what is intended. If that is the case, it should be avoided, because the Plan as clarified does not require any real "sameness" in the DNS anyway. Second, question and answer 9 in the Q&A should be updated. The answer there says, "DNS responses must produce equivalent results. . ." We would prefer that language be removed or somehow altered, because despite the disclaimers immediately following it, it could be misinterpreted as a constraint on what may be part of any of the zone data in question. The test of synchronization is that users should not be surprised, and not that there be any congruence of answers in the DNS. Most users have no direct experience of the DNS, and there need be no requirement of any kind on DNS responses. The example should be modified to include the case where delegations under S1 and S2 have similar names, but where the addresses at those names are different. As long as the results the user experienced were what the user expected, (e.g. because the different servers each served localized but otherwise-equivalent content), that would be consistent with ICANN's stated condition for synchronization. It should also be made clearer that the target systems are not only web systems, but any systems; so MX records and such should also be part of the examples. Thank you for this opportunity to contribute to the completion of ICANN's Fast Track process. Sincerely, [signatories] --JsihDCElWRmQcbOr-- From ajs@shinkuro.com Tue Apr 13 02:31:39 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3067628C0F5 for ; Tue, 13 Apr 2010 02:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mItVPN7d9pUy for ; Tue, 13 Apr 2010 02:31:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E149028C1F3 for ; Tue, 13 Apr 2010 02:29:26 -0700 (PDT) Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 82E9D1ECB401 for ; Tue, 13 Apr 2010 09:29:18 +0000 (UTC) Date: Tue, 13 Apr 2010 05:29:08 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20100413092905.GB14232@shinkuro.com> References: <20100412161637.GO11706@shinkuro.com> <20100412203123.GS10562@x27.adm.denic.de> <20100412203656.GY11706@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20100412203656.GY11706@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Solicitation for subscribers in response to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 09:31:39 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've made a couple more changes. I think that I need to send this today. If you have a strong objection, please let me know. So far, only Olafur says he will sign this. A On Mon, Apr 12, 2010 at 04:36:56PM -0400, Andrew Sullivan wrote: > I've had some comments back, so a modified version is attached. That said, > > On Mon, Apr 12, 2010 at 10:31:23PM +0200, Peter Koch wrote: > > > smithing nits. In my opinion one would either accept the text and Q&A > > "clarifications", since all these additional suggestions are in line > > with the inconsistency provided so far -- or it needs a major overhaul. > > . . .this is half the basic problem. The other half is that whereas > the other documents are backed up by Board resolutions, the Q&A does > not appear to have the force of the Board behind it. So officially, > of course, only the Plan is really what's up for consideration. I > think it would be churlish to pretend that, however. > > > That said, if we'd extend the comments to the Q&A and the Blog entry, > > we might want to clarify the status of the proposed BNAME RR type > > and any expectations that may arise from its availability. > > See the attached & see if it suffices. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > Thank you for posting, and for the opportunity to comment on, the > "Proposed Implementation Plan for Synchronized IDN ccTLDs" > (henceforth, the Plan). Thank you also for the clarifications you > posted in the form of a set of Questions and Answers on 8 April, 2010. > > We are individuals who work on the DNS protocol and on DNS > operations, as participants in the Internet Engineering Task Force. > We have read the documents carefully. > > Prior to the posting of the Q&A, we had several concerns about what > might be entailed for the DNS by the Plan. The Q&A, however, makes > clear that the Plan is exclusively focussed on administrative > arrangements, and has no implications for the DNS protocol. We > therefore understant that under the plan, whatever delegations are > made from the root zone are simply different DNS delegations with no > interdependencies. We understand that synchronization is to be > understood entirely in terms of user expectation, and that users' > expectations could be more or less satisifed in any number of ways, > including by using completely different servers to address the needs > of different communities. > > In light of that, we have two suggestions. > > First, it would be helpful in the present case, and in similar future > cases, if ICANN did not use the terms "resolve" and "address" when the > ordinary meaning of those terms is not what is intended. Both the > Plan and the Q&A web page use the expression "to resolve to the same > address or value". In the Internet context, "resolve" almost always > entails an entanglement with the DNS. Similarly, in the Internet > context, "address" almost always means an IPv4 or IPv6 address. For a > name to resolve to an address, therefore, means that there be an entry > in the DNS such that a lookup of the name results in a response > containing the target IPv4 or IPv6 address. Since the Q&A web page is > clear that there is no such requirement, given that the different > delegations are completely distinct in the DNS, ICANN should use other > terms to make its point or risk continuing confusion. It is not clear > to us what it means for something to resolve to "a value". We are > aware that there are many DNS resource records that do not contain > addresses (NAPTR records, for instance), and that this is perhaps what > is intended. If that is the case, it should be avoided, because the > Plan as clarified does not require any real "sameness" in the DNS > anyway. > > Second, question and answer 9 in the Q&A should be updated. The > answer there says, "DNS responses must produce equivalent > results. . ." We would prefer that language be removed or somehow > altered, because despite the disclaimers immediately following it, it > could be misinterpreted as a constraint on what may be part of any of > the zone data in question. The test of synchronization is that users > should not be surprised, and not that there be any congruence of > answers in the DNS. Most users have no direct experience of the DNS, > and there need be no requirement of any kind on DNS responses. The > example should be modified to include the case where delegations under > S1 and S2 have similar names, but where the addresses at those names > are different. As long as the results the user experienced were what > the user expected, (e.g. because the different servers each served > localized but otherwise-equivalent content), that would be consistent > with ICANN's stated condition for synchronization. It should also be > made clearer that the target systems are not only web systems, but any > systems; so MX records and such should also be part of the examples. > > Thank you for this opportunity to contribute to the completion of > ICANN's Fast Track process. > > Sincerely, > > [signatories] > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="response-20100413a.txt" Thank you for posting, and for the opportunity to comment on, the "Proposed Implementation Plan for Synchronized IDN ccTLDs" (henceforth, the Plan). Thank you also for the clarifications you posted in the form of a set of Questions and Answers on 8 April, 2010. We are individuals who work on the DNS protocol and on DNS operations, as participants in the Internet Engineering Task Force. We have read the documents carefully. Prior to the posting of the Q&A, we had several concerns about what might be entailed for the DNS by the Plan. The Q&A, however, makes clear that the Plan is exclusively focussed on administrative arrangements, and has no implications for the DNS protocol. We therefore understant that under the plan, whatever delegations are made from the root zone are simply different DNS delegations with no interdependencies. We understand that synchronization is to be understood entirely in terms of user expectation, and that users' expectations could be more or less satisifed in any number of ways, including by using completely different servers to address the needs of different communities. It is very difficult to make a general rule about what users might expect, particularly at delegations below the second level in the DNS name space, and we understand the clarified Plan to say that no such general rule is contemplated. In light of that, we have two suggestions. First, it would be helpful in the present case, and in similar future cases, if ICANN did not use the terms "resolve" and "address" when the ordinary meaning of those terms is not what is intended. Both the Plan and the Q&A web page use the expression "to resolve to the same address or value". In the Internet context, "resolve" almost always entails an entanglement with the DNS. Similarly, in the Internet context, "address" almost always means an IPv4 or IPv6 address. For a name to resolve to an address, therefore, means that there be an entry in the DNS such that a lookup of the name results in a response containing the target IPv4 or IPv6 address. Since the Q&A web page is clear that there is no such requirement, given that the different delegations are completely distinct in the DNS, ICANN should use other terms to make its point or risk continuing confusion. It is not clear to us what it means for something to resolve to "a value". We are aware that there are many DNS resource records that do not contain addresses (NAPTR records, for instance), and that this is perhaps what is intended. If that is the case, it should be avoided, because the Plan as clarified does not require any real "sameness" in the DNS anyway. Second, question and answer 9 in the Q&A should be updated. The answer there says, "DNS responses must produce equivalent results. . ." We would prefer that language be removed or somehow altered, because despite the disclaimers immediately following it, it could be misinterpreted as a constraint on what may be part of any of the zone data in question. The test of synchronization is that users should not be surprised, and not that there be any congruence of answers in the DNS. Most users have no direct experience of the DNS, and there need be no requirement of any kind on DNS responses. The example should be modified to include the case where delegations under S1 and S2 have similar names, but where the addresses at those names are different. As long as the results the user experienced were what the user expected, (e.g. because the different servers each served localized but otherwise-equivalent content), that would be consistent with ICANN's stated condition for synchronization. It should also be made clearer that the target systems are not only web systems, but any systems; so MX records and such should also be part of the examples. Thank you for this opportunity to contribute to the completion of ICANN's Fast Track process. Sincerely, [signatories] --GvXjxJ+pjyke8COw-- From ajs@shinkuro.com Tue Apr 13 10:41:01 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C1028C126 for ; Tue, 13 Apr 2010 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_50=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB5Re+aKhKtY for ; Tue, 13 Apr 2010 10:41:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9B23E28C123 for ; Tue, 13 Apr 2010 10:41:00 -0700 (PDT) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1BDE21ECB533; Tue, 13 Apr 2010 17:40:53 +0000 (UTC) Date: Tue, 13 Apr 2010 13:40:51 -0400 From: Andrew Sullivan To: ajs@shinkuro.com, dns-dir@ietf.org Message-ID: <20100413174050.GD14332@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] Final text to be sent to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:41:02 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, I've bcc:d people, because I hate sending others' email addresses around, but I think everyone here could probably figure out how to mail one another if need be. You are receiving this either because you have said to me that you want your name included on the bottom of the message to be sent to ICANN about the synchronized domain plan, or else because you've been involved in the discussion and your intentions about including your name were not clear to me. (The only people who fall into the latter category are members of the dns-dir list.) I attach the latest version of the response to ICANN. It includes as subscribers everyone who has told me at one point or the other to include their name. I believe that each of you has seen a draft very close to this final version, but I want to make sure I haven't made any change that any of you is unable to support. If you are still happy with the enclosed version, please let me know. I will remove the name of anyone who has not responded positively to me by tomorrow, 2010-04-14, at 22:00 UTC (18:00 Eastern Daylight time). If your name is _not_ on here, and you want it to be, you need to tell me that also by tomorrow at 22:00 UTC. I want to make sure these comments are available prior to the ICANN Webinar on 15 April. I have spelled your names as they appear in From: lines in email from you, so if you use localized characters that way it should show up here. If your name does not appear as you'd prefer, and you want me to correct it, please let me know. Unless someone spots an egregious error, I'd like not to fiddle too much with this text any more. So unless you think it's really super important that something be changed, I'd like it if we left things alone. Thanks to each of you for your help in composing this reply to ICANN. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="response-20100413b.txt" Content-Transfer-Encoding: 8bit Thank you for posting, and for the opportunity to comment on, the "Proposed Implementation Plan for Synchronized IDN ccTLDs" (henceforth, the Plan). Thank you also for the clarifications you posted in the form of a set of Questions and Answers on 8 April, 2010. We are individuals who work on the DNS protocol and on DNS operations, as participants in the Internet Engineering Task Force. We have read the documents carefully. Prior to the posting of the Q&A, we had several concerns about what might be entailed for the DNS by the Plan. The Q&A, however, makes clear that the Plan is exclusively focused on administrative arrangements, and has no implications for the DNS protocol. We therefore understand that under the plan, whatever delegations are made from the root zone are simply different DNS delegations with no interdependencies. We understand that synchronization is to be understood entirely in terms of user expectation, and that users' expectations could be more or less satisfied in any number of ways, including by using completely different servers to address the needs of different communities. It is very difficult to make a general rule about what users might expect, particularly at delegations below the second level in the DNS name space, and we understand the clarified Plan to say that no such general rule is contemplated. In light of that, we have two suggestions. First, it would be helpful in the present case, and in similar future cases, if ICANN did not use the terms "resolve" and "address" when the ordinary meaning of those terms is not what is intended. Both the Plan and the Q&A web page use the expression "to resolve to the same address or value". In the Internet context, "resolve" almost always entails an entanglement with the DNS. Similarly, in the Internet context, "address" almost always means an IPv4 or IPv6 address. For a name to resolve to an address, therefore, means that there be an entry in the DNS such that a lookup of the name results in a response containing the target IPv4 or IPv6 address. Since the Q&A web page is clear that there is no such requirement, given that the different delegations are completely distinct in the DNS, ICANN should use other terms to make its point or risk continuing confusion. It is not clear to us what it means for something to resolve to "a value". We are aware that there are many DNS resource records that do not contain addresses (NAPTR records, for instance), and that this is perhaps what is intended. If that is the case, it should be avoided, because the Plan as clarified does not require any real "sameness" in the DNS anyway. Second, question and answer 9 in the Q&A should be updated. The answer there says, "DNS responses must produce equivalent results. . ." We would prefer that language be removed or somehow altered, because despite the disclaimers immediately following it, it could be misinterpreted as a constraint on what may be part of any of the zone data in question. The test of synchronization is that users should not be surprised, and not that there be any congruence of answers in the DNS. Most users have no direct experience of the DNS, and there need be no requirement of any kind on DNS responses. The example should be modified to include the case where delegations under S1 and S2 have similar names, but where the addresses at those names are different. As long as the results the user experienced were what the user expected, (e.g. because the different servers each served localized but otherwise-equivalent content), that would be consistent with ICANN's stated condition for synchronization. It should also be made clearer that the target systems are not only web systems, but any systems; so MX records and such should also be part of the examples. Thank you for this opportunity to contribute to the completion of ICANN's Fast Track process. Sincerely, [THESE SIGNATORIES IN DRAFT] Eric Brunner-Williams Ólafur Guðmundsson Patrik Fältström Paul Hoffman John R. Levine Jim Reid Andrew Sullivan Ondřej Surý Paul Vixie Yoshiro Yoneya --VbJkn9YxBvnuCH5J-- From ogud@ogud.com Tue Apr 13 11:40:10 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1BB28C0D6 for ; Tue, 13 Apr 2010 11:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1HLFwY7nRRA for ; Tue, 13 Apr 2010 11:40:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6E8A13A68C8 for ; Tue, 13 Apr 2010 11:40:07 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3DIe0j3046935 for ; Tue, 13 Apr 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 13 Apr 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100413_184001_073835.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-dempsky-edns0-options-for-private-use-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:40:11 -0000 Count: 11 Network Working Group M. Dempsky Internet-Draft OpenDNS, Inc. Intended status: Standards Track April 12, 2010 Expires: October 14, 2010 EDNS0 Options for Private Use draft-dempsky-edns0-options-for-private-use-00 Abstract This document reserves a range of EDNS0 Option values for private use. From narten@us.ibm.com Wed Apr 14 06:59:44 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C0C3A6935 for ; Wed, 14 Apr 2010 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY2M-ot1pwGJ for ; Wed, 14 Apr 2010 06:59:40 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id B4AB13A683C for ; Wed, 14 Apr 2010 06:59:40 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3EDlMSB017241 for ; Wed, 14 Apr 2010 09:47:22 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3EDxObY507962 for ; Wed, 14 Apr 2010 09:59:24 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3EDxOh0016325 for ; Wed, 14 Apr 2010 10:59:24 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-236-70.mts.ibm.com [9.65.236.70]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3EDxKTq015839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 10:59:21 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o3EDxJ7H030841; Wed, 14 Apr 2010 09:59:20 -0400 Message-Id: <201004141359.o3EDxJ7H030841@cichlid.raleigh.ibm.com> To: Andrew Sullivan In-reply-to: <20100413174050.GD14332@shinkuro.com> References: <20100413174050.GD14332@shinkuro.com> Comments: In-reply-to Andrew Sullivan message dated "Tue, 13 Apr 2010 13:40:51 -0400." Date: Wed, 14 Apr 2010 09:59:19 -0400 From: Thomas Narten Cc: dns-dir@ietf.org Subject: Re: [dns-dir] Final text to be sent to ICANN X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 13:59:44 -0000 I would encourage folk to sign this, even if they don't have strong feelings. Look at this as a "me too" on an IETF mailing list where you agree with someone's issues raised during LC or discussion. The way one formally participates in ICANN is via the public comment process. In the IETF, you just send email. But the purpose is the same, and there is no need to view the formality as being a "higher bar" than what we do in the IETF. And if no one comments, or only the wrong (as in clue challenged) folk comment, ICANN finds itself in the awkward position of not being able to do the right thing because they can't point to the issue being raised during the public comment process. Thomas From dromasca@avaya.com Wed Apr 14 09:35:03 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9D528C14D; Wed, 14 Apr 2010 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1ShAhsezkq2; Wed, 14 Apr 2010 09:35:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9B9013A6359; Wed, 14 Apr 2010 09:35:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="184331873" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:34:53 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451634603" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:34:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:34:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Congestion Exposure (conex) Thread-Index: AcrbMzjH2Bym9zI3StCzu4RjvoXr4AAvQNhg From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: WG Review: Congestion Exposure (conex) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:35:03 -0000 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 13, 2010 9:00 PM To: new-work@ietf.org Subject: WG Review: Congestion Exposure (conex)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. =20 Congestion Exposure (conex) -------------------------------------------------- Current Status: Proposed Working Group Last Updated: 2010-04-08 Chair(s): TBD Transport Area Director(s): Lars Eggert David Harrington Transport Area Advisor: Lars Eggert =20 Mailing Lists: TBD Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements, The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the IP layer, such that the total level of congestion is visible to all IP devices along the path. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Experiments on such use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. Milestones Mar 2011 Submit abstract specification for the congestion exposure mechanism to IESG as Informational Mar 2011 Submit use case description to IESG as Informational Sep 2011 Submit specification of IPv6 packet structure to IESG as Experimental Sep 2011 Submit specification for modification to TCP to IESG as Experimental From dromasca@avaya.com Wed Apr 14 09:35:05 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9458428C2AF; Wed, 14 Apr 2010 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4fdhByLHj-y; Wed, 14 Apr 2010 09:35:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 123B228C0F7; Wed, 14 Apr 2010 09:35:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="184331876" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:34:54 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451634611" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:34:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:34:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: DECoupled Application Data Enroute (decade) Thread-Index: AcrbMzcOb4BDgPh5TTe1JTFo53PqnAAvSi5w From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: WG Review: DECoupled Application Data Enroute (decade) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:35:05 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 13, 2010 9:00 PM To: new-work@ietf.org Subject: WG Review: DECoupled Application Data Enroute (decade)=20 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. =20 =20 DECoupled Application Data Enroute (decade) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-03-26 Chair(s): TBD Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre Applications Area Advisor: * Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the networks. Allowing P2P applications to store and retrieve data from inside networks can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open, standard protocol to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development (and hence, rechartering) is deemed necessary, it is not expected that all work items will be ready for IESG review by that point. However, WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Implementation of policies regarding copyright-protected or illegal content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational From ogud@ogud.com Thu Apr 15 11:40:08 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426CA3A67FF for ; Thu, 15 Apr 2010 11:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJCSq4acqOmU for ; Thu, 15 Apr 2010 11:40:07 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4D4373A68C5 for ; Thu, 15 Apr 2010 11:40:07 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FIe0nn067593 for ; Thu, 15 Apr 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 15 Apr 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100415_184000_000314.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-sury-dnsext-cname-dname-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 18:40:08 -0000 Count: 13 DNSext Working Group O. Sury Internet-Draft CZ.NIC Updates: 1034 (if approved) April 15, 2010 Intended status: Standards Track Expires: October 17, 2010 CNAME+DNAME Name Redirection draft-sury-dnsext-cname-dname-00 Abstract This document proposes a modification to CNAME record to coexist with DNAME record, which provides redirection for a sub-tree of the domain name tree in the DNS system. By allowing this cooexistence, DNS system will have a way how to create a sub-tree redirection together with record owner. This would allow parent zones to create full domain aliases. From dromasca@avaya.com Fri Apr 16 10:35:05 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D033A6A1B; Fri, 16 Apr 2010 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVwfTMoJDg+9; Fri, 16 Apr 2010 10:35:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E32B43A68BD; Fri, 16 Apr 2010 10:35:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,221,1270440000"; d="scan'208";a="213895217" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Apr 2010 13:34:56 -0400 X-IronPort-AV: E=Sophos;i="4.52,221,1270440000"; d="scan'208";a="452411448" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Apr 2010 13:34:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Apr 2010 19:34:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the April 22, 2010 IESG Teleconference Thread-Index: AcrdBOldcW5WAaHqSyq+2dTpvHILSgAhXrrw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the April 22, 2010 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 17:35:05 -0000 Please find below the preliminary agenda of the 4/22 IESG telechat. Please send me you questions, comments and concerns about the documents and the WG charters on the agenda before 4/21 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-sipping-config-framework-17 A Framework for Session Initiation Protocol User Agent Profile Delivery (Proposed Standard) Token: Robert Sparks o draft-ietf-mmusic-rfc4756bis-07 Forward Error Correction Grouping Semantics in Session Description Protocol (Proposed Standard) Note: Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com) Token: Robert Sparks o draft-ietf-sipcore-info-events-07 Session Initiation Protocol (SIP) INFO Method and Package Framework (Proposed Standard) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Robert Sparks o draft-ietf-netmod-yang-12 YANG - A data modeling language for NETCONF (Proposed Standard) Note: David Partain (david.partain@ericsson.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-netmod-yang-types-08 Common YANG Data Types (Proposed Standard) Note: David Partain (david.partain@ericsson.com) is the document shepherd. Token: Dan Romascanu o draft-freed-sieve-notary-07 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions (Proposed Standard) Note: This is a Sieve WG document, despite the name. Cyrus Daboo is the document shepherd. Token: Alexey Melnikov o draft-ietf-pce-pcep-p2mp-extensions-09 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (Proposed Standard) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-avt-register-srtp-01 Policy for Registering SRTP Transforms (Proposed Standard) Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-opsawg-smi-datatypes-in-xsd-06 Expressing SNMP SMI Datatypes in XML Schema Definition Language (Proposed Standard) Note: Scott Bradner (sob@harvard.edu) is the document shepherd. Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Items o draft-nottingham-http-link-header-09 Web Linking (Proposed Standard) Note: Julian Reschke is the document shepherd Token: Alexey Melnikov o draft-ogud-iana-protocol-maintenance-words-03 Definitions for expressing standards requirements in IANA registries. (BCP) Token: Russ Housley o draft-denenberg-mods-etc-media-types-01 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, application/sru+xml (Proposed Standard) Note: I am aware that the document doesn't pass some formatting nits, but I am thinking that in this case RFC Editor can fix that. An alternative would be to find another co-editor, but I think this would be overkill. Token: Alexey Melnikov o draft-reschke-rfc2231-in-http-11 Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields (Proposed Standard) Note: Graham Klyne is the document shepherd Token: Alexey Melnikov o draft-turner-asymmetrickeyformat-05 Asymmetric Key Packages (Proposed Standard) Note: Carl Wallace (cwallace@cygnacom.com) is the Document Shepherd Token: Tim Polk o draft-turner-asymmetrickeyformat-algs-01 Algorithms for Asymmetric Key Package Content Type (Proposed Standard) Note: Carl Wallace (cwallace@cygnacom.com) is the document Shepherd Token: Tim Polk o draft-haberman-rpsl-reachable-test-03 A Dedicated RPSL Interface Identifier for Operational Testing (Proposed Standard) Token: Ron Bonica 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-nsis-nslp-natfw-24 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) (Experimental) Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi). Token: Lars Eggert o draft-ietf-nsis-rmd-19 RMD-QOSM - The Resource Management in Diffserv QOS Model (Experimental) Note: Jukka Manner (jukka.manner@tkk.fi) is the document shepherd. Token: Lars Eggert o draft-ietf-nsis-ext-07 Using and Extending the NSIS Protocol Family (Informational) Note: Document Shepherd: Martin Stiemerling (martin.stiemerling@neclab.eu) Token: Lars Eggert o draft-ietf-radext-status-server-06 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (Informational) Note: Bernard Aboba (bernard_aboba@hotmail.com) is the document shepherd. Token: Dan Romascanu 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-wallace-using-ta-constraints-02 Using Trust Anchor Constraints During Certification Path Processing (Informational) Token: Tim Polk o draft-mattsson-mikey-ticket-03 MIKEY-TICKET: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) (Informational) Token: Tim Polk 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items o draft-simpson-tcpct-01 TCP Cookie Transactions (TCPCT) (Experimental) Token: Lars Eggert 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Decoupled Application Data Enroute (decade) Token: Alexey o Congestion Exposure (conex) Token: Lars 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE From ogud@ogud.com Fri Apr 16 11:40:11 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F5C3A695C for ; Fri, 16 Apr 2010 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZWyNB5G6txe for ; Fri, 16 Apr 2010 11:40:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E7C343A6A05 for ; Fri, 16 Apr 2010 11:40:08 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3GIe0OA078011 for ; Fri, 16 Apr 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 16 Apr 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100416_184001_043174.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-v6ops-isp-scenarios-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 18:40:11 -0000 Count: 15 V6OPS B. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational S. Jiang Expires: October 17, 2010 Huawei Technologies Co., Ltd April 15, 2010 Emerging Service Provider Scenarios for IPv6 Deployment draft-ietf-v6ops-isp-scenarios-00 Abstract This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. The document identifies a number of technology gaps, but does not make recommendations. From dromasca@avaya.com Wed Apr 28 04:19:00 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AEF3A6B9A; Wed, 28 Apr 2010 04:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxdYs5u8t9wo; Wed, 28 Apr 2010 04:18:57 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1F3FA3A6907; Wed, 28 Apr 2010 04:18:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="215548976" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Apr 2010 07:18:14 -0400 X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="468483649" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Apr 2010 07:18:14 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2010 13:17:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: SIP Overload Control (soc) Thread-Index: AcrmL1PVeKox1SUqTKy0ZLuvh715sQAlPYuA From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: WG Review: SIP Overload Control (soc) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 11:19:00 -0000 Please let me know if you have any questions or concerns related to the formation of this WG.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 27, 2010 8:30 PM To: new-work@ietf.org Subject: WG Review: SIP Overload Control (soc)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 4, 2010. =20 SIP Overload Control (soc) --------------------------- Current Status: Proposed Working Group Last Modified: 2010-04-22 Chair(s) TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sip-overload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload=20 Archive: http://www.ietf.org/mail-archive/web/sip-overload/ Description of Working Group: As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, input/ output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the goodput (effective application throughput not counting the overhead of retransmission and redundant data) of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers.=20 Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their source or destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. The working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on=20 implicit/explicit feedback to IESG for publication as Proposed=20 Standard May 2011 Specification for a SIP load filtering mechaism to IESG for=20 publication as Proposed Standard From ogud@ogud.com Wed Apr 28 11:40:15 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BA53A6C17 for ; Wed, 28 Apr 2010 11:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg5ipvc4saZT for ; Wed, 28 Apr 2010 11:40:14 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3FC133A6B64 for ; Wed, 28 Apr 2010 11:40:14 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3SIe1C8094491 for ; Wed, 28 Apr 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 28 Apr 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100428_184001_022749.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-haddad-mext-nat64-mobility-harmful-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 18:40:15 -0000 Count: 10 Mobility Extensions for IPv6 W. Haddad (mext) Ericsson Internet-Draft C. Perkins Intended status: Informational WiChorus Inc. Expires: October 30, 2010 April 28, 2010 A Note on NAT64 Interaction with Mobile IPv6 draft-haddad-mext-nat64-mobility-harmful-01 Abstract This memo discusses potential NAT64 technology repercussions for mobile nodes using Mobile IPv6. An ambiguity is identified related to the use of DNS during bootstrapping, which is likely to inhibit proper signaling between mobile node and home agent.