[drinks] Framework: IANA registration policy, Extensibility text
Alexander Mayrhofer <alexander.mayrhofer@nic.at> Thu, 04 October 2012 11:13 UTC
Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id ED9B121F8567 for <drinks@ietfa.amsl.com>;
Thu, 4 Oct 2012 04:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.2
X-Spam-Level:
X-Spam-Status: No, score=-9.2 tagged_above=-999 required=5 tests=[AWL=0.229,
BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyHtJnZ+VZ1O for
<drinks@ietfa.amsl.com>; Thu, 4 Oct 2012 04:13:39 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by
ietfa.amsl.com (Postfix) with ESMTP id 9EF3021F8584 for <drinks@ietf.org>;
Thu, 4 Oct 2012 04:13:37 -0700 (PDT)
Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over
TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.48 ;
Thu, 4 Oct 2012 13:13:36 +0200
Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by
NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id
14.02.0247.003; Thu, 4 Oct 2012 13:13:34 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "drinks@ietf.org" <drinks@ietf.org>
Thread-Topic: Framework: IANA registration policy, Extensibility text
Thread-Index: Ac2iIMOf7VpGQwvTSRCAZwDeuVuWvg==
Date: Thu, 4 Oct 2012 11:13:34 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075096F5A0C@NICS-EXCH.sbg.nic.at>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.3.79]
Content-Type: multipart/alternative;
boundary="_000_19F54F2956911544A32543B8A9BDE075096F5A0CNICSEXCHsbgnica_"
MIME-Version: 1.0
X-XWALL-BCKS: auto
Subject: [drinks] Framework: IANA registration policy, Extensibility text
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>,
<mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>,
<mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2012 11:13:41 -0000
(per discussion on the design team call yesterday) Hi, During my review of the framework document i discovered two more issues that i didn't include in the report. - We are requesting IANA to create a registry for "Organization Identifiers" in section 11, however, we are not specifying a registration policy for that registry. This will definitely not pass the IANA review. A list of well known policies is contained in section 4.1 of RFC5226 - i suggest that we use either "RFC required" or "IETF review" - both are rather heavyweight allocation methods, but probably fit quite well to this registry, since we're not allocating namespace elements themselves, but rather namespace type identifiers. I think we can fix that by adding a single sentence, for example "OrgIdType namespace values are to be assigned via "RFC required" as defined in Section 4.1 of RFC5226". (Note - concensus in the design team call yesterday was that "RFC required" is the preferred allocation policy - respective text will be included in the next revision) - We have "ext" elements in many of our objects, but the actual use of those extensibility anchors is underspecified. All the descriptions of the "ext" elements refer to "described in a previous section of this document", where the only sentence i found related to this feature is "To encourage interoperability, the framework supports extensibility aspects." I think the sentence itself is already not problematic, because underspecified extensibility actually could decrease interopability among implementations (extensibility, though, increases the interopability with proprietory systems). I'm not sure how to address that one, but looking at the EPP RFCs' extensibility text might be a good idea. (Note: During yesterdays design team call, i volunteered to take up the action item of creating some text around this issue - i think i might manage to do this over the next few days) Alex
- [drinks] Framework: IANA registration policy, Ext… Alexander Mayrhofer