Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

[Mario Loffredo <[e-mail]>]

Il 24/06/2022 23:07, Roger D Carney ha scritto:
> Good Afternoon,
>
> Thanks Jim and Rick, I agree that option B looks like the best 
> collaborative option.

+1


have always expressed my preference for Approach B (and C secondarily).


Mario

>
>
> Thanks
> Roger
>
> ------------------------------------------------------------------------
> *From:* regext <[e-mail]> on behalf of Rick Wilhelm 
> <[e-mail]>
> *Sent:* Friday, June 24, 2022 11:37 AM
> *To:* Gould, James <jgould=[e-mail]>; 
> [e-mail] <[e-mail]>; 
> shollenbeck=[e-mail] 
> <shollenbeck=[e-mail]>; [e-mail] 
> <[e-mail]>
> *Subject:* Re: [regext] OK, What Next? (was RDAP Extensions Approach 
> Analysis v2)
> Caution: This email is from an external sender. Please do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. Forward suspicious emails to isitbad@.
>
> I have been watching this discussion with great interest. Thanks to 
> Jim Gould for the below.  As it’s been a week and no one has commented 
> on this summary, I will assume that prior participants view the below 
> as largely reasonable.
>
> In considering the below, I’ll offer the observations related to two 
> key use-cases related to implementers.
>
> Use-case: Determine the version from the conformance identifier:
>
> Approach A:  The version information is in the prefix, probably at the 
> end and without a defined separator (in all examples I’ve seen).  The 
> most logical place for the version is at the END of the prefix and 
> therefore, the version is placed in the middle of the conformance 
> identifier.  While a reader can detect the version by looking closely, 
> this seems like a big disadvantage for an implementer seeking to parse 
> the conformance identifier.  I would have a hard time writing that 
> code.  Others might be better programmers.
>
> Approach B/C:  Version information at the end; using the underbar.  
> Seems easy to parse via code.  Super-easy to read.
>
> Implementers need to be able to determine the version quickly and 
> reliably in code.  For this, either Approach B or Approach C is the 
> better fit.  Approach A works for human readers, but not for code.
>
> Use-case: Interacting with IANA Registry as an extension implementer:
>
> Approach A:  Create a new registry entry when creating a new extension 
> or when the version changes.   Registry entry integrates version. 
> Benefit:  IANA registry has full record of all versions.  Drawback:  
> Seems hard to express version compatibility.
>
> Approach B:  Create a new registry entry when creating a new 
> extension, but NO interaction required when creating a version.
>
> Approach C:  Create a new registry entry when creating a new 
> extension.  Create a new versioned extension identifier when creating 
> a new version of an existing extension.   Registry entry decoupled 
> from versioning. Benefit: IANA registry has full record of all versions.
>
> In my experience, IANA registries are typically managed to avoid 
> namespace collision.  They do not typically have an explicit mechanism 
> for versioning.  For example:
>
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fprotocol-numbers%2Fprotocol-numbers.xhtml&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uTXePdmzasi%2FJAXvf7Aq%2FdCB1PWG3WxHXOYEEVZtVwQ%3D&reserved=0>
>
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fdns-sec-alg-numbers%2Fdns-sec-alg-numbers.xhtml%23dns-sec-alg-numbers-1&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8LrZ1Kc5a9NmxjyZ717bGehtFLMSKPSwgd4CtE8gcMs%3D&reserved=0>
>
> https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-extensions-1 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fepp-extensions%2Fepp-extensions.xhtml%23epp-extensions-1&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WUaiml%2FzBK2yXYiOPwiUnLNoeDXBxyOLWjNTQ7D3hNY%3D&reserved=0> 
>
>
> If client-side implementers used the IANA RDAP Extensions registry for 
> discovery, then it might make sense to have some versioning 
> mechanism.  However, unlike the various RDAP Bootstrap registries, I 
> do not believe that the IANA RDAP Extensions registry is used for 
> discovery.
>
> This would tilt the decision in favor of B because it results in a 
> simpler RDAP Extensions registry.
>
> I wonder if, over the long term, Approach A might discourage protocol 
> evolution because the version information is embedded.
>
> Regardless, when looking at the combination of these use-cases, I 
> think that Approach B is the better fit overall:  simple to parse and 
> a simpler RDAP Extensions registry.
>
> Happy to hear other points of view to move the discussion forward and 
> get us toward closure.
>
> I think that whatever we do, it is going to require some clean-up.  
> But I would offer that the situation is never going to get any 
> easier.  From an implementation standpoint, RDAP is still in the early 
> stages.  Let’s make the investment now.
>
> Thanks
>
> Rick
>
> *From: *regext <[e-mail]> on behalf of Gould, James 
> <jgould=[e-mail]>
> *Date: *Friday, June 17, 2022 at 9:02 AM
> *To: *[e-mail] <[e-mail]>, 
> shollenbeck=[e-mail] 
> <shollenbeck=[e-mail]>, [e-mail] 
> <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions 
> Approach Analysis v2)
>
> *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.*
>
> ------------------------------------------------------------------------
>
> I agree with Mario that we need to first consider the approaches 
> presented (approach A, B, and C) prior to determining what changes 
> need to be made to the existing RFCs.  I believe that the use of the 
> "lunarNIC_level_0" identifier is appropriate for the RDAP Conformance 
> value in RFC 9083 to signal support for the specification.
>
> The gap that exists in the RFCs is how to support versioning of the 
> RDAP extensions.  The RDAP conformance identifiers can support 
> versioning, with "rdap_level_0" providing the base identifier for RDAP 
> itself.  There is nothing that explicitly ties the prefix 
> registrations with the RDAP conformance identifier registrations, 
> where the prefixes define new path segment and response elements, and 
> the RDAP conformation identifier signals the support for a 
> specification.  I believe the RDAP Conformance identifiers should 
> include the versioning, like the namespace URI in XML, and the 
> prefixes should not include versioning, like the namespace prefix in 
> XML.   If we consider the versioning of RDAP extensions, I include an 
> example of each approach in the drafts below:
>
>  1. Approach A -
>     https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-15
>     <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FgmaECADgR1HNQmZfGNRzE%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kIE%2BMq1B4GKgfwhtC%2FuL1YRPIFgDO9p1ixB6gAwSkCM%3D&reserved=0>
>
>      1. Registration of versioned extension prefix “roidc1”, that is
>         used for the RDAP conformance and used as an RDAP prefix, as
>         in “roidc1_session”, “roidc1_deviceInfo”,
>         “roidc1_openidcConfiguration”.
>      2. If the version changes, all the extension elements (RDAP
>         conformance and the RDAP prefixes elements will change), and
>         there is no formal format for the version number.
>  2. Approach B -
>     https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-04#section-6
>     <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F5HCkCBBjV6f7GZDi6yN-J%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EUdsVt9sDEtIPYhKr5Y8fgIx6Wz%2BaXBI1FxDqylsMzc%3D&reserved=0>
>
>      1. Registration of the extension prefix “redacted”, which is used
>         for the new response member and used as the prefix used in the
>         versioned RDAP conformance value “redacted_level_0.2”.  Note,
>         the use of “.” does not match RFC 7480, so the versioned RDAP
>         Conformance value should have been “redacted_level_0_2”.
>      2. The version of the RDAP Conformance is defined in the
>         associated specification, but it will use the unique prefix
>         registered in the RDAP Extension Registry.
>      3. This provides the linkage similar to Approach A, but doesn’t
>         cascade versioning into the prefix and the extension elements.
>  3. Approach C -
>     https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-07
>     <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FG7WTCDklX8F596oHAnunI%3Fdomain%3Ddatatracker.ietf.org&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=b0xHcQiQziEKP2DtATVpWxVowVw7ht7DERaarDrZlfk%3D&reserved=0>
>
>      1. Registration of the extension prefix “redacted” and the
>         versioned extension identifier “redacted_level_0_3”, where
>         there can be more than one extension prefix “redacted”,
>         “redacting”, “redaction” registered along with the versioned
>         extension identifier “redacted_level_0_3”.  The RDAP
>         conformance identifier is used for signaling only and the
>         registered prefixes ensure uniqueness with other RDAP extensions.
>
> I’m starting to think that Approach B may satisfy both requirements of 
> those advocating for Approach A and those advocating for Approach C, 
> where there is a linkage between the RDAP conformation value and the 
> RDAP prefixed in Approach A, and there is versioning support that is 
> isolated to the RDAP conformance in Approach C. The RFCs mix of the 
> term prefix and identifier would need to be clarified and how 
> versioning is handled needs to be defined.
>
> -- 
>
> JG
>
> James Gould
>
> Fellow Engineer
>
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/ 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F5kk9CERmYxi37AlSP2r_h%3Fdomain%3Dverisigninc.com%2F&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=8m6cngcRSoZ1nHbM9X9gjCMZ3BszpSHJ5%2BTfCO4%2FnJE%3D&reserved=0>>
>
> On 6/16/22, 10:08 AM, "regext on behalf of Mario Loffredo" 
> <[e-mail] on behalf of [e-mail]> wrote:
>
> 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.
>
> Hi Scott,
>
> Il 16/06/2022 15:30, Hollenbeck, Scott ha scritto:
>
> >> -----Original Message-----
>
> >> From: regext <[e-mail]> On Behalf Of Mario Loffredo
>
> >> Sent: Thursday, June 16, 2022 2:57 AM
>
> >> To: [e-mail]
>
> >> Subject: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions
>
> >> Approach Analysis v2)
>
> >>
>
> >> 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.
>
> >>
>
> >> Hi folks,
>
> >>
>
> >> I invite you to consider that, currently, rdap-reverse-search and,
>
> >> potentially,
>
> >> three other RDAP-related docs are blocked waiting for the end of this
>
> >> discussion.
>
> > [SAH] There's no reason for the documents to be blocked if you adopt the
>
>   > practice described in 9083. Look at Section 2.1 (Naming):
>
> >
>
> > "Servers that insert such unspecified members into JSON responses 
> SHOULD have
>
> > member names prefixed with a short identifier followed by an underscore
>
> > followed by a meaningful name"
>
> >
>
> > We need an identifier for "unspecified members" (extension elements) 
> that's to
>
> > be used as a prefix. Further:
>
> >
>
> > "If The Registry of the Moon desires to express information not 
> found in this
>
>   > specification, it might select "lunarNIC" as its identifying 
> prefix and
>
> > insert, as an example, the member named "lunarNIC_beforeOneSmallStep" to
>
> > signify registrations occurring before the first moon landing and 
> the member
>
> > named "lunarNIC_harshMistressNotes" that contains other descriptive 
> text."
>
> >
>
> > This example shows the identifying prefix being used in two 
> examples. This
>
> > begs the question: "What is registered with IANA and returned in the
>
> > rdapConformance data structure?". Section 4.1 (RDAP Conformance) has the
>
> > answer:
>
> >
>
> > "When custom JSON values are inserted into responses, conformance to 
> those
>
> > custom specifications MUST be indicated by including a unique string 
> literal
>
> > value registered in the IANA RDAP Extensions registry specified in 
> [RFC7480].
>
> > For example, if the fictional Registry of the Moon wants to signify 
> that their
>
> > JSON responses are conformant with their registered extensions, the 
> string
>
> > used might be "lunarNIC_level_0"."
>
> >
>
> > This unambiguously tells us that the value registered with IANA is 
> included in
>
> > the rdapConformance data structure. If you consider the text from 
> Section 2.1,
>
> > the only thing that make sense is if these identifiers are one and 
> the same.
>
> > That's why I'm saying that the example in 4.1 is incorrect and needs 
> to be
>
> > fixed. It should be "lunarNIC" to be consistent with Section 2.1 
> such that the
>
> > identifier used with "unspecified members" is the same identifier that's
>
> > returned in the rdapConformance data structure and the same 
> identifier that's
>
> > registered with IANA.
>
> >
>
> >> In addition, it seems to me more logical, first, to decide how RDAP
>
> >> exentions
>
> >> must be treated and, then, correct RFC 9083 to make it consistent 
> with what
>
> >> decided.
>
> > [SAH] 9083 already describes how extensions must be treated. If there's
>
> > anything unclear about that description, that lack of clarity should be
>
> > addressed first. If the WG wants to *change* that description, that's a
>
> > different discussion.
>
> [ML] Whatever will be the approach (A,B, or C) we'll agree on, RFC 9083
>
>     needs to be updated.
>
> But depending on the approach agreed, the corrections needed will be
>
>     different and they wiil involve either the definitions or the 
> examples
>
>     or both.
>
> Likewise, the elected approach could imply possible changes to the
>
>     existing documents.
>
> Best,
>
> Mario
>
> > Scott
>
> > _______________________________________________
>
> > regext mailing list
>
> > [e-mail]
>
> > 
> https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FIqfWCG6o18i17yBfknsBU%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KmvSoXaCm6kQ0B9%2F5hZBiINnzfvRaeUKlOa0rKEYkEI%3D&reserved=0>
>
> -- 
>
>     Dr. Mario Loffredo
>
> Technological Unit “Digital Innovation”
>
> Institute of Informatics and Telematics (IIT)
>
> National Research Council (CNR)
>
> via G. Moruzzi 1, I-56124 PISA, Italy
>
> Phone: [phone]
>
> Web: 
> http://secure-web.cisco.com/14ojfrPjCC0uZKbflsEuxNfFgHKsAz5anzd-kaxzeNZsRbCoDuDjpzlEzWIzaM5MM8XZjqFJHKfGDDPcnA6dr_GgY2-CXYGZieUsDALj1M9E2Fmebwzya7Wp3wKKqZ0rg6uy10EnPPBNDdD83p4kCSKx4Cll-08iXc0jKVi-322wXWyKG1ITCW0m1sdJEkipnozrferGaRL91A5v6j0PkC4lg_f2Dh9-sN84qFT8BhMJeNh1aHQvYc0Sp-Lh9J7D3/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FDqKiCJ6r4QiqJ4BtOAOnl%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hRnJH5UIGfPnAXbIXGJwdgThplTJnFmvyNpEJzgHu9E%3D&reserved=0>
>
> _______________________________________________
>
> regext mailing list
>
> [e-mail]
>
> https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FIqfWCG6o18i17yBfknsBU%3Fdomain%3Dsecure-web.cisco.com&data=05%7C01%7Crcarney%40godaddy.com%7Cf7f575f03b434a22320808da55ffe472%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637916855724654440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KmvSoXaCm6kQ0B9%2F5hZBiINnzfvRaeUKlOa0rKEYkEI%3D&reserved=0>
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo