[regext] AD review of draft-ietf-regext-rdap-partial-response-12

Barry Leiba <barryleiba@computer.org> Fri, 24 July 2020 18:17 UTC

Return-Path: <barryleiba@gmail.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 3EB773A110D; Fri, 24 Jul 2020 11:17:00 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 BVxzR8KZfT3e; Fri, 24 Jul 2020 11:16:59 -0700 (PDT)
Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) (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 F2C0D3A1107; Fri, 24 Jul 2020 11:16:55 -0700 (PDT)
Received: by mail-il1-f172.google.com with SMTP id t4so7963980iln.1; Fri, 24 Jul 2020 11:16:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mVwgYlFqoOL7xVbn/mGtaYSkPkMCKnd5PvHH1qtxwtc=; b=Igp41MtyW6gEQHjQfUn+WkyHX7s/S6gcfeyMWO0CMYPvfX+Fvmk3LAjCeS3H6GPNa1 uTGTWtMiGBy6raBSL2jdsw5SvbMCdoiYbL0Ctr8RGhQlccjefaHjHwELEFI0j/pQ452O aEETc/I2yUPHMEAvDhePqZbp1ts7R9FRS/kTDkp4QKk6Yl+N7eeN0mGGG5mrMw/llwIz 0MxXLYLOqZM0oNcT0TT7PJq5GEuVFOulDaWZT0H9w7gJDANshD+nljhbHSRo57qNW0jY eK0FzP69a2HagfHT9lHCl3sflOS3rHmwHWoaHamT6rvt2YgP9YQhNYW1inxZrRzhxMlW M/iw==
X-Gm-Message-State: AOAM531u7wKGEEBAr1pJfPY6JnfLxyXlx75cjyfdAKV6xWmyiTwwBorL 2+IAKCEpoZI9bGRNprvsDsF7mtbAyUoVXWTtxdr3Fg==
X-Google-Smtp-Source: ABdhPJz1M1QibIG5tBC6aULrKpPmRoE2/x4ZuTKQi9XNYkI9PQhzblRYgMAQXODrylbn2Bi+swij35t2oM1gCMRzUm0=
X-Received: by 2002:a05:6e02:8a8:: with SMTP id a8mr11812615ilt.52.1595614614602; Fri, 24 Jul 2020 11:16:54 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 24 Jul 2020 14:16:43 -0400
Message-ID: <CALaySJKBsPa45SJo4Mt480NW==dDbXrsf-7KkUoB4DAkTqBX+Q@mail.gmail.com>
To: "draft-ietf-regext-rdap-partial-response.all@ietf.org" <draft-ietf-regext-rdap-partial-response.all@ietf.org>
Cc: regext <regext@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004d496805ab33fae3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/bLIURJPaIN6obsfwFfpmLKKOFnw>
Subject: [regext] AD review of draft-ietf-regext-rdap-partial-response-12
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, 24 Jul 2020 18:17:00 -0000

Thanks so much for the recent editorial work on this document:  Version -12
is easy to read and clear, and I’m happy to sent it to last call.  I have
some review comments below, but they’re all minor and can be handled as
part of the last call comments.  I will request last call on this right
after I send this note.

— Section 1 —

   Several leading API providers [LINKEDIN] [FACEBOOK] [GOOGLE]
   implement partial response features by providing an optional query
   parameter through which clients identify the fields they wish to
   receive.  Support for partial responses is also considered a leading
   principle by many best practice guidelines in REST API implementation
   [REST-API1] [REST-API2] in order to improve performance, save on
   bandwidth and possibly accelerate the overall interaction.  In other
   contexts, for example in digital libraries and bibliographic
   catalogues, servers can respond according to different element sets
   (i.e. "brief" to obtain a short response and "full" to obtain the
   complete response).

Maybe it’s just me, but I find that paragraph unnecessary.  I suggest
simply removing it (and the references it cites) as extraneous.  This is a
suggestion, not a requirement, so if the working group has a reason to keep
the paragraph, that’s OK.  I just think it doesn’t add anything useful to
the document beyond what’s in the other paragraphs here.

— Section 1.1 —
Please use the exact boilerplate from RFC 8174.

— Section 4 —

   o  "id": the server provides only the key field, respectively:
      "handle" for entities, "ldhName" for domains and nameservers.

Nit: Please remove “, respectively”, as it’s misused here.  Correct use
(though I don’t suggest this change) woud be, ‘the server provides only the
key field: “handle” or “ldhName” for entities or domains and nameservers,
respectively.’

   RDAP providers are RECOMMENDED to include

This is correct and fine as written, but I think it reads better in active
voice as, “RDAP providers  SHOULD include”.

   Fields included in the "brief" and "full" field sets MUST be returned
   according to the user's access and authorization levels.

What is the focus of this sentence?  Is it about what MUST be returned?  Or
that authorization levels MUST be applied?  I think it’s the latter, but
it’s not clear from the wording.  If I’m right, it might be better worded
this way (adjust as appropriate to give the emphasis you really intend):

NEW
   Fields included in the "brief" and "full" field set responses MUST
   take into account the user's access and authorization levels.
END

— Section 6 —
Please make the contact “IETF”, rather than “IESG”.

—
Barry