From brian.e.carpenter@gmail.com Fri Jan 3 11:34:11 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223C71ADFC2 for ; Fri, 3 Jan 2014 11:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSz43MXtrvH7 for ; Fri, 3 Jan 2014 11:34:09 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D199F1AC4A5 for ; Fri, 3 Jan 2014 11:34:05 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so16010832pbb.18 for ; Fri, 03 Jan 2014 11:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jhV/c9pYwVAGA1DyZ2EGgk0DoL24GknK4PINjO/w+mc=; b=N8Fm3cEf23vAnSLLiET1tbsFYBIK7yZNA5HZXPDu4atg5kF+HY+gdDcGiulLNMmBIb 7DU3tFLKOuFU5bPxf45T8DEDRgOgFiptOqkewsJPKLcUoYYSvi141g6s0sXtbpgEhnBv sfhYKxkVo8QNS+KjuXJlGdP0iV0Z/ZyR1vhVnC8eLcc22Rf8SpaAWNjSTevOpKwPKKia 2KnjYtD4uJgoLgmjsmCe2U8eF2rmnOao1CpFKErUa1C9Q0bvjpqiXDpNkNkIicV68k7m 5zhwDQGBw8qD7VNle51aoXFq1ZR6BRLK9RdRBwiO4ZYAEru9p7Py0PlBfcAx1FuAxKvf Ks/Q== X-Received: by 10.66.142.107 with SMTP id rv11mr97783498pab.17.1388777638576; Fri, 03 Jan 2014 11:33:58 -0800 (PST) Received: from [192.168.178.21] (1.197.69.111.dynamic.snap.net.nz. [111.69.197.1]) by mx.google.com with ESMTPSA id ic7sm110663440pbc.29.2014.01.03.11.33.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 11:33:57 -0800 (PST) Message-ID: <52C710AF.3030701@gmail.com> Date: Sat, 04 Jan 2014 08:34:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: InternetGovtech@iab.org References: <20140103165943.10614.65695.idtracker@ietfa.amsl.com> In-Reply-To: <20140103165943.10614.65695.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-iab-iana-framework@tools.ietf.org Subject: Re: [Internetgovtech] I-D Action: draft-iab-iana-framework-00.txt X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:34:11 -0000 Hi, Some general comments: 1. As in all documents in this space, I think it's vital to lock in early the fact that IANA operates under IAB/IETF instructions. So after the sentence in 1.2: "Currently the maintenance, implementation and publication of most of the IETF protocol Registries is performed by the Internet Corporation for Assigned Names and Numbers (ICANN)." I think it's important to add "according to the Memorandum of Understanding [RFC2860]" (And similarly in section 4.2.) 2. Related to that, I believe the references to "ICANN" in Section 2.1 Example 2 and Example 3 should be changed to IANA. ICANN just happens to hold the IANA token at the moment. 3. Section 2.2.1 Example 3 should contain a reminder of the same thing, for example "Generic TLD delegation policy is *today* developed bottom-up through ICANN policy processes." And so on... "ICANN, as the *current* IANA functions operator, ..." Regards Brian From paf@frobbit.se Fri Jan 3 12:17:37 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1A1ADFAA for ; Fri, 3 Jan 2014 12:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyryud8nAv7x for ; Fri, 3 Jan 2014 12:17:36 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE21ADD02 for ; Fri, 3 Jan 2014 12:17:36 -0800 (PST) Received: from [192.168.1.10] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 2E77220239; Fri, 3 Jan 2014 21:17:28 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C60C4935-1289-4656-9F4D-31B7C1B9F814"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Fri, 3 Jan 2014 21:17:25 +0100 Message-Id: References: To: Kolkman Olaf , Jari Arkko X-Mailer: Apple Mail (2.1827) Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 20:17:38 -0000 --Apple-Mail=_C60C4935-1289-4656-9F4D-31B7C1B9F814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 3 jan 2014, at 18:36, IETF Chair wrote: > In this article I wanted to highlight an important but often hidden = part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA). = What is IANA, how does it work, how is it related to the IETF, and how = has it evolved over time? How will it evolve in the future, and how can = you participate in the discussion? >=20 > http://www.ietf.org/blog/2014/01/iana/ Comments after first read of this very good text that is coming at the = right time. In no specific order: 1. IANA itself divide its work in three parts, and because of that I = think Olaf's draft is more correct than Jari's text that I think sort of = only talk about two? Maybe I misunderstand. Anyway... 2. Regarding IANA evaluation: > In some cases, the evaluation of requests is a > straightforward task requiring little subjective evaluation, whereas > in other cases evaluation is more complex and requires subject matter > experts as defined by the relevant policy guidance. I normally explain this a bit differently. IANA at this time evaluates a = request and comes back with one of three(!) different responses: - YES, approved - NO, not approved - [to IETF] Rules not clear enough I.e. I think it should be clear that IANA is to (unless things really = have changed from when I was more involved) a. Inspect the IANA Considerations Section as part of the publication = process of an RFC b. Signal to whatever policy development process that developed the = rules for a certain parameter that although IANA said "ok" (see a. = above), the rules where not clear enough and should be updated 3. Policy development I think the division of the process in various pieces in Olafs draft is = good. But I think it should be even more specific on the fact that the = _policy_ process that results in a request to IANA to do something might = be in various places, and that is not limited to IETF and ICANN and = RIRs. I do for example not know where policy process is for the timezone = database, or maybe IETF is the one that have set the policy for IANA, = and that is to "listen to changes decided by [some third body]"? = Honestly I do not know. ICANN have the policy development of the IDN language tables, and I = think I remember W3C had one parameter, but maybe I am wrong. Hmm... I must re-read and see whether I really feel a clarification is needed, = and if so, what it is 4. ENUM ENUM is interesting example...because IANA is not really involved at = all. Or rather, IANA manages ARPA, and is asked by IAB to delegate = e164.arpa to RIPE NCC which in turn is implementing the policy decided = by ITU-T policy. 5. Key principles of the IANA framework This, section 3, is very good. Can not be emphasised enough. 6. Agreement between DoC and ICANN People will ask what the relationship is between IETF-ICANN agreements = on for example IANA performance and improvements and the USGov-ICANN = agreement . = See specifically C.2.9 (including sub bullets -- not the .INT TLD...) = and C.4 about measurements. Specifically, when these documents talks about IAB oversight, what is = that oversight relationship with the Contracting Officer=92s = Representative (COR) oversight according to the contract with US Gov? Patrik --Apple-Mail=_C60C4935-1289-4656-9F4D-31B7C1B9F814 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSxxrVrMabGguI180RAvVtAJ9AC++ddbu+O/TL59dtTdUv0epmnACglQmp 9As6+/U+J6gupAuK6m3AIbk= =WTuP -----END PGP SIGNATURE----- --Apple-Mail=_C60C4935-1289-4656-9F4D-31B7C1B9F814-- From sm@resistor.net Fri Jan 3 13:12:44 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F151ADFB9 for ; Fri, 3 Jan 2014 13:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayHNgcw5Eh8j for ; Fri, 3 Jan 2014 13:12:43 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC561ADFB1 for ; Fri, 3 Jan 2014 13:12:43 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s03LCKRV001623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 13:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1388783548; bh=AcTcqIPIJ2veLD3m7wpwSUagiSXR70RcYApOyCBThTU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aH8TZT3BBgHvqaEzllwogsVYaf4xLROhwC24iaLKFdZ4jsXL8NPUsFguie1x9tugn NiQ7YNGu2Mn4oxXMxU3yXriS0ByuX/KXVUVKjEeufMIZaOj0Nb0uzYvUfauF8p2ag6 ox8Pt3EVItAKKEt9Byj1YIMhITd/w+MIstEzw+0o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1388783548; i=@resistor.net; bh=AcTcqIPIJ2veLD3m7wpwSUagiSXR70RcYApOyCBThTU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lCa/8SmbM6usqDS+GdMST5Ehi2Ic51PIPqEUH58nuBFwFNsIlSUqfL8k0MQXcrfTU 0sxM3ZPMl2BvUSCSjSZ7iEazjutmY7jKnAk+R/y1y3oq4szpLgzxj6muM14X8cQ3ii 7FPxECrv3Jeg9WlLUxYnnJOcPk8NQ4d5c4/P1/Ac= Message-Id: <6.2.5.6.2.20140103123954.0d6fe410@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Jan 2014 12:50:23 -0800 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: SM In-Reply-To: References:

Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Kolkman Olaf , internetgovtech@iab.org, Jari Arkko Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 21:12:44 -0000 Hi Patrik, At 12:17 03-01-2014, Patrik F=E4ltstr=F6m wrote: >IETF and ICANN and RIRs. I do for example not=20 >know where policy process is for the timezone=20 >database, or maybe IETF is the one that have set=20 >the policy for IANA, and that is to "listen to=20 >changes decided by [some third body]"? Honestly I do not know. It is my understanding that neither the IETF nor=20 IANA sets policy for the timezone database. The=20 maintenance of the timezone database is discussed in RFC 6557. Regards, -sm=20 From paf@frobbit.se Fri Jan 3 13:21:54 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2C1ADFBD for ; Fri, 3 Jan 2014 13:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLhDR08JlueT for ; Fri, 3 Jan 2014 13:21:54 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id C68981ADFB8 for ; Fri, 3 Jan 2014 13:21:53 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::5984:3598:5ce5:82f8] (unknown [IPv6:2a02:80:3ffc:0:5984:3598:5ce5:82f8]) by mail.frobbit.se (Postfix) with ESMTPSA id A91D2203E5; Fri, 3 Jan 2014 22:21:45 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_421D7346-2F59-4E61-8AE0-FE43EAAD5DD8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <6.2.5.6.2.20140103123954.0d6fe410@resistor.net> Date: Fri, 3 Jan 2014 22:21:10 +0100 Message-Id: <5B5870BD-36B2-4F7D-9D04-70A37ACBA830@frobbit.se> References:

<6.2.5.6.2.20140103123954.0d6fe410@resistor.net> To: SM X-Mailer: Apple Mail (2.1827) Cc: Kolkman Olaf , internetgovtech@iab.org, Jari Arkko Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 21:21:55 -0000 --Apple-Mail=_421D7346-2F59-4E61-8AE0-FE43EAAD5DD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 3 jan 2014, at 21:50, SM wrote: > Hi Patrik, > At 12:17 03-01-2014, Patrik F=E4ltstr=F6m wrote: >> IETF and ICANN and RIRs. I do for example not know where policy = process is for the timezone database, or maybe IETF is the one that have = set the policy for IANA, and that is to "listen to changes decided by = [some third body]"? Honestly I do not know. >=20 > It is my understanding that neither the IETF nor IANA sets policy for = the timezone database. The maintenance of the timezone database is = discussed in RFC 6557. Ok, good. Thanks for the information. Then instructions IANA has related to this parameter still comes from = IETF. That is the important piece I think. Patrik --Apple-Mail=_421D7346-2F59-4E61-8AE0-FE43EAAD5DD8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSxynGrMabGguI180RAuBJAKCZ9v7+1bKpYI9c+x+vK19Hhwn8AgCfSAYC CM/feCGoBAAnitZap1KaRxE= =mla/ -----END PGP SIGNATURE----- --Apple-Mail=_421D7346-2F59-4E61-8AE0-FE43EAAD5DD8-- From drc@virtualized.org Fri Jan 3 18:11:37 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735AA1AE02A for ; Fri, 3 Jan 2014 18:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5IFDm9ydaaf for ; Fri, 3 Jan 2014 18:11:33 -0800 (PST) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B01AE01B for ; Fri, 3 Jan 2014 18:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id ABED484CEE; Fri, 3 Jan 2014 21:11:25 -0500 (EST) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 43865-04; Fri, 3 Jan 2014 21:11:25 -0500 (EST) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id EC30A84B43; Fri, 3 Jan 2014 21:11:23 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_CC91DACF-29E3-40BB-9AF2-6C9BC507F063"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: David Conrad In-Reply-To: Date: Fri, 3 Jan 2014 18:11:19 -0800 Message-Id: <31904788-A83A-4C4E-8125-676D59D77893@virtualized.org> References:

To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1827) Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 02:11:37 -0000 --Apple-Mail=_CC91DACF-29E3-40BB-9AF2-6C9BC507F063 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Patrik, On Jan 3, 2014, at 12:17 PM, Patrik F=E4ltstr=F6m = wrote: > In no specific order: >=20 > 1. IANA itself divide its work in three parts, and because of that I = think Olaf's draft is more correct than Jari's text that I think sort of = only talk about two? Maybe I misunderstand. Jari does briefly mention the two other major functions (names and = Internet numbers), however there is (or at least was) a bit more than = just {protocol parameters,names,Internet numbers}: there's also = management of .ARPA and .INT and other similar odds and ends. > 2. Regarding IANA evaluation: >=20 >> In some cases, the evaluation of requests is a >> straightforward task requiring little subjective evaluation, whereas >> in other cases evaluation is more complex and requires subject matter >> experts as defined by the relevant policy guidance. >=20 > I normally explain this a bit differently. IANA at this time evaluates = a request and comes back with one of three(!) different responses: >=20 > - YES, approved >=20 > - NO, not approved >=20 > - [to IETF] Rules not clear enough Not just to the IETF. In theory, at least, IANA staff can push back on = the ASO for clarification on global address policies and on ICANN in the = context of root zone management (e.g., glue policy). However, far more common than "Rules not clear enough" would be: - [to requester] Need more information. > I.e. I think it should be clear that IANA is to (unless things really = have changed from when I was more involved) >=20 > a. Inspect the IANA Considerations Section as part of the publication = process of an RFC >=20 > b. Signal to whatever policy development process that developed the = rules for a certain parameter that although IANA said "ok" (see a. = above), the rules where not clear enough and should be updated There might be a mixing of roles here. To use Olaf's = terminology/distinctions, I believe (a) is (or should be) part of the = policy development role and (b) is part of the implementation role. = That is, I think IANA staff should be in the loop in policy development, = reviewing the IANA consideration section during the development of the = policy so they can ensure that policy can be implemented. It may be = interesting that by the terms of the current IANA functions contract = between ICANN and the USG (specifically, section C.2.5), it can be = argued that IANA staff are explicitly disallowed from participation in = policy development -- I suspect it comes down to the interpretation of = "initiate, advance, or advocate" and "respond to requests for = information". > 3. Policy development >=20 > I think the division of the process in various pieces in Olafs draft = is good. But I think it should be even more specific on the fact that = the _policy_ process that results in a request to IANA to do something = might be in various places, and that is not limited to IETF and ICANN = and RIRs. Perhaps a more exhaustive mapping of resource to policy definition body: protocol parameters: IETF top-level domains: ICANN, IETF (see RFC 6761), governments (in the case = of ccTLDs) top-level Internet number blocks: IETF (see RFC 7020), the RIR policy = definition bodies, legacy address holders(?) .ARPA: IAB, IETF (sub-zones, e.g., in-addr.arpa, can involve other = players, depending on the sub-zone) .INT: ICANN(?) -- this one has always been a bit odd. > 4. ENUM >=20 > ENUM is interesting example...because IANA is not really involved at = all. Or rather, IANA manages ARPA, and is asked by IAB to delegate = e164.arpa to RIPE NCC which in turn is implementing the policy decided = by ITU-T policy. Out of curiosity, how is the ITU-T policy enforced in the case of = e164.arpa? Is there a contract between the ITU Secretariat and = RIPE-NCC? > 5. Key principles of the IANA framework >=20 > This, section 3, is very good. Can not be emphasised enough. I actually think this should be expanded. Each of the terms used in that = section probably need to be defined/explained. E.g., what do "stable" = and "predictable" mean in the context of an IANA framework? =20 > 6. Agreement between DoC and ICANN >=20 > People will ask what the relationship is between IETF-ICANN agreements = on for example IANA performance and improvements and the USGov-ICANN = agreement . = See specifically C.2.9 (including sub bullets -- not the .INT TLD...) = and C.4 about measurements. >=20 > Specifically, when these documents talks about IAB oversight, what is = that oversight relationship with the Contracting Officer=92s = Representative (COR) oversight according to the contract with US Gov? "*That*, Detective, is the right question." -- Dr. Alfred Lanning = (deceased), "I, Robot" (the movie) =20 :) Regards, -drc --Apple-Mail=_CC91DACF-29E3-40BB-9AF2-6C9BC507F063 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSx23HAAoJENV6ebf0/4rXXEQH/iHCrkMXMHOIH9BxKXeLAKpk Yt/bdmsxUCXQDa7FdgdigkTMbRqJrkFroswdB7aW687E5218k73czcU7j0Gr8qwI EOo8XOOPpxjxGQTUTvB0vlkNxWGGEPp12Pw8biDHa+yca45s8NaxY+gKma9lDDlS 7ZS8guGxYqwfeT2/VEd20jkbAitBNDBQGQFSLJdWjZO/JgB6be6fCvSi0lB2kPC1 8dfjSP71Q8F6jnHdvQpP8iKQtUDENy5tTPW4tytkPvUeg90mBnVNNJiNw/C5p7rh 7jbYOx+5HRwg3J8s1E3aGPZPDetO84WIne8tJgVfh9FPXNn4p5USWmrTFYk4Ftw= =jwfF -----END PGP SIGNATURE----- --Apple-Mail=_CC91DACF-29E3-40BB-9AF2-6C9BC507F063-- From paf@frobbit.se Fri Jan 3 23:44:54 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CCD1AD669 for ; Fri, 3 Jan 2014 23:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXBwY4FhKUsi for ; Fri, 3 Jan 2014 23:44:51 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id E420A1AC829 for ; Fri, 3 Jan 2014 23:44:50 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::5984:3598:5ce5:82f8] (unknown [IPv6:2a02:80:3ffc:0:5984:3598:5ce5:82f8]) by mail.frobbit.se (Postfix) with ESMTPSA id 62621201DD; Sat, 4 Jan 2014 08:44:42 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1C00F7F1-D681-4350-99D2-FE98A44D6EB5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <31904788-A83A-4C4E-8125-676D59D77893@virtualized.org> Date: Sat, 4 Jan 2014 08:44:40 +0100 Message-Id: References:

<31904788-A83A-4C4E-8125-676D59D77893@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1827) Cc: internetgovtech@iab.org Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 07:44:54 -0000 --Apple-Mail=_1C00F7F1-D681-4350-99D2-FE98A44D6EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 4 jan 2014, at 03:11, David Conrad wrote: > On Jan 3, 2014, at 12:17 PM, Patrik F=E4ltstr=F6m = wrote: >> 2. Regarding IANA evaluation: >>=20 >>> In some cases, the evaluation of requests is a >>> straightforward task requiring little subjective evaluation, whereas >>> in other cases evaluation is more complex and requires subject = matter >>> experts as defined by the relevant policy guidance. >>=20 >> I normally explain this a bit differently. IANA at this time = evaluates a request and comes back with one of three(!) different = responses: >>=20 >> - YES, approved >>=20 >> - NO, not approved >>=20 >> - [to IETF] Rules not clear enough >=20 > Not just to the IETF. In theory, at least, IANA staff can push back on = the ASO for clarification on global address policies and on ICANN in the = context of root zone management (e.g., glue policy). Correct. > However, far more common than "Rules not clear enough" would be: >=20 > - [to requester] Need more information. +1 >> I.e. I think it should be clear that IANA is to (unless things really = have changed from when I was more involved) >>=20 >> a. Inspect the IANA Considerations Section as part of the publication = process of an RFC >>=20 >=20 >> b. Signal to whatever policy development process that developed the = rules for a certain parameter that although IANA said "ok" (see a. = above), the rules where not clear enough and should be updated >=20 > There might be a mixing of roles here. To use Olaf's = terminology/distinctions, I believe (a) is (or should be) part of the = policy development role and (b) is part of the implementation role. = That is, I think IANA staff should be in the loop in policy development, = reviewing the IANA consideration section during the development of the = policy so they can ensure that policy can be implemented. Specifically, *IF* IANA is part of the PDP (which I believe IANA still = is for at least the IETF PDP) then that should be mentioned. > It may be interesting that by the terms of the current IANA functions = contract between ICANN and the USG (specifically, section C.2.5), it can = be argued that IANA staff are explicitly disallowed from participation = in policy development -- I suspect it comes down to the interpretation = of "initiate, advance, or advocate" and "respond to requests for = information". Correct. I do though think IETF have had the line drawn correctly for some time. = The IANA involvement is strictly to inspect the IANA considerations = section. But your point about C.2.5 (and other) is a good one regarding staff of = IANA involvement in for example IETF or other PDP that result in = instructions to IANA. >> 3. Policy development >>=20 >> I think the division of the process in various pieces in Olafs draft = is good. But I think it should be even more specific on the fact that = the _policy_ process that results in a request to IANA to do something = might be in various places, and that is not limited to IETF and ICANN = and RIRs. >=20 > Perhaps a more exhaustive mapping of resource to policy definition = body: >=20 > protocol parameters: IETF > top-level domains: ICANN, IETF (see RFC 6761), governments (in the = case of ccTLDs) I am very sensitive to words like "governments"...I think we normally = talk about "territory" that the ccTLD is linked to. Is a "government" = the governing body over a territory, or do "government" imply a = "country"? But I agree with the category. You also have COR approval as specified in the contact with US = Government, but that can be tied under "governments" possibly? > top-level Internet number blocks: IETF (see RFC 7020), the RIR policy = definition bodies, legacy address holders(?) > .ARPA: IAB, IETF (sub-zones, e.g., in-addr.arpa, can involve other = players, depending on the sub-zone) ...depending on the sub-zone according to instructions from IAB... > .INT: ICANN(?) -- this one has always been a bit odd. Um...yes... >> 4. ENUM >>=20 >> ENUM is interesting example...because IANA is not really involved at = all. Or rather, IANA manages ARPA, and is asked by IAB to delegate = e164.arpa to RIPE NCC which in turn is implementing the policy decided = by ITU-T policy. >=20 > Out of curiosity, how is the ITU-T policy enforced in the case of = e164.arpa? Is there a contract between the ITU Secretariat and = RIPE-NCC? It is a bit complicated...but that is how it ends up being... - There are the basic RFCs that specify ENUM - There are instructions from IAB to RIPE-NCC (synchronized with ITU-T) - There are ITU-T resolutions - There is an exchange of letters between ITU-T and RIPE-NCC And probably more exchanges of documents... I think you see this best by looking at the ITU version of the setup: But this is an example where IAB made the decision to have a different = entity managing "the parameter" while "just" asking IANA to delegate the = e164.arpa domain (as manager of .ARPA) to whatever RIPE-NCC requests it = to be. Detail: All of this work was done (by me and a few others) together with = Houlin Zhao, which I do believe will be the new head of ITU. >> 5. Key principles of the IANA framework >>=20 >> This, section 3, is very good. Can not be emphasised enough. >=20 > I actually think this should be expanded. Each of the terms used in = that section probably need to be defined/explained. E.g., what do = "stable" and "predictable" mean in the context of an IANA framework? Yes please. We have for example that discussion with Unicode Consortium = (for correct reasons) all the time, just because we have different view = of what "stable" means (when discussing versioning). >> 6. Agreement between DoC and ICANN >>=20 >> People will ask what the relationship is between IETF-ICANN = agreements on for example IANA performance and improvements and the = USGov-ICANN agreement = . See = specifically C.2.9 (including sub bullets -- not the .INT TLD...) and = C.4 about measurements. >>=20 >> Specifically, when these documents talks about IAB oversight, what is = that oversight relationship with the Contracting Officer=92s = Representative (COR) oversight according to the contract with US Gov? >=20 > "*That*, Detective, is the right question." -- Dr. Alfred Lanning = (deceased), "I, Robot" (the movie) =20 >=20 > :) ;-) Patrik --Apple-Mail=_1C00F7F1-D681-4350-99D2-FE98A44D6EB5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSx7vorMabGguI180RAt2eAJ9CtmiLAJYL1rMeseSZtiOkY4z8ywCfTG4F DMgDq7ywtfX6DZdwZmlWa7o= =2QUh -----END PGP SIGNATURE----- --Apple-Mail=_1C00F7F1-D681-4350-99D2-FE98A44D6EB5-- From jefsey@jefsey.com Sun Jan 26 19:41:40 2014 Return-Path: X-Original-To: internetgovtech@ietfa.amsl.com Delivered-To: internetgovtech@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231401A0185 for ; Sun, 26 Jan 2014 19:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrCJ8CB8AM7P for ; Sun, 26 Jan 2014 19:41:38 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id C9C001A00E1 for ; Sun, 26 Jan 2014 19:41:38 -0800 (PST) Received: from 120.20.176.95.rev.sfr.net ([95.176.20.120]:63628 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1W7d4p-00008G-Mh for internetgovtech@iab.org; Sun, 26 Jan 2014 19:41:36 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jan 2014 04:41:33 +0100 To: internetgovtech@iab.org From: Jefsey In-Reply-To: References:

<31904788-A83A-4C4E-8125-676D59D77893@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Internetgovtech] IANA blog article X-BeenThere: internetgovtech@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Internet Governance and IETF technical work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 03:41:40 -0000 I wish to raise two points of interest (IMHO) in the coming Sao Paulo meeting's perspective: 1. http://en.wikipedia.org/wiki/Sandra_Braman I discover (may she is well known by most of you?) this searcher. Her "Internet RFCs as social policy: Network design from a regulatory perspective" is a few years old study but it will probably be a kind of topics that /1NET people will discuss. Moreover if there is not a layer protection by a technical governance. 2. There are convergent indications that GS1 could target its own tables in the IANA to support the ONS (the version 2.0.1 of the standard was ratified one year ago). After the Unicode convergence (langtags, IDNA2008) this could lead ICANN to become a Tables Keeper for the whole Internet. This would add to the opposition of many as putting more control in American hands. I would therefore suggest that the IETF maintains its own content of IANA tables in a format that would help differentiating file hosting/copyright/control and the data/number/name/parameters themselves. There is the Dublin Core. Intlnet started working on the Versailles Core to describe languages. I would suggest that the IETF considers an IETF Uniform Core List and an open data delivery and update service for its parameters descriptions and values. So everyone could use the parameters directly when embeding them in applications, etc. Without a single point of control. Best jfc