Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-07.txt

Joseph Yee <jyee@donuts.email> Fri, 24 June 2022 19:41 UTC

Return-Path: <jyee@donuts.email>
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 2ED85C15AAF7 for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 12:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=donuts.email
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_CfqSs4BVd6 for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 12:41:47 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8EBC15AD41 for <regext@ietf.org>; Fri, 24 Jun 2022 12:41:46 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id x3so6225618lfd.2 for <regext@ietf.org>; Fri, 24 Jun 2022 12:41:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=donuts.email; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qZ9m3A6PMhLKqUI7QftGOPY5igCfrsDq8WVjPIkQlm0=; b=F/6prqd2qDNwgUJXYap9s7GdIAZUqgN8pzxlXxflaZo0qgTCaNxue06LTa+qUUyHds qwtsghOcCHAg2V6fZA6LsI7NVgGTr1GT1Q/PlclHbQ9a/dqKXYXBqozFwEGtub1oQq/C RYJFlYXyP/6Yo0RiZw7jdF9IT3W8LtMbeyPT8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qZ9m3A6PMhLKqUI7QftGOPY5igCfrsDq8WVjPIkQlm0=; b=gcSL25B2eSx5WlZipIC12EepPUVbah1jtszGZvAz2yEuEslfgTTjrNILQiXJuFH5Bj urqEqtAk9oq8GO/7VhIe4uZfWQVUeXjwyw7QmgCYK1mtBQgW1WHQYWZeqQ/RkLuxeiEx pUDcQPzwZFzRAqCYeYfx7pPrzRfWFadDQTfLK/Qtjj2fqSQG5DlBbAlX47Ha+o7TPIjg 4F9cN8Kn/9TTe7dYYtWcC74KWb96/GW9Lj6daI0tonL0vnr5AfkRHIkd3WC/71WbNLFj KfLk1bILa3xpQ7UgM67nqaOUqWDKyCIY52ioNGpqogfNc5yLY52Mx2jUyQj11VHadq7+ EMbw==
X-Gm-Message-State: AJIora8fJu2zKI54tIhWCOXfJwOJ2dJ1KzoHcTv+txy2+FR6pWYaYDbW Vbi3hcb/uskbnDk7roIpfx2eoDWqfHEpGU2CBB0V5zJxtZMocQ==
X-Google-Smtp-Source: AGRyM1shBcp9BZ19pTO/CUCE7zN7J/Vn8Xr4xT2EsiXdlTrDyQKk4x1FW5dSVF14fr0wySmDFFy6fEPlR4s3zuiWu6s=
X-Received: by 2002:a05:6512:260c:b0:47f:74f1:13b9 with SMTP id bt12-20020a056512260c00b0047f74f113b9mr268819lfb.443.1656099704125; Fri, 24 Jun 2022 12:41:44 -0700 (PDT)
MIME-Version: 1.0
References: <165472331750.38962.7093902258341297395@ietfa.amsl.com> <BY5PR10MB417939331D373FD2E19023EFC9B39@BY5PR10MB4179.namprd10.prod.outlook.com>
In-Reply-To: <BY5PR10MB417939331D373FD2E19023EFC9B39@BY5PR10MB4179.namprd10.prod.outlook.com>
From: Joseph Yee <jyee@donuts.email>
Date: Fri, 24 Jun 2022 15:41:31 -0400
Message-ID: <CAN_HUyKbDJnxnSLSU5f6=gavOASbTQnLnapfuFAvsboHPC-8AQ@mail.gmail.com>
To: Rick Wilhelm <Rwilhelm@pir.org>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>
Cc: "regext@ietf.org" <regext@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093ddca05e236c272"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/L6pjK5YqosfjqABnIhH_Bbs0NMs>
Subject: Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-07.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Jun 2022 19:41:51 -0000

(resend with different mail from)

Rick, Jim,

Sorry to take long to respond. Thanks for the input and I will discuss with
Jim Galvin as my co-author about splitting the draft.  I will also review
and address the comments you provided.

I am occupied this week on work matters and I will be away next week.  I
will start as soon as I can from the week of July 4 on this draft.

Best,
Joseph

On Wed, Jun 22, 2022 at 6:06 PM Rick Wilhelm <Rwilhelm@pir.org> wrote:

> Joseph,
>
>
>
> Thanks for the ongoing updates to the draft.
>
>
>
> Some comments to the -07 draft below.
>
>
>
> Before getting into a more detailed, I want to express support for the
> high-level suggestions that Jim Gould made in a June 15 message.  Pasting
> them here:
>
>
>
>    1. Split the draft into two separate drafts, with the first being a
>    standards track draft that covers the framework elements (format, IANA
>    registries, and a base set of report elements), and the second being an
>    informational track draft that includes reports that use the framework.
>    The framework should be flexible enough to support the definition of many
>    report elements and many reports.
>    2. To support an extensible set of report element values, such as
>    transactions and objects, the Data Element Definition registry can be
>    expanded to support typed elements, with the initial set including (fields,
>    transactions, and objects).  This is like the RDAP JSON Values registry
>    that supports multiple types of values.  This way new types of transactions
>    and objects can be registered that are unique and are described.
>
>
>
> The first item is consistent with in-session comments that I’ve made at
> prior meetings, but I don’t think that I’ve sent it to the list before.  My
> detailed review of the doc has further convinced me that separating into
> two documents is a better idea than combining one.
>
>
>
>
>
> The second is something that has emerged upon further review.
>
>
>
>
>
> Now to detail
>
>
>
>
>
> Section 2:
>
>
>
> Regarding:
>
>
>
> Data element names in the
>
>    IANA registry MUST be unique and MUST be processed as case
>
>    insensitive.
>
>
>
> I’m certainly supportive of case-insensitive processing.  But as the Draft
> has data element names with a smattering of upper-case letters, I’m very
> concerned that we are dooming our predecessors to a frustrating set of
> defects when libraries fail to process these in a case-insensitive manner.
> I’ve been through any number of difficult debugging sessions involving JSON
> handling where things go awry.  Since we are using the underbar as a word
> separator, we don’t need the upper-case to denote word boundaries.  That
> is:  “date_time” is just as readable as “Date_Time”.
>
>
>
> Therefore:  I would like to suggest that the upper-case letters in all the
> data elements be lower-cased.  This would be covering 2.1 – 2.4.
>
>
>
>
>
>
>
> 2.1.4. Transaction_Type
>
> 2.1.5 Object_Type
>
>
>
> I found the specificity of these sections to be lacking.  Based on this
> language, incompatible implementations could emerge.  For example: the use
> of all lower case (“domain”), mixed case (“Domain”), all upper (“DOMAIN”).
> Or even abbreviations: “dom”, “con”, “hos”.  Same with the transaction
> types.
>
>
>
> This comment is also linked to the (pasted) second suggestion from Jim
> Gould’s comment.  If, for some reason, Gould’s suggestion of an extensible
> set of report element values is _*not*_ taken, then the lack of
> specificity should still be address via some other mechanism.
>
>
>
> 2.1.5 Object_Type
>
>
>
> The current text:
>
>
>
>         The object type involved in the report.
>
>
>
> Implies that a report can only involve a single object.  I don’t have any
> examples handy, but I don’t understand the restriction.  Maybe the latter
> part of the sentence can be improved?
>
>
>
> 2.3.1 Available_Date
>
> 2.3.2 Deleted_Date
>
> 2.3.3 Redemption_End_Date
>
> 2.3.4 Pending_Delete_Date
>
> 2.3.5 Updated_Date
>
> 2.3.6 Created_Date
>
> 2.3.7 Expiration_Date
>
>
>
> The date and time format follows the "type=dateTime" specification as
> defined in RFC 5731 [RFC5731].
>
>
>
> At the risk of stepping into Hollenbeck/Gould territory, the dateTime
> linkage to EPP is established in RFC 5730 and I _*think*_ that there it
> is part of base XML, not defined in the RFC.
>
>
>
> 2.4.
>
>
>
> Overall, in this section the descriptions of the element names would be
> clearer if there was more use of the indefinite article “a” (or “an”) and
> less use of the definite article “the”.  This is because the data elements
> apply broadly, rather than to a particular instance.  As an example,  the
> first sentence of the section:
>
>
>
> As is:  “The identifier assigned to the registrar.“
>
> Proposed: “The identifier assigned to a registrar.”
>
>
>
> In the edits, this will look like a series of nits, but it would be
> helpful to the reader
>
>
>
> 2.4.1. Registrar_ID
>
>
>
> The current text:
>
>
>
>    The identifier assigned to the registrar.  If the registrar is
>
>    accredited under ICANN, it MUST be the registrar's IANA ID
>
>    [IANA_Registrar_IDs].  Otherwise it is a value known between the
>
>    producer and the consumer, set via an out-of-band mechanism and
>
>    unique within all reports of the producer.
>
>
>
> Suggested:
>
>
>
>    The identifier assigned to a registrar.  If a registrar is
>
>    accredited under ICANN and the producer report involves an
> ICANN-accredited TLD, it MUST be the registrar's IANA ID
>
>    [IANA_Registrar_IDs].  Otherwise it is a value known between the
>
>    producer and the consumer, set via an out-of-band mechanism.
>
> .
>
> I think that the current text places too many restrictions of ccTLD
> operators, who may have ICANN-accredited registrars and non-ICANN
> accredited registrars.  A ccTLD does not have any requirement to use IANA
> IDs for those registrars that happen to be ICANN-accredited and this
> document would have any sway regarding uniqueness requirements on registrar
> identifiers for a producer.
>
>
>
>
>
> 2.4.3. DNSSEC
>
>
>
> Regarding:
>
>
>
>    The value MUST be either 'YES' or 'NO' to indicate whether the domain
>
>    is DNSSEC signed.
>
>
>
> In this context, the element seems like it might be better named
> HAS_DNSSSEC to indicate that it is a boolean concept.
>
>
>
> Separately (or perhaps related), I think that “true” and “false” would be
> better values than “YES” or “NO”, as these are used in JSON (
> https://datatracker.ietf.org/doc/html/rfc8259#section-3)
>
>
>
> 2.4.6.  Contact_Name
>
>
>
> Regarding:
>
>    The name of the contact object.  Usually it is the name of an
>
>    individual or an organization as described in RFC 5733 [RFC5733]
>
>    Section 2.3.
>
>
>
> While RFC 5733 Section 2.3 describes the representation of individual and
> organizational names associated with a contact, Section 3.2.1 has a clear
> distinction between the individual and the (optional) organization.  It is
> unclear how the current doc handles a situation where both would be
> communicated in the report.
>
>
>
> Also, this field is not actually the “name of the contact object”, it (per
> RFC 5733) “contains the name of the individual or role represented by the
> contact”
>
>
>
> 2.4.7. Linked
>
>
>
> See above comment related to YES/NO vs true/false for 2.4.3 DNSSEC
>
>
>
> 2.4.9. Host_IP
>
>
>
> Regarding:
>
>
>
>    The IP address of the host object.  The syntax of the IPv4 address
>
>    MUST conform to RFC 791 [RFC0791].  The syntax of the IPv6 address
>
>    MUST conform to RFC 4291 [RFC4291].  If it contains mutliple IP
>
>    addresses, each must be separated by symbol comma with the whole
>
>    string under double quotes as specified in RFC 4180 [RFC4180]
>
>
>
> Various issues with clarity.  Suggested text:
>
>
>
>    The IP address(es) of a host object.  The syntax of an IPv4 address
>
>    MUST conform to RFC 791 [RFC0791].  The syntax of an IPv6 address
>
>    MUST conform to RFC 4291 [RFC4291].  If the element contains multiple IP
>
>    addresses, each must be separated by a comma; with the
>
>    element enclosed with double quotes as specified in RFC 4180 [RFC4180]
>
>
>
>
>
> Section 3:
>
>
>
> I think that these comments are valid even if the doc gets split into two
> (as described above)
>
>
>
> Regarding:
>
>
>
>    A consumer MUST be able to receive data elements that are not
>
>    recognized and MAY skip them accordingly, both in the header row and
>
>    in the record rows.
>
>
>
> I think that the “MAY” here should be removed, because if the consumer
> does not “skip them accordingly”, then the consumer really is not really
> “able to receive data elements that are not recognized” (which is a MUST).
> Suggested edit is to remove the “MAY”, as in:
>
>
>
>    A consumer MUST be able to receive data elements that are not
>
>    recognized and skip them accordingly, both in the header row and
>
>    in the record rows.
>
>
>
>
>
> Regarding:
>
>
>
>    A report is specified in the report registry with two pieces of
>
>    information.  First is the name of the report.  This can be whatever
>
>    is appropriate as defined by the producer of the report.  The name of
>
>    the report MUST be unique and this characteristic MUST be enforced by
>
>    registry.
>
>
>
> It seems odd that there is so much work going into designing this and the
> naming convention for reports is being left entirely unspecified.  While I
> haven’t given it much thought of what it _*should*_ be, the idea that
> it’s a “free for all” seems odd.  I don’t think that we should be requiring
> everyone to have the same name for every report.  But by this spec, whoever
> is first to create “domain-report”, “contact-report”, etc and the name
> doesn’t indicate any source.
>
>
>
>
>
> Section 3.1-3.7:
>
>
>
> Pls note that I did not do a detailed review the structure/contents of the
> sample reports in 3.1-3.7, I think that they are interesting examples, but
> by no means definitive.  As described in the initial comments, I think that
> these should be in an informational document because they provide a point
> of view on what reports might look like, but it is just a point of view.
> From personal experience, these reports vary widely (wildly?) and can be
> impacted by all sorts of context.  Having these examples in a standards
> track document gives them inordinate weight.
>
>
>
>
>
> Nits:
>
>
>
> Section 1:
>
>
>
> Regarding:
>
>
>
> Among the distinctions that vary by
>
>    producer is the syntax of the data provided,
>
>
>
> Suggest to add: “report” to improve clarity; to be:
>
>
>
> Among the report distinctions that vary by
>
>    producer is the syntax of the data provided,
>
>
>
>
>
> Section 2:
>
>
>
> Regarding:
>
>
>
> The name of the data element MUST be unique and this characteristic
>
>    MUST be enforced by the registry.
>
>
>
> I _*think*_ that in this context “registry” refers to “IANA data element
> registry” (and not the report producer). Would be good to clarify regardless
>
>
>
>
>
> Regarding:
>
>
>
> The data elements adopt the same naming convention, where all the
>
>    leading character of each word use upper-case and the rest in lower-
>
>    case,
>
>
>
> Suggest to removed “all” and swap “the rest” for “the remaining
> characters” to improve clarity; to be:
>
>
>
> The data elements adopt the same naming convention, where the
>
>    leading character of each word uses upper-case and the remaining
> characters use lower-
>
>    case,
>
>
>
> Typo: “symbol”
>
>
>
> Section 3:
>
>
>
> Regarding:
>
>
>
> The name of the report MUST be unique and this characteristic MUST be
> enforced by
>
>    registry.
>
>
>
> Similar to the previous comment.  I _*think*_ that in this context
> “registry” refers to “IANA report registry” (and not the report producer).
> Would be good to clarify regardless.
>
>
>
>
>
> This turned out longer than I expected.  There are probably things that I
> missed.  Hope it’s helpful.
>
>
>
> Thanks,
>
> Rick
>
>
>
>
>
> *From: *regext <regext-bounces@ietf.org> on behalf of
> internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Wednesday, June 8, 2022 at 5:22 PM
> *To: *i-d-announce@ietf.org <i-d-announce@ietf.org>
> *Cc: *regext@ietf.org <regext@ietf.org>
> *Subject: *[EXTERNAL] [regext] I-D Action:
> draft-ietf-regext-simple-registration-reporting-07.txt
>
> CAUTION: This email came from outside your organization. Don’t trust
> emails, links, or attachments from senders that seem suspicious or you are
> not expecting.
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Registration Protocols Extensions WG of
> the IETF.
>
> Title : Simple Registration Reporting
> Authors : Joseph Yee
> James Galvin
> Filename : draft-ietf-regext-simple-registration-reporting-07.txt
> Pages : 35
> Date : 2022-06-08
>
> Abstract:
> Domain name registries (the producer) and registrars (the consumer)
> report to each other by sharing bulk information through files. This
> document creates two IANA registries to establish a standard
> reporting mechanism between domain name registries and registrars.
> The first IANA registry lists standard data elements and their syntax
> for inclusion in the files. The second IANA registry lists standard
> reports based on the standard data elements. Each report is a file
> formatted as a CSV file. The advantage of this reporting mechanism
> is that a report, each file, can be imported by recipients without
> any prior knowledge of their contents, although reporting is enhanced
> with a minimum of knowledge about the files. The mechanism for the
> distribution of and access of the files is a matter of local policy.
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/
> <https://protect-us.mimecast.com/s/PBFoCjRNX8inNRVU1YbO9?domain=datatracker.ietf.org>
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-07.html
> <https://protect-us.mimecast.com/s/6NS9CkRNY7iOG5Ph8I2X8?domain=ietf.org>
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-07
> <https://protect-us.mimecast.com/s/cYz1ClYNZ7C24XjFVSw62?domain=ietf.org>
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> <https://protect-us.mimecast.com/s/gRR5CmZg1yCj4W9C3ox2a?domain=ietf.org>
>