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

James Galvin <galvin@elistx.com> Fri, 02 October 2020 20:06 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 C86EF3A16D1 for <regext@ietfa.amsl.com>; Fri, 2 Oct 2020 13:06:18 -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 dkAtuPf082FZ for <regext@ietfa.amsl.com>; Fri, 2 Oct 2020 13:06:16 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 618183A16CF for <regext@ietf.org>; Fri, 2 Oct 2020 13:06:16 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id b13so1706417qvl.2 for <regext@ietf.org>; Fri, 02 Oct 2020 13:06:16 -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=wUO8M+HOV9plw7GWIq8Q4bBwLllvRtQ2sOV2ol5qavw=; b=do9CfGGzHTNHyn8jESQ/DDcFtjiKPahOLweF55fHm+jB3KAhp/x9ySiVEqUgnDx11E xgNRHDvN+NcA028jK0lN0ou5kXXKl2nWym/FjPMwSIjhi7/+xHCczDHo/2k6kZKdhNni vDYw92FGmY7lY3M929EJIisPQQbATG9u8glilXGsBh8VUbrpGzDbmzC1Qmck1Xs0jPb5 O2XwkONt6j+10uCTL5P3jZZ5x6GH4ltLFXF4Zh6OqYWiEbN1KKoM15QDNIjdxbp+gY42 9WXeUHAsfPw691tx5Ri2b68Vcqz4lhOE4FmMvIjXyyFrMHZtkZjaerO2UfjRgIo8ww/x +JMA==
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=wUO8M+HOV9plw7GWIq8Q4bBwLllvRtQ2sOV2ol5qavw=; b=LIwohVgrCxn++5GwRxpGH/BHezI7Ti4l8Tfv9T3uP/DaIy3SFodNyaw48jzZUNgSmF Nt1Liohmi9lHnwJU0kGQGjFXqAj4O3b180rg5W2Vp3XuTSdqMqqwZEEa8k85iCR1IRMr YVnGmX+qzi4hrTyh2Kqc+jwgqhQaze/rbOUwz7scEzUex9MTWY/eA4u1vMIR0TH5PYy7 z7YuACicxeIh/n0NvYqUQs7wS0KuyPyY+qKXddgddQ92cIo6nL41c2QBkbUKu0lpFwM1 MoJJUezRczZX1DCGjlnn8aXvvVb2zoks/VEXyB55boDU2YVcKQslWvuQywUe/6NToa0X m+rQ==
X-Gm-Message-State: AOAM5331YOyhIxDS/b7lQ4+VAAmHEt/HosDhVpd0FS0BiIKQeBtUkt/6 Ee+mACYhVjdGBd2EN+rr2Zn4NCtmc/vx3mXqrZo=
X-Google-Smtp-Source: ABdhPJyjXJ89bYxPKtElyPHxsfVv2TN0nh5sJuaYg078jBRXu0LYI107C4Io3bkdWJbkZVwYPpKFAg==
X-Received: by 2002:ad4:408f:: with SMTP id l15mr3797682qvp.4.1601669174975; Fri, 02 Oct 2020 13:06:14 -0700 (PDT)
Received: from [10.0.0.100] ([2601:154:c202:9d20:591:5600:a9ec:a8fa]) by smtp.googlemail.com with ESMTPSA id l13sm1924673qtv.82.2020.10.02.13.06.13 for <regext@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 13:06:13 -0700 (PDT)
From: James Galvin <galvin@elistx.com>
To: regext@ietf.org
Date: Fri, 02 Oct 2020 16:06:27 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <064F7704-0619-4CD1-A17C-A59EC82A7596@elistx.com>
In-Reply-To: <F5EC2287-ADD1-49E9-B5F2-25E73C64DA10@antoin.nl>
References: <F5EC2287-ADD1-49E9-B5F2-25E73C64DA10@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/KESYOjNABInduX3sL1LQYhR31xs>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
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:06:19 -0000

The WGLC for this document was scheduled to end today.  While there is 
support to move the document forward there are two minor comments that 
have been raised during the last call.

The chairs would like to hear from other working group members as to 
what to do with these comments.  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:

I have one item to bring up with draft-ietf-regext-rfc7483bis, which is 
associated with Section 5.1 “The Entity Object Class”.   The jCard 
"version" and "fn" members are required according to RFC 6350, which 
poses an issue if a contact name does not exist or needs to be redacted. 
  To address this case, I recommend adding a sentence to the end of 
section 3 "Common Data Types":

Contact information is defined using jCards as described in [RFC7095].  
The “version” and “fn” members are required according to 
[RFC6350], where an empty “fn” member MAY be used when the contact 
name does not exist or is redacted.

Two response have been offered:

Scott Hollenbeck:

I'd like to see some discussion of this suggestion. If one understands 
the normative references, the suggestion is already implicitly 
addressed. There may be some value in describing this situation 
explicitly since it came up in the ICANN gTLD implementation context, 
but so others think this clarification is necessary?

Jasdip Singh:

Seems if the RDAP profile for the DNRs 
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en) 
could clarify this, the spec could be left as-is.



Mario Loffredo:

The document does not contain any requirement or recommendation about 
when returning ldhName and unicodeName values. However, the examples 
seem to convey the idea that ldhName must  always be returned and 
unicodeName must be returned in case of an IDN.

No responses yet.



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-rfc7483bis/
>
> 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 Jasdip Singh.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext