Re: [regext] id_token parameter usage in rdap-openid

[Hollenbeck, Scott]

> -Original Message-
> From: Tom Harrison 
> Sent: Tuesday, January 25, 2022 12:04 AM
> To: Hollenbeck, Scott 
> Cc: mario.loffr...@iit.cnr.it; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] id_token parameter usage in rdap-openid
> 
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> On Mon, Jan 24, 2022 at 02:43:40PM +, Hollenbeck, Scott wrote:
> > [SAH] The best thing we can do is to explain the situation in Section
> > 3.1.3.1.  What's there now needs to change:
> >
> > OLD:
> > 3.1.3.1.  Provider Discovery
> >
> > An RDAP server/RP needs to receive an identifier from an End-User that
> > can be used to discover the End-User's OP.  That process is required
> > and is documented in the "OpenID Connect Discovery"
> > protocol [OIDCD].
> >
> > PROPOSED NEW:
> > 3.1.3.1.  Provider Discovery
> >
> > An RDAP server/RP needs to be able to map an End-User's identifier to
> > an OP.  This can be accomplished using the OPTIONAL "OpenID Connect
> > Discovery" protocol [OIDCD], but that protocol is not widely
> > implemented and can be unreliable. Out-of-band methods are also
> > possible and can be more dependable.  For example, an RP can support a
> > limited number of OPs and maintain internal associations of those
> > identifiers with the OPs that issued them. An RP can also ask an
> > end-user to identify the OP that issued their identifier as part of an
> > RDAP query workflow. An RP MAY use any provider discovery approach
> > that is suitable for its operating environment.
> >
> > How does that sound?
> 
> I think this is fine, but one adjustment for the "select an OP" case:
> 
> An RP can also ask an end-user to identify the OP that issued
> their identifier as part of an RDAP query workflow.  In this case,
> the RP will need to maintain state for the association between the
> user's identifier and the OP in order to process later queries
> that rely on passing the access token and user identifier as
> authorization parameters.
> 
> Alternatively, the RDAP client could pass the issuer value (from the ID token)
> instead of the user identifier when doing this sort of query.

[SAH] Thanks. I'll use the addition you suggested above.

Scott

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

[regext] I-D Action: draft-ietf-regext-rfc7484bis-05.txt

[internet-drafts]

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   : Finding the Authoritative Registration Data (RDAP) 
Service
Author  : Marc Blanchet
Filename: draft-ietf-regext-rfc7484bis-05.txt
Pages   : 20
Date: 2022-01-25

Abstract:
   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer queries for
   a requested scope, such as domain names, IP addresses, or Autonomous
   System numbers.  This document obsoletes RFC7484.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7484bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rfc7484bis-05


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

Re: [regext] I-D Action: draft-ietf-regext-rfc7484bis-05.txt

[Marc Blanchet]

Hello,
 This draft should be fixing all issues (mostly editorial) regarding comments 
from IESG, LC and Area reviews, except two topics on which I will send an email 
 as separate thread to the mailing list and the reviewers.

So you shall see in the next mails my responses to the reviews with notes 
saying about if it is fixed in -05 or not. Most of them (if not all) are 
editorial.

I will then send an email regarding the two topics that were raised during the 
reviews and where I think we shall discuss and are more substantive.

Regards, Marc.

> Le 25 janv. 2022 à 17:09, internet-dra...@ietf.org a écrit :
> 
> 
> 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   : Finding the Authoritative Registration Data (RDAP) 
> Service
>Author  : Marc Blanchet
>   Filename: draft-ietf-regext-rfc7484bis-05.txt
>   Pages   : 20
>   Date: 2022-01-25
> 
> Abstract:
>   This document specifies a method to find which Registration Data
>   Access Protocol (RDAP) server is authoritative to answer queries for
>   a requested scope, such as domain names, IP addresses, or Autonomous
>   System numbers.  This document obsoletes RFC7484.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7484bis-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rfc7484bis-05
> 
> 
> 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

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

Re: [regext] Artart last call review of draft-ietf-regext-rfc7484bis-04

[Marc Blanchet]

> Le 30 sept. 2021 à 17:29, Russ Housley via Datatracker  a 
> écrit :
> 
> Reviewer: Russ Housley
> Review result: Ready
> 
> I am the assigned ARTART reviewer for this Internet-Draft.
> 
> Document: draft-ietf-regext-rfc7484bis-04
> Reviewer: Russ Housley
> Review Date: 2021-09-30
> IETF LC End Date: 2021-10-27
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major Concerns: None.
> 
> Minor Concerns: None.
> 
> Nits:
> 
> Section 13 says: "Since the first publication of this RFC ..."
> Please reword.  I think you mean since RFC 7484 was published.
> 

Done in -05

Thanks, Marc.


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

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

[Marc Blanchet]

> Le 6 oct. 2021 à 15:08, Joel Halpern via Datatracker  a 
> écrit :
> 
> 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."

Done in -05

Regards, Marc.


> 
> Nits/editorial comments: N/A
> 
> 
> 

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

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

[Marc Blanchet]

> Le 29 nov. 2021 à 05:22, Robert Wilton via Datatracker  a 
> écrit :
> 
> 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?


Will be discussed in a separate thread

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

Done in -05

Marc.

> 
> Thanks,
> Rob
> 
> 
> 

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

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

[Marc Blanchet]

> Le 29 nov. 2021 à 09:01, Lars Eggert via Datatracker  a 
> écrit :
> 
> 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.

no action taken

> 
> 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.

no action taken on my side

> 
> 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.

Done in -05


> 
> 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".

Done in -05


> 
> Uncited references: [RFC7071].
> 

RFC7071 is referenced in the Acknowledgements section, so no action 
taken

Regards, Marc.

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

Re: [regext] Erik Kline's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Marc Blanchet]

> Le 1 déc. 2021 à 14:37, Erik Kline via Datatracker  a écrit 
> :
> 
> Erik Kline 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:
> --
> 
> [S5.2 & 13.2, comment]
> 
> * It's probably better to refer to RFC 5952 for IPv6 text representations.
>  (If not, why not?)
> 

Done in -05

> [S5.3, comment]
> 
> * It might be good to place additional restrictions on the ordering of
>  AS numbers in the range syntax to require increasing order, ["101-202"],
>  and not allow ["202-101”]


Done in -05

Thanks, Regards, Marc.

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

Re: [regext] John Scudder's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Marc Blanchet]

> Le 1 déc. 2021 à 21:05, John Scudder via Datatracker  a 
> écrit :
> 
> John Scudder 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:
> --
> 
> Thanks for the useful and easy to follow spec. I have a few questions and
> comments below, I hope some of them are helpful.
> 
> 1. In §5 you write,
> 
>   The longest match is done the same way as for
>   routing:
> 
> I might prefer “… same way as for packet forwarding“. It isn’t a big deal,
> though.
> 

Done in -05

> 2. In §5.1 you write,
> 
>   The latter is chosen by the client given the longest match.
> 
> I suggest “because it is” instead of “given“. (Similar in §5.2)

Done in -05


> 
> 3. In §5.3 you write,
> 
>  The array
>   always contains two AS numbers represented in decimal format
> 
> Don’t you mean, “each array element always contains…“? Also, it appears what 
> it
> really contains is two ASNs *separated by a hyphen*.

Yes.

> 
> 4. Again with respect to §5.3, is there no need for most-specific match
> semantics for ASNs? I’m imagining that presented with the choices of a larger
> or smaller range to match a given query, the smallest matching range would be
> used. E.g., given a query of 65501 and two entries, one for 65500-65535 and
> another for 65501-65501, the latter would be chosen. No?

Added a sentence in -05 to the effect that ranges must not overlap. 

> 
> 5. In §6 you mention a “fully referenced URL”. Do you mean “fully-qualified “?

Done in -05


THanks, Regards, Marc.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Éric Vyncke's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)

[Marc Blanchet]

> Le 1 déc. 2021 à 05:39, Éric Vyncke via Datatracker  a 
> écrit :
> 
> Éric Vyncke 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:
> --
> 
> Thank you for the work put into this document. Special congratulations for
> having THREE implementations including one by the author.
> 
> Please find below one blocking DISCUSS point (trivial to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only for
> my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.
> 
> Special thanks to Jasdip Singh for the shepherd's write-up including the
> section about the WG consensus.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> -- Section 5.2 --
> The end of this section uses
> "https://example.net/rdaprir2/ip/2001:0db8:1000::/48"; (not RFC 5952 compatible
> with the leading zero in front of "db8") as an example but this example seems
> to contradict section 3.1.1 of RFC 9082.

Done in -05

> 
> 
> --
> COMMENT:
> --
> 
> == COMMENTS ==
> 
> -- Section 1 --
> No need to reply, but I really appreciate the author's use of the past tense 
> in
> "Per this document, IANA has created new registries" as opposed to similar
> documents using the future tense. This document will age well ;-)
> 

no action


> -- Section 3 --
> "be retrieved via HTTP from locations specified by IANA" should this document
> include the IANA location ?
> 

To my knowledge, it has been the policy of IANA/IETF to not publish the 
location
URL of the registries in RFCs

> Should a "real" date be used rather than "-MM-DDTHH:MM:SSZ" ? I.e., the
> syntax is specified later anyway so let's use a real example ? Later examples
> in section 5 use "real" dates but not those in section 4 ;-)

Done in -05

> 
> -- Section 5.2 --
> Should RFC 5952 also be specified as IPv6 representation in addition to RFC
> 4291 ?

Done in -05


> -- Section 5.3 --
> The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do
> not mind too much that the example in this section uses private ASN space but
> suggest anyway to limit the example to the documentation ASNs.

Private ASN space enables the document to provide various cases. 
Documentation ASN space is too short to properly show the various cases


THanks, Regards, Marc.


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

[regext] Éric Vyncke's No Objection on draft-ietf-regext-rfc7484bis-05: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-rfc7484bis-05: 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 addressing my blocking DISCUSS (ok it was trivial to fix ;-) )
and replying to all my comments below. I have kept it below for archiving only,
ignore it.

Thank you for the work put into this document. Special congratulations for
having THREE implementations including one by the author.

Please find below one archived DISCUSS point (trivial to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.

Special thanks to Jasdip Singh for the shepherd's write-up including the
section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

== Archived DISCUSS for history — to ignored ==

-- Section 5.2 --
The end of this section uses
"https://example.net/rdaprir2/ip/2001:0db8:1000::/48"; (not RFC 5952 compatible
with the leading zero in front of "db8") as an example but this example seems
to contradict section 3.1.1 of RFC 9082.

== COMMENTS ==

-- Section 1 --
No need to reply, but I really appreciate the author's use of the past tense in
"Per this document, IANA has created new registries" as opposed to similar
documents using the future tense. This document will age well ;-)

-- Section 3 --
"be retrieved via HTTP from locations specified by IANA" should this document
include the IANA location ?

Should a "real" date be used rather than "-MM-DDTHH:MM:SSZ" ? I.e., the
syntax is specified later anyway so let's use a real example ? Later examples
in section 5 use "real" dates but not those in section 4 ;-)

-- Section 5.2 --
Should RFC 5952 also be specified as IPv6 representation in addition to RFC
4291 ?

-- Section 5.3 --
The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do
not mind too much that the example in this section uses private ASN space but
suggest anyway to limit the example to the documentation ASNs.



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

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

[Marc Blanchet]

> Le 29 nov. 2021 à 16:37, Benjamin Kaduk via Datatracker  a 
> écrit :
> 
> 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.
> 

acknowledgement has been added in -05

> 
> --
> 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 .

appendix has been added in -05

>  (Why do we no longer
> mention the possibility of defering discovery to a trusted RDAP
> aggregator or redirector?)

Because we feel this is outside of the scope of the document

> 
> 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.

Will be discussed in a separate thread


>   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?

Not human consumption, but more IANA and developers. No action taken.


>   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 number added in -05

> 
> 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?

Yes it is still useful as it is currently being used in production, even if 
the draft has expired

> 
> 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.

Will be discussed in a separate thread


> 
> 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.

Sentence removed in -05

> 
>   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.

Done in -05

>   As discussed in Section 8, software that accesses these registries
>   will depen

Re: [regext] Éric Vyncke's Discuss on draft-ietf-regext-rfc7484bis-04: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Merci Marc, for all your detailed answers and addressing the blocking DISCUSS 
point.

I have now cleared my DISCUSS ballot,

Good job by the authors, the shepherd, and the WG !

Regards

-éric

From: Marc Blanchet 
Date: Tuesday, 25 January 2022 at 23:25
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-regext-rfc7484...@ietf.org" 
, regext-chairs 
, regext , Jasdip Singh 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-regext-rfc7484bis-04: (with 
DISCUSS and COMMENT)




Le 1 déc. 2021 à 05:39, Éric Vyncke via Datatracker 
mailto:nore...@ietf.org>> a écrit :

Éric Vyncke 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:
--

Thank you for the work put into this document. Special congratulations for
having THREE implementations including one by the author.

Please find below one blocking DISCUSS point (trivial to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education). I am also sympathetic to Ben Kaduk's DISCUSS point.

Special thanks to Jasdip Singh for the shepherd's write-up including the
section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 5.2 --
The end of this section uses
"https://example.net/rdaprir2/ip/2001:0db8:1000::/48"; (not RFC 5952 compatible
with the leading zero in front of "db8") as an example but this example seems
to contradict section 3.1.1 of RFC 9082.

Done in -05



--
COMMENT:
--

== COMMENTS ==

-- Section 1 --
No need to reply, but I really appreciate the author's use of the past tense in
"Per this document, IANA has created new registries" as opposed to similar
documents using the future tense. This document will age well ;-)

no action



-- Section 3 --
"be retrieved via HTTP from locations specified by IANA" should this document
include the IANA location ?

To my knowledge, it has been the policy of IANA/IETF to not publish the 
location
URL of the registries in RFCs


Should a "real" date be used rather than "-MM-DDTHH:MM:SSZ" ? I.e., the
syntax is specified later anyway so let's use a real example ? Later examples
in section 5 use "real" dates but not those in section 4 ;-)

Done in -05



-- Section 5.2 --
Should RFC 5952 also be specified as IPv6 representation in addition to RFC
4291 ?

Done in -05



-- Section 5.3 --
The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do
not mind too much that the example in this section uses private ASN space but
suggest anyway to limit the example to the documentation ASNs.

Private ASN space enables the document to provide various cases. 
Documentation ASN space is too short to properly show the various cases




THanks, Regards, Marc.



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

Re: [regext] John Scudder's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[John Scudder]

Hi Marc,

Thanks, I just had a look at the diff. I have one further point to follow up on.

> On Jan 25, 2022, at 5:22 PM, Marc Blanchet  wrote:
> 
>> Le 1 déc. 2021 à 21:05, John Scudder via Datatracker  a 
>> écrit :
[…trimmed…]
>> 3. In §5.3 you write,
>> 
>> The array
>>  always contains two AS numbers represented in decimal format
>> 
>> Don’t you mean, “each array element always contains…“? Also, it appears what 
>> it
>> really contains is two ASNs *separated by a hyphen*.
> 
> Yes.

05 still has the text as quoted above. I’m not sure if that was deliberate, or 
an oversight. In case it wasn’t clear, I was suggesting something along these 
lines: 

OLD:
   served by the base RDAP URLs found in the second element.  The array
   always contains two AS numbers represented in decimal format that
   represents the range of AS numbers between the two elements of the
   array, where values are in increasing order (e.g. 100-200, not
   200-100).  A single AS number is represented as a range of two

NEW:
   served by the base RDAP URLs found in the second element.  Each
   element of the array
   contains two AS numbers represented in decimal format, 
   separated by a hyphen, that
   represents the range of AS numbers between the two AS numbers
   (inclusive), where values are in increasing order (e.g. 100-200, not
   200-100).  A single AS number is represented as a range of two

(While I was at it I changed “between the two elements of the array”, which I 
think was just wrong, and added “inclusive”.)

If the text in 05 is exactly the way you want it, that’s OK, I think that for 
practical purposes the ambiguity is unlikely to be a problem, especially given 
the example (which is what I relied on to understand the meaning). I’m just 
pointing this out in case it was an oversight.

Regards,

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

Re: [regext] Call for agenda items IETF 113

[Heather Flanagan]

Hi all-

I suspect we’d like a few minutes to talk about the status of the data 
dictionary and maybe discuss some ideas on avoiding policy implications.

Heather Flanagan
Spherical Cow Consulting



  Translator of Geek to Human
  h...@sphericalcowconsulting.com



‌
On Jan 24, 2022, 6:42 AM -0800, Antoin Verschuren 
, wrote:
> Reminder…
>
>
> Jim and Antoin
>
> > Op 17 jan. 2022, om 15:22 heeft Antoin Verschuren 
> >  het volgende geschreven:
> >
> > Hi All,
> >
> > Ii’s time to think about agenda items for IETF 113 to see how much time we 
> > need for our meeting.
> > The deadline for requesting a meeting slot will be end of next week.
> > Jim and I are thinking to request a same one hour time slot as last IETF 
> > 112 meeting, unless we get a lot of requests from you for new work.
> >
> > So if you intend to request for a presentation, please let the chairs know 
> > before next Monday so we can make a good judgement.
> >
> > Regards,
> >
> > Jim and Antoin
> >
> >
> > ___
> > regext mailing list
> > regext@ietf.org
> > https://www.ietf.org/mailman/listinfo/regext
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Call for agenda items IETF 113

[Steve Crocker]

Heather,

Your suspicion is confirmed :)

Steve


On Tue, Jan 25, 2022 at 6:36 PM Heather Flanagan <
h...@sphericalcowconsulting.com> wrote:

> Hi all-
>
> I suspect we’d like a few minutes to talk about the status of the data
> dictionary and maybe discuss some ideas on avoiding policy implications.
>
> Heather Flanagan
> Spherical Cow Consulting
>  
>
>
>
>   Translator of Geek to Human
>   h...@sphericalcowconsulting.com
>
>
>
> ‌
> On Jan 24, 2022, 6:42 AM -0800, Antoin Verschuren  40antoin...@dmarc.ietf.org>, wrote:
>
> Reminder…
>
>
> Jim and Antoin
>
> Op 17 jan. 2022, om 15:22 heeft Antoin Verschuren  40antoin...@dmarc.ietf.org> het volgende geschreven:
>
> Hi All,
>
> Ii’s time to think about agenda items for IETF 113 to see how much time we
> need for our meeting.
> The deadline for requesting a meeting slot will be end of next week.
> Jim and I are thinking to request a same one hour time slot as last IETF
> 112 meeting, unless we get a lot of requests from you for new work.
>
> So if you intend to request for a presentation, please let the chairs know
> before next Monday so we can make a good judgement.
>
> Regards,
>
> Jim and Antoin
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] John Scudder's No Objection on draft-ietf-regext-rfc7484bis-04: (with COMMENT)

[Marc Blanchet]

> Le 25 janv. 2022 à 17:46, John Scudder  a écrit :
> 
> Hi Marc,
> 
> Thanks, I just had a look at the diff. I have one further point to follow up 
> on.
> 
>> On Jan 25, 2022, at 5:22 PM, Marc Blanchet  wrote:
>> 
>>> Le 1 déc. 2021 à 21:05, John Scudder via Datatracker  a 
>>> écrit :
> […trimmed…]
>>> 3. In §5.3 you write,
>>> 
>>>The array
>>> always contains two AS numbers represented in decimal format
>>> 
>>> Don’t you mean, “each array element always contains…“? Also, it appears 
>>> what it
>>> really contains is two ASNs *separated by a hyphen*.
>> 
>> Yes.
> 
> 05 still has the text as quoted above. I’m not sure if that was deliberate, 
> or an oversight. In case it wasn’t clear, I was suggesting something along 
> these lines: 
> 
> OLD:
>   served by the base RDAP URLs found in the second element.  The array
>   always contains two AS numbers represented in decimal format that
>   represents the range of AS numbers between the two elements of the
>   array, where values are in increasing order (e.g. 100-200, not
>   200-100).  A single AS number is represented as a range of two
> 
> NEW:
>   served by the base RDAP URLs found in the second element.  Each
>   element of the array
>   contains two AS numbers represented in decimal format, 
>   separated by a hyphen, that
>   represents the range of AS numbers between the two AS numbers
>   (inclusive), where values are in increasing order (e.g. 100-200, not
>   200-100).  A single AS number is represented as a range of two
> 
> (While I was at it I changed “between the two elements of the array”, which I 
> think was just wrong, and added “inclusive”.)
> 
> If the text in 05 is exactly the way you want it, that’s OK, I think that for 
> practical purposes the ambiguity is unlikely to be a problem, especially 
> given the example (which is what I relied on to understand the meaning). I’m 
> just pointing this out in case it was an oversight.

Was not an oversight. I thought you were looking for an answer to your comment, 
so I responded “yes” ;-)

Thanks for the text, I’ll add it to the -06, which I need to do anyway because 
I left two topics that need further discussion in the working group/ADs.

Thanks, Marc.



> 
> Regards,
> 
> —John

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

[regext] draft-ietf-regext-rfc7484bis: Requiring secure transport for accessing bootstrap registries

[Marc Blanchet]

Hello,
 As part of the reviews of draft-ietf-regext-rfc7484bis-04 for Internet 
Standard, Benjamin Kaduk has commented as follows:


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.

…

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.



Scott Kelly commented in his review:


Scott Kelly

From the abstract:
  This document specifies a method to find which Registration Data
  Access Protocol (RDAP) server is authoritative to answer queries for
  a requested scope, such as domain names, IP addresses, or Autonomous
  System numbers.  This document obsoletes RFC7484

Here is the security considerations section:

  "By providing a bootstrap method to find RDAP servers, this document
  helps to ensure that the end users will get the RDAP data from an
  authoritative source, instead of from rogue sources.  The method has
  the same security properties as the RDAP protocols themselves.  The
  transport used to access the registries can be more secure by using
  TLS [RFC8446], which IANA supports.

  Additional considerations on using RDAP are described in [RFC7481]."

Because this document is updating RFC7484, and because these security 
considerations are copied verbatim from that doc, I hesitate to raise my 
concern. Nonetheless, I think the assertion that this document "helps to ensure 
that the end users will get the RDAP data from an authoritative source, instead 
of from rogue sources." is questionable. I think the suggestion to use TLS 
helps, but I think it would be better to say something like this:

"This document specifies a method to find which RDAP server is authoritative to 
answer queries for a requested scope, such as domain names, IP addresses, or 
Autonomous System numbers. If this data is not authenticated, an adversary may 
inject data that redirects the user to a rogue RDAP server. A robust 
authentication method such as may be provided by TLS [RFC8446] SHOULD be 
utilized to protect against this.

Additional considerations on using RDAP are described in [RFC7481]."

I'm not attached to the precise wording, but I think implementers should be 
told what the risks are, and how to mitigate them. I don't think the current 
security considerations quite hit that aspiration.



Furthermore, referring to SK text proposal, Benjamin Kaduk added:


This is a good template for actual text to put in the document that covers
TLS usage and the need for it.  However, I think we may even be able to do
better than "TLS SHOULD be utilized", since (as I understand it) RFC 7481
has a requirement that "HTTP over TLS MUST be used to protect all
client-server exchanges unless operational constraints make it impossible
to meet this requirement."  So, we might end this text instead with
"A robust authentication method is provided by TLS [RFC8446], and
accordingly the use of TLS is required by RFC 7481 in the absence of
operational constraints that make use of TLS impossible; in such cases,
alternative authentication methods SHOULD be utilized to protect against
such risks.”


I contacted IANA to ask them if there is any issue for them if we require HTTPS 
for accessing the registries. I’ve been told that:
- they currently serve both http and https, but they do HSTS
- I also get that comment:


While we do publish these resources over HTTPS, and by all means URLs can and 
should be specified with https:// URLs, we should generally avoid dictating 
specific technical choices that dictate the "maximum set" in RFCs unless they 
are critical to implementation. For example, what if there is a new secure 
dissemination technology that is more secure/performant/etc than HTTPS? If 
there is specific text that required it only be served over https would 
preclude publication via additional different means without necessarily issuing 
a superseding RFC. Would we have to discontinue other methods (like mirroring 
our data to IETF via rsync)?

To use an analogy, if we had a policy "Registration data must be published via 
the WHOIS protocol" versus "Registration data must only be published via t

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

[Marc Blanchet]

> Le 29 nov. 2021 à 10:31, Francesca Palombini via Datatracker 
>  a écrit :
> 
> 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.

I have a hard time thinking to replace an RFC reference to a draft in a 
document that would become an Internet Standard. Moreover, I think the 
reference is more about “please look at ways to cache data” more than a hard 
requirement. So I disagree with your proposal. The new -05 do not contain any 
change in that regard. So I’m looking for your reply if you still want me to 
change the reference

> 
> 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.

At the time of writing the first draft, I took what was used in other RFCs 
for a  formal JSON definition. I agree that CDDL seems nicer and easier to 
understand and follow. However, I’m kinda not too warm about changing a formal 
specification while there are no changes in fact on the specification, for 
pushing the document in Internet Standard.  People reading the diff will think 
that the specification has changed, while it has not. The new -05 do not 
contain any change in that regard. So I’m looking for your reply if you still 
want me to use this CDDL snippet

Marc.


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

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

[Benjamin Kaduk]

Hi Marc,

No further comments from me here; I'll look for the separate threads
indicated.

Thanks,

Ben

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