Re: [regext] EPP Transport Service Discovery

[Steve Crocker]

Scott, et al,

This seems to me an excellent idea, but let me suggest adding a bit more
content.

And before doing so, let me acknowledge that a registry will likely inform
its registrars well in advance of any changes and will likely provide a
test system for registers to use in advance of a cutover to a new transport
system.  But rather than depending on this alone, an automated process for
discovering the transport will be very helpful.

And now for the added content:

If a registry upgrades to a new transport method, it will likely operate
both the old and new transport for a period of time.  Indeed, it might even
support three or more transport methods during some periods.  Accordingly,
the response to a service discovery query will likely contain multiple
answers.  Each answer should also include a flag indicating whether it is a
preferred method.

But wait, there's more.

Each transport method will go through a lifecycle.  The transport method
lifecycle has the following states.

A. Announcement that the method will be supported in the future.
(Including the anticipated date is a good idea, but the date should be
interpreted as a guess, not a certainty.)

B. Announcement that the method is now supported.  Include the date it
became supported.  (A transport method in this state is "preferred."  There
should be at least one method in this state, but there could be more than
one.)

C. Announcement that the method that has been supported is scheduled to be
removed.  Include the estimated date of removal.  This will serve as notice
that any registrar still using the transport should move to another
available method that has reached state B.  (And, of course, there should
indeed already be at least one method in state B.)

D. Announcement that the method will become unavailable on a specific
date.  (All use of a method in this state should have ceased.  However, if
the method is still in use by a registrar, it will work.  The registry's
system or other monitoring systems can take note and escalate attention to
the appropriate managers,)

E. Removal of the transport method from the set of answers.

Extension of the proposal to include these states is easy.  Just add a flag
to indicate whether the transport method is in state A, B, C or D, and
include the date.

Comments?

Steve


On Tue, Mar 19, 2024 at 7:11 PM Hollenbeck, Scott  wrote:

> As noted during this morning’s regext session, we need to consider how a
> client can discover the transport services provided by an EPP server.
> Opportunistic probing is one method, another is server capability
> publication using something like an SVCB record that’s published in a DNS
> zone maintained by the EPP server operator. Perhaps something like this:
>
>
>
> epp.example.net.  7200  IN SVCB 3 epp.example.net. (
>
>alpn="bar" port="700" transport="tcp")
>
>
>
> There is no “transport” SvcParamKey currently registered with IANA, but
> that’s easy to do. I think there’s a draft here that needs to be written.
>
>
>
> Scott
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]

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

Re: [regext] Verified Email

[Steve Crocker]

I doubt the bot knows about RFCs :)Sent from my iPhoneOn Mar 15, 2024, at 4:05 PM, George Michaelson  wrote:Is this spam? How would we know that Steve's inbox hasn't been overtaken by a bot?GOn Fri, 15 Mar 2024, 8:13 pm Steve Crocker, <st...@shinkuro.com> wrote:Hi regext@ietf.org,I’ve been using a new tool called Verified Email. It runs in my inbox and shows me who’s a real person — saves time and reduces spam.
Thought you might find it useful. Here’s my invite link if you want to try it.
Steve
Sent by a Verified






  sender
___
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] Verified Email

[Steve Crocker]

Hi regext@ietf.org,

I’ve been using a new tool called Verified Email
.
It runs in my inbox and shows me who’s a real person — saves time and
reduces spam.

Thought you might find it useful. Here’s my invite link

if you want to try it.

Steve

Sent by a Verified
[image: Sent by a Verified sender]

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

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

[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] 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] CALL FOR ADOPTION: draft-flanagan-regext-datadictionary

[Steve Crocker]

Stephane, Michele, et al,

Thanks for your comments.  We're looking forward to adjusting the
descriptions, removing any policy bias, etc., etc.  We were advised to wait
until the WG adoption decision has been made, hopefully fairly soon.

Steve


On Tue, Jan 4, 2022 at 5:23 AM Michele Neylon - Blacknight  wrote:

> This draft seems to be rather confused about what its purpose is.
>
> As others have pointed out it talks about “DNS”, but in reality its focus
> seems to be on domain names and their registrants.
>
> It says it’s merely a “dictionary” but then goes on to make very clear
> policy decisions eg. 2.30
>
> It also includes terms that are not in anyway standard as if they were eg.
> 2.8, 2.9, 2.11
>
>
>
> Regards
>
>
>
> Michele
>
>
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> https://www.blacknight.com/
>
> https://blacknight.blog/
>
> Intl. +353 (0) 59  9183072
>
> Direct Dial: +353 (0)59 9183090
>
> Personal blog: https://michele.blog/
>
> Some thoughts: https://ceo.hosting/
>
> ---
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845
>
>
>
>
>
> *From: *regext  on behalf of James Galvin <
> gal...@elistx.com>
> *Date: *Monday, 20 December 2021 at 14:28
> *To: *Registration Protocols Extensions 
> *Subject: *[regext] CALL FOR ADOPTION:
> draft-flanagan-regext-datadictionary
>
> [EXTERNAL EMAIL] Please use caution when opening attachments from
> unrecognised sources.
>
> This is the formal adoption request for DNS Data Dictionary:
>
>
> https://datatracker.ietf.org/doc/draft-flanagan-regext-datadictionary/
>
> Please review this draft to see if you think it is suitable for adoption
> by REGEXT and comment to the list, clearly stating your view.
>
> This Call For Adoption will close on Monday, 10 January.
>
> If there are no objections, the chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Antoin and Jim
>
> ___
> 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] Request to adopt draft-flanagan-regext-datadictionary-01

[Steve Crocker]

George,

Thanks for your thoughtful comments.  I look forward to responses from others.  
I’m certainly open to changes that improve clarity and/or usability.

Steve

Sent from my iPhone

> On Dec 19, 2021, at 9:42 PM, George Michaelson  wrote:
> 
> I think this work is worth pursuing. But with a couple of caveats.
> 
> 1) it's hard to change the wider community around "normative language"
> and so we have to set realistic goals for actually moving the marker
> in the wider community to what words people use. That doesn't mean it
> isn't worth being clear, but it would have to be taken as read people
> will continue to expect to use other language. Lets document terms but
> not expect there to be agreement in the wide to use them?
> 
> 2) some marginalia in how the RIRs discuss things is hyper specific to
> one RIR even if the concept is similar in another RIR. The term "Local
> Internet Registry" or LIR really only has specific meaning in the RIPE
> region even if we all use it from time to time. The Term NIR only has
> specific meaning in APNIC, bound into how we structure. The analogous
> concept in the LACNIC region is really not identical. And, concepts
> like "portable" and "non-portable" addresses, PI/PI,
> Assignment/Allocation are not always well understood. I have some
> concerns these kinds of things will cause problems, and like cases
> exist inside the domain-registry world. I admit that from time to time
> I struggle with some nuances in "Registrar lock" -was it something I
> chose, or something done to me against my will (for instance)
> 
> I agree with Jiankang that the similarity to the DNS terminology draft
> is unfortunate. I would stick to registration, distinct from DNS.
> REGEXT is about more than DNS registry, so the ontology here has to be
> about more than DNS too.
> 
> What would it do to charter? Does it require consideration against
> charter goals?
> 
> What would it do to the RDAP/EPP pace of work? This work spans both. I
> continue to find the pace of document movement between the two
> sub-classes confusing. This adds to the confusion perhaps?
> 
> cheers
> 
> -george
> 
> ___
> 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] Request to adopt draft-flanagan-regext-datadictionary-01

[Steve Crocker]

We request the REGEXT WG adopt draft-flanagan-regext-datadictionary-01 as a
work item.  The goal is to establish a IANA registry of data elements that
are commonly used in multiple applications that handle registration data.

We anticipate this dictionary will be overseen by an IESG-appointed set of
experts.  The existence of this dictionary will not impose any requirements
that all of these data elements will be collected nor that any particular
set of these will be made available in response to requests.  Rather, the
intent here is simply to provide a common list of possible data elements
and a publicly visible set of names for the data elements.

We expect there will be additions to the dictionary, so the list of data
elements in the current draft is most likely not complete.  That said, we
feel it is useful to move forward with the review and adoption process.  If
and when other data elements are proposed, they can be included through the
usual process.

Thank you,

Heather Flanagan
Steve Crocker
Edgemoor Research Institute
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Reminder: Call for agenda items IETF 112

[Steve Crocker]

We request time on the agenda to introduce draft-flanagan-regext-datadictionary
and request the WG consider it for adoption.  This I-D proposes
standardization of a dictionary of data elements related to DNS
registrations.  The data dictionary is a building block for multiple
applications, including EPP, RDAP and others.  It will be useful and
inclusive for country code top level domains, generic top level domains and
the address community.  We propose additions to the dictionary be overseen
by an IETF-appointed group of experts, as is usual.

Thanks,

Steve Crocker






On Mon, Oct 18, 2021 at 9:37 AM Antoin Verschuren  wrote:

> Hi All,
>
> As you may have seen, we have a one hour meeting slot for IETF 112 on
> Wednesday November 10th, 14:30 UTC.
> Our preliminary agenda is due next week, and so far we only have 1 author
> (Jody) to talk about existing work.
> Can the other authors please indicate if they need time on our agenda?
> We may also have some time on our agenda left for new work.
> Please let the chairs know if you want some time on the agenda before next
> week.
>
> Regards,
>
> Jim and Antoin
>
>
>
> Op 13 sep. 2021, om 15:19 heeft Antoin Verschuren  het
> volgende geschreven:
>
> Hi All,
>
> Ii’s time already to think about agenda items for IETF 112.
> The deadline for requesting a meeting slot will be next week.
> Jim and I are thinking to request a same one hour time slot as last IETF
> 111 meeting, unless we get a lot of requests from you for new work.
>
> If you intend to request for a presentation, please let the chairs know.
>
> 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