Re: [dnsext] Request for new RRTYPE assignment: "ASSET"

Kevin Darcy <kcd@chrysler.com> Sat, 13 September 2008 00:14 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327CC3A67DB; Fri, 12 Sep 2008 17:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.663
X-Spam-Level:
X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 O2gzG9btDDqG; Fri, 12 Sep 2008 17:14:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6E7B3A67A1; Fri, 12 Sep 2008 17:14:36 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KeIh2-0007dU-St for namedroppers-data@psg.com; Sat, 13 Sep 2008 00:08:52 +0000
Received: from [129.9.168.37] (helo=shbmap02.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <kcd@chrysler.com>) id 1KeIgy-0007d5-Mr for namedroppers@ops.ietf.org; Sat, 13 Sep 2008 00:08:50 +0000
X-AuditID: 8109a824-aaa24bb000000bb5-fe-48cb0481b523
Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shbmap02.extra.chrysler.com (Symantec Mail Security) with SMTP id A9A2A4E4002 for <namedroppers@ops.ietf.org>; Fri, 12 Sep 2008 20:08:33 -0400 (EDT)
Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by shnavip4-hme0.shdc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008091220083304990 for <namedroppers@ops.ietf.org>; Fri, 12 Sep 2008 20:08:33 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m8D08Xsv011606 for <namedroppers@ops.ietf.org>; Fri, 12 Sep 2008 20:08:33 -0400 (EDT)
Message-ID: <48CB0481.3090800@chrysler.com>
Date: Fri, 12 Sep 2008 20:08:33 -0400
From: Kevin Darcy <kcd@chrysler.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Request for new RRTYPE assignment: "ASSET"
References: <20080911152052.GH1008@commandprompt.com>
In-Reply-To: <20080911152052.GH1008@commandprompt.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

I have nothing to offer in response to this request, from purely a DNS 
technical perspective, but as a matter of semantics, the word "asset" 
already has an established meaning in the English language, with 
different jargonistic colorings in the Legal, Accounting and 
Intelligence fields, and the use of "ASSET" as a mnemonic, for something 
wholly unrelated to any of those meanings, might be confusing.

Granted, we already have NULL, CERT, SINK, OPT and HIP, but in all those 
cases the record type is either a) experimental, b) obsolete (if not 
formally), or c) accurately and unambiguously describe their contents. I 
don't think "asset" falls into any of those categories.

Would an alternative mnemonic be considered?

ASLIST?

ASGROUP?

ASNUMS?

- Kevin

Andrew Sullivan wrote:
> Dear colleagues,
>
> I sent this message below on 28 August, but I just attempted to find
> it in the archives and did not.  I'm not entirely sure what happened
> to it.  I'm posting it again now.  Because I can't find it in the
> archives, I hereby extend the closing date of this request until three
> weeks today, 2008-10-02 at 17:00-04.  My apologies to the RRTYPE
> requester and the experts for this delay.
>
> ---original message follows---
>
> IANA has a request for a new RRTYPE.  They've asked us to attempt to
> follow the rules of 2929bis, since it is apparently about to be
> adopted by the IETF (and is held up for non-technical reasons, I am
> led to believe).
>
> Under the rules of draft-ietf-dnsext-2929bis-07, a completed template
> for the request must be posted to the relevant mailing list for at
> least three weeks prior to Expert Review decisision.  (For the purposes
> of this request, we are using this mailing list; we expect the
> mailing list to remain the same in the future, but it is possible that
> IANA will change the mailing list.  We'll know once 2929bis is
> published in its final form.)
>
> In the meantime, the IESG has appointed a panel of experts.  Roy
> Arends (roy@nominet.org.uk) and Frederico Neves (fneves@registro.br)
> are the two panelists, and I will serve as panel chair.
>
> If you have any comments on the request, please post them to the list,
> or send them directly to Roy, Frederico, and me.   This call for
> comments will close three weeks from today, on 2008-09-18 17:00-04.
>
> Andrew (for the panel)
>
> ===begin template===
>
>    A.    Submission Date:
>
>    2008-04-24
>
>    B.    Submission Type:
>          [x] New RRTYPE
>          [ ] Modification to existing RRTYPE
>
>    C.    Contact Information for submitter:
>                Name:  Lutz Donnerhacke
>                Email Address: lutz@iks-jena.de
>                International telephone number: +49-3641-460850
>                Other contact handles: LD26
>          (Note: This information will be publicly posted)
>
>
>    D.    Motivation for the new RRTYPE application?
>          Please keep this part at a high level to inform the Expert and
>          reviewers about uses of the RRTYPE. Remember most reviewers
>          will be DNS experts that may have limited knowledge of your
>          application space.
>
>              We have an Internet Draft describing an infrastructure
>              for verifying routes received via BGP4.  The
>              infrastructure uses DNS.
>
>              An RRTYPE is needed to represent AS numbers in a compact
>              format.  These resource records can be merged to share
>              other AS sets and to describe very large AS sets as a
>              union of smaller records of the proposed new type.
>
>              Current implementations of this strategy using existing
>              RRTYPEs have exceeded the protocol limits of DNS.
>
>    E.    Description of the proposed RR type.
>          This description can be provided in-line in the template, as an
>          attachment or with a publicly available URL:
>
>              The proposed resource record is described in
>              draft-donnerhacke-sidr-bgp-verification-dnssec-04,
>              section 2.1 and following.
>
>    F.    What existing RRTYPE or RRTYPEs come closest to filling that
>          need and why are they unsatisfactory?
>          
>              The TXT type comes closest, but attempts to use it have
>              exceeded the protocol limits of DNS, with response sizes
>              exceeding 100kB.  Experimental numbers are not acceptable
>              for the current use case, because the testbed software
>              needs to be deployed in embedded software.
>
>    G.    What mnemonic is requested for the new RRTYPE (optional)?
>          Note: this can be left blank and the mnemonic decided after the
>          template is accepted.
>
>              ASSET
>
>    H.    Does the requested RRTYPE make use of any existing IANA
>          Registry or require the creation of a new IANA Sub-registry and
>          in DNS Parameters?
>          If so, please indicate which registry is to be used or created.
>          If a new sub-registry is needed, specify the allocation policy
>          for it and initial contents. Also include what the modification
>          procedures will be.
>
>              Yes.  In addition to updating the RRTYPE code registry,
>              it requires the creation of an IANA sub-registry for
>              subtype numbers.  The initial subtype numbers are
>              allocated by
>              draft-donnerhacke-sidr-bgp-verification-dnssec-04,
>              section 2.1.1.  It defines the following subtypes:
>
>              0
>               Union of the referenced ASSET RRs and embedded number
>               ranges
>              
>              1
>               Set of all possible AS numbers
>
>              2
>               Transition marker
>
>              3-15
>               Reserved
>
>              Modification is to be by standards action.
>
>
>    I.    Does the proposal require/expect any changes in DNS
>          servers/resolvers that prevent the new type from being
>          processed as an unknown RRTYPE (see [RFC3597])?
>
>              No.
>
>    J.    Comments:
>
>              None
>
> ===end===
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>
>
>   


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>