[DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Thu, 07 February 2019 16:48 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513121292F1 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 08:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Level:
X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hPxaB3Mge6ZG for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 08:48:17 -0800 (PST)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DEA4124BF6 for <dnsop@ietf.org>; Thu, 7 Feb 2019 08:48:15 -0800 (PST)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Thu, 7 Feb 2019 17:48:09 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0435.000; Thu, 7 Feb 2019 17:47:41 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: draft-ietf-dnsop-attrleaf vs. RFC7553
Thread-Index: AdS/A6lXkR/vK91JS+aKsAvRVHamBg==
Date: Thu, 07 Feb 2019 16:47:41 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE0759FBCD40B@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.110]
Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE0759FBCD40BNICSEXCH2sbgnic_"
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8c5ySTUcuhbIOx5DNZUNwAm5MN8>
Subject: [DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 16:48:19 -0000

Hello everyone,

I'm turning my head around an issue around the attrleaf draft, and its connection with RFC7553 (the URI RRType). Im specifically wondering what the connection between the "service parameter" in RFC 7553 and the "Global Underscore Node Names" in draft-ietf-dnsop-attrleaf is.  I'm trying to reword draft-mayrhofer-dns-did to request a new underscore node name. My issues is as follows:

RFC 7553 restricts the  "service parameters" (those underscored names) as follows:


   Valid service

   parameters are those registered by IANA in the "Service Name and

   Transport Protocol Port Number Registry" [RFC6335<https://tools.ietf.org/html/rfc6335>] or as "Enumservice

   Registrations [RFC6117<https://tools.ietf.org/html/rfc6117>]

However, I understand the intent of draft-ietf-attrleaf (as far as I understand) is to replace/extend that definition by a new registry, and does indeed include underscore node names for the URI RRType in Section 4.3. However, I'm wondering whether that formally "overrides" the previous specification.. So, my questions are:


A)      Would it be enough to request a global underscore node name to use it with the URI RRType

B)      And shouldn't draft-ietf-dnsop-attrleaf hence UPDATE RFC7553?

(I know the draft is already *very* well advanced in the process, so I'm opening a can of worms here - but better late than never? And there are definitely more future use cases for URI records that might be well covered by the attrleaf document..)

Comments appreciated!

Best,
Alex