Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

2023-02-14 Thread Hollenbeck, Scott 
I'm aware of two other RFCs that also define terms like this: 4949 (security) 
and 8499 (DNS). The intended status for this draft is "Standards Track". At 
best, this should be Informational in the same way that 4949 is informational.

Neither of these RFCs creates a registry. As such, I don't see the need for 
the registry described in Section 3. If a registry is really needed, it would 
be helpful to include text that describes why the registry is needed. If a 
case can be made for the registry I'm also confused by the initial assignment 
described in Section 3.2. It includes a data element "Name", with a reference 
to Section 2.1 of the draft, but there is no data element "Name" in Section 
2.1.

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

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

2023-02-14 Thread Gould, James 
I agree with Scott's feedback on the track being changed to Informational and 
removal of the IANA Registry.  

Why doesn't this draft match the approach taken io RFC 8499 for DNS 
Terminology?  The Registration System terms can certainly have overlap with the 
DNS terms in RFC 8499, where the RFC 8499 reference can be made, but the 
definition is catered to registration systems.  I see value with the terms in 
RFC 8499 for reference within drafts.  I would like to see the same value of 
terms defined in draft-ietf-regext-datadictionary.  The term definitions need 
to have adequate detail with relevant references made to the registration RFCs 
(e.g., RFC 5730 - 5733. 9022), which is not currently the case.  My 
recommendation is to refer to this as Registration Terminology instead of 
Registration Data Dictionary, following the approach taken in RFC 8499 for DNS 
terminology, and removing the definition of an IANA registry.   

Thanks,

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  



On 2/14/23, 8:14 AM, "regext on behalf of Hollenbeck, Scott" 
mailto:regext-boun...@ietf.org> on behalf of 
shollenbeck=40verisign@dmarc.ietf.org 
> wrote:



I'm aware of two other RFCs that also define terms like this: 4949 (security) 
and 8499 (DNS). The intended status for this draft is "Standards Track". At 
best, this should be Informational in the same way that 4949 is informational.


Neither of these RFCs creates a registry. As such, I don't see the need for 
the registry described in Section 3. If a registry is really needed, it would 
be helpful to include text that describes why the registry is needed. If a 
case can be made for the registry I'm also confused by the initial assignment 
described in Section 3.2. It includes a data element "Name", with a reference 
to Section 2.1 of the draft, but there is no data element "Name" in Section 
2.1.


Scott
___
regext mailing list
regext@ietf.org 
https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
 






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

Re: [regext] WGLC: draft-ietf-regext-datadictionary-03

2023-02-14 Thread Steve Crocker 
James, Scott, et al,

The motivation for this proposal was to have a registry of available data
elements for everyone who is managing an Internet based registration system
to draw upon.  An informational RFC would be a way to communicate the idea
of having such a registry but would not actually cause one to come into
existence.

At present, each registration system defines its own terms.  There is a
huge amount of overlap in terminology and meaning.  The point of having a
registry of terms is to eliminate or reduce duplication.  The existence of
a registry of available data elements does *not* mean that every registry
has to use all of the data elements.

Thanks,

Steve


On Tue, Feb 14, 2023 at 11:02 AM Gould, James  wrote:

> I agree with Scott's feedback on the track being changed to Informational
> and removal of the IANA Registry.
>
> Why doesn't this draft match the approach taken io RFC 8499 for DNS
> Terminology?  The Registration System terms can certainly have overlap with
> the DNS terms in RFC 8499, where the RFC 8499 reference can be made, but
> the definition is catered to registration systems.  I see value with the
> terms in RFC 8499 for reference within drafts.  I would like to see the
> same value of terms defined in draft-ietf-regext-datadictionary.  The term
> definitions need to have adequate detail with relevant references made to
> the registration RFCs (e.g., RFC 5730 - 5733. 9022), which is not currently
> the case.  My recommendation is to refer to this as Registration
> Terminology instead of Registration Data Dictionary, following the approach
> taken in RFC 8499 for DNS terminology, and removing the definition of an
> IANA registry.
>
> Thanks,
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> On 2/14/23, 8:14 AM, "regext on behalf of Hollenbeck, Scott" <
> regext-boun...@ietf.org  on behalf of
> shollenbeck=40verisign@dmarc.ietf.org  40verisign@dmarc.ietf.org>> wrote:
>
>
>
> I'm aware of two other RFCs that also define terms like this: 4949
> (security)
> and 8499 (DNS). The intended status for this draft is "Standards Track".
> At
> best, this should be Informational in the same way that 4949 is
> informational.
>
>
> Neither of these RFCs creates a registry. As such, I don't see the need
> for
> the registry described in Section 3. If a registry is really needed, it
> would
> be helpful to include text that describes why the registry is needed. If a
> case can be made for the registry I'm also confused by the initial
> assignment
> described in Section 3.2. It includes a data element "Name", with a
> reference
> to Section 2.1 of the draft, but there is no data element "Name" in
> Section
> 2.1.
>
>
> Scott
> ___
> regext mailing list
> regext@ietf.org 
>
> https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> <
> https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> >
>
>
>
>
>
> ___
> 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] WGLC: draft-ietf-regext-datadictionary-03

2023-02-14 Thread Hollenbeck, Scott 
Steve, if the draft gives IANA instructions to create a registry, that’ll 
happen if the IESG approves the draft for publication as an RFC. The fact that 
it’s Informational won’t mean that IANA can’t do it. There is no “protocol” in 
the draft. As such, Standards Track makes no sense.



As I said earlier, though, the IETF has RFC precedents for data dictionaries 
where no IANA registry was needed or used. If the draft is going to deviate 
from existing practice, it needs to explain why that deviation is necessary. It 
doesn’t currently do that. Your note below could be a good starting point for 
text to be added to the draft.



Scott



From: Steve Crocker 
Sent: Tuesday, February 14, 2023 11:11 AM
To: Gould, James ; Hollenbeck, Scott 

Cc: regext@ietf.org; Steve Crocker 
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-datadictionary-03



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.

James, Scott, et al,



The motivation for this proposal was to have a registry of available data 
elements for everyone who is managing an Internet based registration system to 
draw upon.  An informational RFC would be a way to communicate the idea of 
having such a registry but would not actually cause one to come into existence.



At present, each registration system defines its own terms.  There is a huge 
amount of overlap in terminology and meaning.  The point of having a registry 
of terms is to eliminate or reduce duplication.  The existence of a registry of 
available data elements does not mean that every registry has to use all of the 
data elements.



Thanks,



Steve





On Tue, Feb 14, 2023 at 11:02 AM Gould, James 
mailto:40verisign@dmarc.ietf.org>> 
wrote:

   I agree with Scott's feedback on the track being changed to Informational 
and removal of the IANA Registry.

   Why doesn't this draft match the approach taken io RFC 8499 for DNS 
Terminology?  The Registration System terms can certainly have overlap with the 
DNS terms in RFC 8499, where the RFC 8499 reference can be made, but the 
definition is catered to registration systems.  I see value with the terms in 
RFC 8499 for reference within drafts.  I would like to see the same value of 
terms defined in draft-ietf-regext-datadictionary.  The term definitions need 
to have adequate detail with relevant references made to the registration RFCs 
(e.g., RFC 5730 - 5733. 9022), which is not currently the case.  My 
recommendation is to refer to this as Registration Terminology instead of 
Registration Data Dictionary, following the approach taken in RFC 8499 for DNS 
terminology, and removing the definition of an IANA registry.

   Thanks,

   --

   JG



   James Gould
   Fellow Engineer
   jgo...@verisign.com 


   703-948-3271
   12061 Bluemont Way
   Reston, VA 20190

   Verisign.com 
>



   On 2/14/23, 8:14 AM, "regext on behalf of Hollenbeck, Scott" 
mailto:regext-boun...@ietf.org> 
> on behalf of 
shollenbeck=40verisign@dmarc.ietf.org 
>> 
wrote:



   I'm aware of two other RFCs that also define terms like this: 4949 (security)
   and 8499 (DNS). The intended status for this draft is "Standards Track". At
   best, this should be Informational in the same way that 4949 is 
informational.


   Neither of these RFCs creates a registry. As such, I don't see the need for
   the registry described in Section 3. If a registry is really needed, it would
   be helpful to include text that describes why the registry is needed. If a
   case can be made for the registry I'm also confused by the initial assignment
   described in Section 3.2. It includes a data element "Name", with a reference
   to Section 2.1 of the draft, but there is no data element "Name" in Section
   2.1.


   Scott
   ___
   regext mailing list
   regext@ietf.org 
>
   
https://secure-web.cisco.com/10SGxJBThV6gF8vGi29LMAG0uFCn7qADz6eT8eDTTlNAx_2KL71rgw3tMxntmZ5RctPZjdp27W5frUo1bODZofGGp4FPUXU8ouuO-i3fIHQP26EwvVN4ZV71j3mHTuQ5CQVxI5Hvt_vLF9yy1NA6uRbEn9CNh9PyU_Y3abI0S6d9P1RNDE1FtTGvFoDVbBLlbJpHOAjQTez90BbpcXsi7foA2QSVoBihLvpeTn_CXnigFFQcn5B6pk83GufTYTMcDe8w3D2uJzC1LIsWogLhn6mw9dbtvff0VA0_bo4SN8U0zFTFGdVfFvCu3oTcIU5nA/https%3A%2F%2Fwww.

[regext] I-D Action: draft-ietf-regext-rdap-rir-search-00.txt

2023-02-14 Thread 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   : RDAP RIR Search
Authors : Tom Harrison
  Jasdip Singh
  Filename: draft-ietf-regext-rdap-rir-search-00.txt
  Pages   : 8
  Date: 2023-02-14

Abstract:
   The Registration Data Access Protocol (RDAP) is used by Regional
   Internet Registries (RIRs) and Domain Name Registries (DNRs) to
   provide access to their resource registration information.  The core
   specifications for RDAP define basic search functionality, but there
   are various IP and ASN-related search options provided by RIRs via
   their Whois services for which there is no corresponding RDAP
   functionality.  This document extends RDAP to support those search
   options.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-00


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