Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Dmitry Belyavsky]

On Sat, Dec 18, 2021 at 2:53 PM Taras Heichenko 
wrote:

>
>
> > On 15 Dec 2021, at 16:14, Dmitry Belyavsky  wrote:
> >
> > Dear Taras.
>
> Dear Dmitry
>
> >
> > On Tue, Dec 14, 2021 at 8:13 PM Taras Heichenko 
> wrote:
> > The comment is in body.
> >
> > > On 13 Dec 2021, at 15:15, Hollenbeck, Scott  40verisign@dmarc.ietf.org> wrote:
> > >
> > >> -Original Message-
> > >> From: Gould, James 
> > >> Sent: Thursday, December 9, 2021 11:59 AM
> > >> To: Hollenbeck, Scott ;
> > >> ietf=40antoin...@dmarc.ietf.org ; regext@ietf.org
> > >> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL:
> draft-ietf-regext-epp-
> > >> eai-04
> > >>
> > >> 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.
> > >>
> > >> Scott,
> > >>
> > >> Thanks for the review and feedback.  I provide responses to your
> feedback
> > >> embedded below.
> > >>
> > >> --
> > >>
> > >> JG
> > >>
> > >>
> > >>
> > >> James Gould
> > >> Fellow Engineer
> > >> jgo...@verisign.com  > >> B4BA42740803/jgo...@verisign.com>
> > >>
> > >> 703-948-3271
> > >> 12061 Bluemont Way
> > >> Reston, VA 20190
> > >>
> > >> Verisign.com  > >> web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD
> > >> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0
> > >> 6ld-
> > >> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7
> > >> yUIN-
> > >> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b
> > >> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com%2F>
> > >>
> > >> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott"  > >> boun...@ietf.org on behalf of shollenbeck=
> 40verisign@dmarc.ietf.org>
> > >> wrote:
> > >>
> > >>
> > >>A few questions/comments:
> > >>
> > >>Section 6: We need to provide the rationale for that SHOULD
> (Registries
> > >> SHOULD validate the domain names in the provided email addresses).
> What
> > >> does "validate" mean? For syntax? For reachability?
> > >>
> > >> JG - This is associated with validating the syntax.  The goal is to
> ensure
> > >> that
> > >> the domain name, whether an ASCII or IDN domain name is a syntactic
> valid
> > >> domain name the may be reachable.  Would it help to modify this to
> read
> > >> "Registries SHOULD validate the syntax of the domain names in the
> provided
> > >> email addresses so they may be reachable."?
> > >
> > > [SAH] Syntax validity is no guarantee of reachability. The only way to
> confirm
> > > that an email address "works" is to send email to that address and
> confirm
> > > that it's delivered. I don't think we want to suggest that registries
> should
> > > start sending out email delivery tests, so maybe something like this
> instead:
> > >
> > > " Registries SHOULD ensure that the provided email addresses are
> syntactically
> > > valid to reduce the risk of future usability errors."
> >
> > The check of existing of the domain (MX or at least A/ record) from
> the
> > email address may be added. I am not sure that it should be there but it
> also
> > raises the probability that the email address is valid.
> >
> > Personally I don't think it is feasible to reject the contact
> registration/change if these records don't exist.
> > And anyway, it's out of scope for this document.
>
> I just wanted to say that there are different ways to check the validity
> of an email address.
> If some registry does such a check will it be contrary to the RFC? May we
> need a phrase that
> allows wider Interpretation?
>

I don't see it will be contrary, and so I don't think we need to specify
this in this document.
BTW, I've already removed the phrases about extra email limitations.


> >
> >
> > >
> > >>Section 7: What's significant about "eai-0.3"? The "0.3" part
> doesn't
> > >> track to
> > >> the current version of the draft; perhaps "1.0" would be better now.
> See
> > >> also
> > >> Section 5.2.
> > >>
> > >> JG - Yes, the namespace will be changed to "eai-1.0" once it passes
> WGLC
> > >> similar to what has happened in past EPP extensions with pointed
> > >> namespaces.
> > >
> > > [SAH] OK.
> > >
> > >>Section 8: It might be helpful to add more text to explain why
> > >> "Registries
> > >> MAY apply extra limitation to the email address syntax". Why might
> they
> > >> want to do that? It seems a little unusual to say that they MAY do
> > >> something,
> > >> but in the next sentence say, "These limitations are out of scope of
> this
> > >> document".
> > >>
> > >> JG - Agreed, this does not look to add value.  Do you believe the
> > >> Implementation Considerations section should be removed, since the
> > >> contents really don't provide any material considerations?
> > >
> > > [SAH] Yes, that's probably a good idea.
> > >
> > > Scott
> > > ___
> > > regext mailing list
> > > regext@ietf.org
> > > https://www.ietf.org/m

Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

[Jiankang Yao]

 Hello all,

  I agree with Tim's point. Support +1
 RFC8499 provides the DNS terminology, which provides a list of DNS protocol 
related terminology.
  This document can provide a neutral DNS Data Dictionary related to Domain 
name registered data. I think that it will be useful for registry, registrar 
and registrant.

 
One suggestion:
  RFC8499 is named with "DNS terminology" while this document is named with 
"DNS Data Dictionary".
  Just having a quick look at these two names, it seems it is not easy to 
distinguish between them.

  How about renaming "DNS Data Dictionary" to "DNS Registration Data 
Dictionary" or seome else?


Best Regard.



Jiankang Yao
 
From: Tim Wicinski
Date: 2021-12-19 10:36
To: regext
Subject: Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

REGEXT chairs

Please count this as my +1 for adopting this work. I find this highly relevant 
to not just create this dictionary, but offer precise definitions for terms to 
avoid any "squishness" which seems to come back to bite up when we least expect 
it.  The work in DNSOP on DNS Terminology is a good example of doing something 
a little dull provides benefits elsewhere.

Tim



On Sat, Dec 18, 2021 at 9:39 AM Steve Crocker  wrote:
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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

[George Michaelson]

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

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

Re: [regext] Request to adopt draft-flanagan-regext-datadictionary-01

[Patrick Mevzek]

On Sun, Dec 19, 2021, at 21:23, Jiankang Yao wrote:
>   How about renaming "DNS Data Dictionary" to "DNS Registration Data 
> Dictionary" or seome else?

You could even drop "DNS" from "DNS Registration Data Dictionary". 

First because even today by domain name registrars and registries, EPP/RDAP
are used for things that are not related to the DNS at all (ex: contacts).

Second because EPP was created as a generic provisioning protocol that
technically could handle things completely unrelated to domain names,
even if it is its only major public generic use.

-- 
  Patrick Mevzek
  p...@dotandco.com

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