[regext] Robert Wilton's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-regext-rfc7484bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



--
COMMENT:
--

Hi,

Thanks for this document.

Regarding, 5.3.  Bootstrap Service Registry for AS Number Space

   The complete
   query is, therefore, "https://example.net/rdaprir2/autnum/65411";.  If
   the server does not answer, the client can then use another URL
   prefix from the array.

Does allowing URLs over http:// potentially open up the possibility of
downgrade attacks, e.g., DDOS'ing the https version of a service to force it to
use a service available on an http version instead?  Would it be helpful to
describe this in the security section, perhaps recommending that only https://
URLs are used?

As a trivial nit, I would suggest "ordered" is better than "sorted" in section
3, and perhaps also in section 13.

Thanks,
Rob



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Lars Eggert's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-regext-rfc7484bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



--
COMMENT:
--

DOWNREF [RFC3339] from this Internet Standard to Proposed Standard RFC3339,
which already was in RFC7484, so no action now I guess.

DOWNREF [RFC5396] from this Internet Standard to Proposed Standard RFC5396,
which was added in this doc but seems fully OK. Given the content of RFC5396,
we should add it to the DOWNREF registry I think.

Thanks to Joel Halpern for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/G7JSzW2J05YJ9gh1NO1FY1TLf78).

---
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
> on the existing entries of the above mentioned registries. An RDAP client fe
>^^^
The adjective "above-mentioned" is spelled with a hyphen.

Section 8. , paragraph 4, nit:
> nts, where the first ARRAY-VALUE is a an entry-list and the second ARRAY-VAL
> 
Two determiners in a row. Choose either "a" or "an".

Uncited references: [RFC7071].



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [Gen-art] Genart last call review of draft-ietf-regext-rfc7484bis-04

[Lars Eggert]

Joel, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2021-10-6, at 22:08, Joel Halpern via Datatracker  wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-regext-rfc7484bis-04
> Reviewer: Joel Halpern
> Review Date: 2021-10-06
> IETF LC End Date: 2021-10-27
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as an Internet Standard
> 
> Major issues: N/A
> 
> Minor issues:
>I think this is intended to move the document to Full Internet Standard.
>If so, it would have been nice if there were an appendix "Changes since rfc
>7484.  It could have said "There are no substantive changes except for
>updates to the implementation status section of the document.  This update
>is primarily to meet the requirements for moving to Internet Standard."
> 
> Nits/editorial comments: N/A
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Francesca Palombini's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-regext-rfc7484bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



--
COMMENT:
--

Thank you for the work on this document.

Many thanks to Russ Housley for the ART ART review:
https://mailarchive.ietf.org/arch/msg/art/XJJLbQHKjAxsAlScJL3BKX9vMOA/ and
Carsten Bormann for providing CDDL feedback (more below).

I have a couple of non-blocking comments, but I would really appreciate an
answer.

Francesca

1. -

FP: Please replace references to RFC 7234 with draft-ietf-httpbis-cache-19.

2. 

Section 10.2

FP: This section is quite clear, but I can't not notice that CDDL
(https://datatracker.ietf.org/doc/html/rfc8610) would have been a good addition
to this document. Here is a proposal

rdap-bootstrap-registry = {
  "version": tstr,
  "publication": tstr,
  ? "description": tstr,
  "services": [+ service]
}

service = [
  entry-list,
  service-uri-list
]

entry-list = [+ entry: tstr]

service-uri-list = [+ service-uri: tstr]

Note that I have marked each of the services, entry-list and service-uri-list
arrays as containing "one or more" element - if these arrays can be empty, then
"+" should be replaced by "*". Which raise the question - can any of them be
empty? What would be the meaning in that case? And also nicely shows why
defining the CDDL is always a Good Thing.



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Benjamin Kaduk's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-rfc7484bis-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/



--
DISCUSS:
--

There are two errata reports against RFC 7484, both in status
"reported"
(https://www.rfc-editor.org/errata_search.php?rfc=7484&rec_status=15).
Part of the requirements for advancing a document to Internet Standard
is to address all errata reports against the original document.  On a
superficial reading of the diff from RFC 7484 to this document it does
appear that changes are included that would address these two errata
reports, but that should probably be acknowledged in the text, and the
responsible AD should use the RFC Editor's errata tool to process the
reports accordingly.


--
COMMENT:
--

I agree with the genart reviewer that a "changes since RFC 7484" section
would be worthwhile.  This would be especially helpful for the changes
in Section 8, only part of which seem clearly motivated by the errata
report https://www.rfc-editor.org/errata/eid5460 .  (Why do we no longer
mention the possibility of defering discovery to a trusted RDAP
aggregator or redirector?)

Section 3

   The RDAP Bootstrap Service Registries, as specified in Section 13
   below, have been made available as JSON [RFC8259] objects, which can
   be retrieved via HTTP from locations specified by IANA.  The JSON

While in a certain technical sense, using HTTPS still qualifies as
"retrieved via HTTP", I'd suggest changing this to "HTTPS" to provide
more straightforward guidance to use the access mechanism that provides
integrity protection and source authenticity.

   The optional "description" string can contain a comment regarding the
   content of the bootstrap object.

If this "comment" is intended for human consumption, does the guidance
from BCP 18 about including language information come into play?

   JSON names MUST follow the format recommendations of [RFC7480].  Any

A quick text search in RFC 7480 for "format" didn't pull up anything
that obviously corresponded to this reference.  If we refer to the ABNF
in §6 of that document, perhaps a section reference is in order?

Section 8

   Some authorities of registration data may work together on sharing
   their information for a common service, including mutual redirection
   [REDIRECT-RDAP].

The [REDIRECT-RDAP] draft expired in 2014.  Is this text still useful?

Section 11

   The
   transport used to access the registries can be more secure by using
   TLS [RFC8446], which IANA supports.

In a similar vein to Roman's comment, I note the following text from RFC
7481:

%HTTP over TLS MUST be used to
% protect all client-server exchanges unless operational constraints
% make it impossible to meet this requirement.  [...]

It seems that we could use a different phrasing here that is more
commensurate with the requirements of STD 95.

Section 13

The RDAP Bootstrap Services Registries will
   start empty and will be gradually populated as registrants of domains
   and address spaces provide RDAP server information to IANA.

This text about "start empty" seems a bit stale, now.

   Since the first publication of
   this RFC, no issue have been reported regarding the load or the
   service.

I agree with the directorate reviewer that "first publication of RFC
7484" seems more correct.

   As discussed in Section 8, software that accesses these registries
   will depend on the HTTP Expires header field to limit their query

(nit?) saying "will depend" is perhaps implying a stronger requirement
than what Section 8 actually covers.

Section 14.2

We say that "JSON names MUST follow the format recommendations of
[RFC7480]", which would seem to require RFC 7480 to be a normative
reference.  (That would not cause a new downref, fortunately.)



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext