Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

James Galvin <galvin@elistx.com> Fri, 02 October 2020 20:15 UTC

Return-Path: <galvin@elistx.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE83A16D4 for <regext@ietfa.amsl.com>; Fri, 2 Oct 2020 13:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=elistx-com.20150623.gappssmtp.com
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 EMJFFeAZEtan for <regext@ietfa.amsl.com>; Fri, 2 Oct 2020 13:15:17 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCBC3A1775 for <regext@ietf.org>; Fri, 2 Oct 2020 13:15:08 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id a4so2835136qth.0 for <regext@ietf.org>; Fri, 02 Oct 2020 13:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=Jv4o4Orn7unSdK8tOVBc9gY2zFpjXjIA+WQiTKReDD4=; b=X7RYaWc+RCb9AtDe3hXZjwx92YnMuMQty/+/1ylTPKxIw+viFH/8d2K5uwhBXy0ZY2 r4anPEwr27AA6y3nHQOjmQwu9kDSnDVoUghb0Zg29j54ht2NrSDG0DAhP5RnVBNtQwz9 +wxgpQt3wK6WERb47pDouqEvVB/iSsufHd2oL3A4euEfRGsxAtnakxmuPmeiHWSeq06S z/j7/gABEua3gz5DOownAwxYa3uNjAMkmMavFvuyfCYaelLqiboDLRq5tmHTiKqUF3KN EOjkLvXsmq8elyEQxHIqkzYwjMbb5/QZLJOdDJ7y4VE/zQWsLJRFnrr0Fiw8qksMF34N yMEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Jv4o4Orn7unSdK8tOVBc9gY2zFpjXjIA+WQiTKReDD4=; b=WnLk1ZILlus5DAWQkWcr+N8/Oh0FJI7ZczTOVCXOL2n3VEsnFiptg/9GmT5UyDyuDS ASIl3aEEeBmbH/E/CAyJaY21FayQste0AnBqkHHFfyJuw1lZ5AhG8qI3/5+p9UVUfFHp QhBKBCwubMqhsVeNBFCuSnLZkGoZWtY4k1tyqguaW0Zm/Qy2wRk3RqNRBETrnfiMkdqI 7cAQ4dmyyylD2Zfelzo++0jX6DC9juuxvBoUH5BtZSMuIW+heE6ewKUV+uGPLM3YVxbl tsnmFnKLHFqcG2O9MdUhVqfIstzusPWRVnv+8fdu+TgeBmSIBk+Gy3kKRmQIZquw/v2v cYvw==
X-Gm-Message-State: AOAM533LP02qT6Vo9n15aNztWh9xpJLOn1Y2MFHXWBryF48IhAAEdXzz KT7vcWwhIaD3i3K+nVtu6QYLZqzPy5tG4nBm4gw=
X-Google-Smtp-Source: ABdhPJwAfrPwi59Hn08mOIlGz0VAwVfAslg6gcdwETPHWO2LGMad86oIpU+yfSLqoYXK35Y8Ga4dBA==
X-Received: by 2002:ac8:1a7b:: with SMTP id q56mr4107146qtk.56.1601669706960; Fri, 02 Oct 2020 13:15:06 -0700 (PDT)
Received: from [10.0.0.100] ([2601:154:c202:9d20:591:5600:a9ec:a8fa]) by smtp.googlemail.com with ESMTPSA id z9sm1836651qta.95.2020.10.02.13.15.05 for <regext@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 13:15:05 -0700 (PDT)
From: James Galvin <galvin@elistx.com>
To: regext@ietf.org
Date: Fri, 02 Oct 2020 16:15:19 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <4A5F8A5D-32E6-4666-898F-23B83C5CDB18@elistx.com>
In-Reply-To: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl>
References: <D394EB73-FAA1-42E2-899B-8E188A78411F@antoin.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/o9N_jciAbzqKxICV47D2rUt84qg>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 20:15:20 -0000

The WGLC for this document was scheduled to end today.  While there is 
support to move the document forward there is one minor comment that has 
been raised during the last call.

The chairs would like to hear from other working group members as to 
what to do with this comment.  Rather than close the last call and risk 
another last call, we are extending this last call for another week.  If 
we can come to a consensus as to how to proceed before the end of last 
call than the document can stay on track to be submitted to the IESG 
after the last call.

The WG last call will end at close of business on Friday, 9 October 
2020.


Here are the comments as seen on the mailing list.  Please respond with 
your suggestions regarding these two comments.


James Gould:

Yes, lumping the registrar object with the contact object under a single 
RDAP entity object interface is the rub.  We solved the problem in the 
RDAP Profile, by supporting entity lookup by IANA ID (number) and 
registrar name (string) for the registrar objects, and by ROID 
(“((\w|_){1,80}-\w{1,8}") for the contact objects.  Where there is 
overlap, which is registrar name (string) and ROID 
((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My 
recommendation is to provide guidance in the section 3.1.5 "Entity Path 
Segment Specification" for this real world case:

The <handle> parameter represents an entity (such as a contact,
registrant, or registrar) identifier whose syntax is specific to the
registration provider.  For example, for some DNRs, contact
identifiers are specified in [RFC5730] and [RFC5733], and
registrar identifiers are specified using the IANA Registrar ID
assigned by ICANN.  The server SHOULD define a scheme
for the <handle> parameter to differentiate between the
supported entity object types (e.g., contact and registrar),
such as using different <handle> formats, using a <handle>
precedence order, or a combination of formats and precedence
order.

The SHOULD could be a MUST, but the point is to provide guidance to 
implementers of the protocol.

Two responses have been offered:

Jasdip Singh response:

One thought is if it could be in the RDAP profile doc for the DNRs 
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en). 
That way no need to update the spec.

James Gould response:

The RDAP Profile is dependent on the RFC, so I wouldn't create a 
circular dependency.  My recommendation is to take the lessons learned 
in implementing the RFC and provide guidance on how to handle it in the 
RFC directly.



Thanks!

Antoin and Jim





On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:

> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/
>
> This WG last call will end at close of business, Friday, 2 October 
> 2020.
>
> Please review this document and indicate your support (a simple 
> “+1” is sufficient) or concerns with the publication of this 
> document by replying to this message on the list.
>
> The document shepherd for this document is Mario Loffredo.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext