[regext] About conformance to RFC 8521

[Stephane Bortzmeyer]

While RFC 8521 says "RDAP responses that contain values described in
this document MUST indicate conformance with this specification by
including an rdapConformance [RFC7483] value of
"rdap_objectTag_level_0", it is funny to note that apparently not one
of the registries under

does it :-)

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

Re: [regext] [EPP] Several commands under the same

[Stephane Bortzmeyer]

On Thu, Oct 20, 2022 at 07:52:48AM -0400,
 Marc Blanchet  wrote 
 a message of 33 lines which said:

> An example of such tool is xmllint —schema $schemafile  $inputFile
> . Xmllint is pretty available in any distribution.

Using James Gould's example:

%  xmllint --noout --schema wrapper.xsd epp.xml
epp.xml:25: element update: Schemas validity error : Element 
'{urn:ietf:params:xml:ns:epp-1.0}update': This element is not expected. 
Expected is one of ( {urn:ietf:params:xml:ns:epp-1.0}extension, 
{urn:ietf:params:xml:ns:epp-1.0}clTRID ).
epp.xml fails to validate

So, thanks to all, I have now ammunition to use with the client :-)

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

[regext] [EPP] Several commands under the same

[Stephane Bortzmeyer]

We got a message from a registrar saying that having several commands
under an  element is legal:


  

   ...


   ...

and that "it works with all the other registries".

XML schema is difficult to read but RFC 5730, section 2.5 uses the
singular to talk about the command. So, my opinoion is that the
registrar is wrong. Advices?

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

Re: [regext] CALL FOR ADOPTION: draft-flanagan-regext-datadictionary

[Stephane Bortzmeyer]

On Mon, Dec 20, 2021 at 09:27:43AM -0500,
 James Galvin  wrote 
 a message of 18 lines which said:

> This is the formal adoption request for DNS Data Dictionary:
> 
>   https://datatracker.ietf.org/doc/draft-flanagan-regext-datadictionary/

OK for adoption, since this is a real issue and this draft is a good
starting point. But I share George Michaelson's concerns: many words
are very policy-loaded and it can be difficult to capture a standard
definition for them. Also, I agree that the title should refer to
domain names, not the DNS protocol (see draft-lewis-domain-names).

Also:

> This is the domain name in an EPP [RFC5731] domain object 

I see no reason to refer to EPP (domain names existed long before EPP).

> and it MUST be in A-Label format.

Why? The international version (U-label) seems more inclusive.

> Individual names MAY be provided in either UTF-8 [RFC3629] or a
> subset of UTF-8 that can be represented in 7-bit ASCII,

Is the goal to describe semantics of a data element or also to specify
its syntax? (In the last case, we need to specify the Unicode
normalisation.)

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

Re: [regext] Registration Protocols Extensions (regext) WG Virtual Meeting: 2021-10-20 CHANGED

[Stephane Bortzmeyer]

On Fri, Nov 05, 2021 at 02:32:17PM -0700,
 IESG Secretary  wrote 
 a message of 44 lines which said:

> The Registration Protocols Extensions (regext) WG will hold
> a virtual interim meeting on 2021-10-20 from 14:00 to 15:00 UTC.
...
> Please find below the call details for the Joint IETF REGEXT and CPH TechOps 
> meeting on Wednesday, 20 October 2021 at 14:00 UTC for 60 minutes.

Sent on 2021-11-08.

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

[regext] [check] always prohibited when avail="1" ?

[Stephane Bortzmeyer]

RFC 5731 3.1.1 seems to clearly prevent a  to be sent when
avail="1".

But RFC 9095 6.1.1 has an example with a  for avail="1".

So, is it really forbidden to send a  to the client when the
domain is available but you want to send some extra conditions?

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

Re: [regext] Last Call: (Registration Data Access Protocol (RDAP) Partial Response) to Proposed Standard

[Stephane Bortzmeyer]

On Tue, Jul 28, 2020 at 12:10:21PM +0200,
 Mario Loffredo  wrote 
 a message of 35 lines which said:

> the .it RDAP server provides searches only to authenticated users.

Yes, but I was interested in the test bed (which hosts only a subset
of the data). Also closed?

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

Re: [regext] Last Call: (Registration Data Access Protocol (RDAP) Partial Response) to Proposed Standard

[Stephane Bortzmeyer]

On Fri, Jul 24, 2020 at 12:01:59PM -0700,
 The IESG  wrote 
 a message of 42 lines which said:

> The IESG has received a request from the Registration Protocols Extensions WG
> (regext) to consider the following document: - 'Registration Data Access
> Protocol (RDAP) Partial Response'
>as Proposed Standard

In section 7.1, a test bed is mentioned, but it is not publically available:

% curl  https://rdap.pubtest.nic.it/domains\?name=nic.it
{"errorCode":401,"title":"Unauthenticated users are not allowed to
submit the query"}

(Same answer for all variations under /domains. /domain works.)

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

[regext] [RDAP] rdapConformance mandatory?

[Stephane Bortzmeyer]

I've found a RDAP client which crashes, apparently when there is no
rdapConformance in the answer.

RFC 7483 seems very liberal. It does not say that rdapConformance is
mandatory.

Any opinion, backed by chapter and verse of RFC 7483, about wether
this member is really necessary?

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

[regext] EPP and rate-limiting

[Stephane Bortzmeyer]

Sometimes, some clients are too talkative and, for instance, try
 too often to grab a domain. I'm not sure of the best error
code to return when such behaviour is detected. HTTP has 429 "Too Many
Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

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

Re: [regext] I-D Action: draft-harrison-regext-rdap-mirroring-00.txt

[Stephane Bortzmeyer]

On Fri, Feb 01, 2019 at 04:20:56AM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 44 lines which said:

> Title   : RDAP Mirroring Protocol (RMP)
> Authors : Tom Harrison
>   George G. Michaelson
>   Andrew Lee Newton
>   Filename: draft-harrison-regext-rdap-mirroring-00.txt

Since it is in the agenda of the WG this afternoon...

The Security Considerations are too weak. Unlike the RPKI (which was
the inspiration for this protocol), RDAP data may be
sensitive/personal. So, it requires a more thought-of privacy
analysis.

The current text just refers to RFC 7481, which do not seem to
consider bulk access. Mirroring all the data is very different from
having access for specific requests.

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

Re: [regext] IETF 101 agenda

[Stephane Bortzmeyer]

On Sat, Mar 10, 2018 at 04:26:18PM +0100,
 Antoin Verschuren  wrote 
 a message of 170 lines which said:

> Session II,  Regular WG meeting session.
> Wednesday 2018-03-21  15:20 - 16:50

> 6. AOB

draft-bortzmeyer-regext-epp-dname "EPP Mapping for DNAME delegation"
has now one implementation (client-side), I just published -02, with
only this added information.

If people want to discuss it during the WG meeting or outside of the
WG, I'm in London and be happy to talk.

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

Re: [regext] EPP and DNAME records, how to do it

[Stephane Bortzmeyer]

On Tue, Jan 16, 2018 at 08:38:59AM -0500,
 John R Levine  wrote 
 a message of 40 lines which said:

> New tiny zone on [abc].iana-servers.net:
> 
> evil. SOA whatever
> evil. NS a.iana-servers.net.
> evil. NS b.iana-servers.net.
> evil. NS c.iana-servers.net.
> evil. DNAME empty.as112.arpa.

OK, I see your point. Documented in an appendix in
draft-bortzmeyer-dname-root-05.txt as a possible alternative.

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

Re: [regext] EPP and DNAME records, second reason not to do it

[Stephane Bortzmeyer]

On Mon, Jan 15, 2018 at 01:19:54PM -0500,
 John R Levine  wrote 
 a message of 36 lines which said:

> in the root (add DNSSEC to taste):
> 
> ...
> evil. NS ns1.evilsrv.wtf.
> evil. NS ns2.evilsrv.wtf.

Does not work for the use case of draft-bortzmeyer-dname-root since
you cannot delegate new names to the old AS 112 (see RFC 7535 for the
rationale).

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

Re: [regext] first reason not to do EPP and DNAME records?

[Stephane Bortzmeyer]

On Mon, Jan 15, 2018 at 03:05:10PM -0500,
 John R Levine  wrote 
 a message of 64 lines which said:

> > In that light, we would need an EPP extension before IANA can
> > adopt a policy to allow DNAME in the root.
> 
> I don't understand why you think it would have to be in that order.

One of the annoying things at IETF is that there is no clear directive
on the order to do things which involve several stakeholders. At the
discussion in dnsop about draft-bortzmeyer-dname-root, Kim Davies
(IANA) suggested that it wasn't productive to discuss the policy part
of the project since there isn't even an EPP mapping for it. So, what
is the right order and who decides on it? (Personal advice: there is
no order, things are faster when done in parallel.)

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

Re: [regext] first reason not to do EPP and DNAME records?

[Stephane Bortzmeyer]

On Mon, Jan 15, 2018 at 07:31:54PM +,
 Ulrich Wisser  wrote 
 a message of 99 lines which said:

> IANA sends root updates to Verisign via EPP.  In that light, we
> would need an EPP extension before IANA can adopt a policy to allow
> DNAME in the root.

Yes. That's the entire point. (And it was said several times on this
list but some people don't read threads before replying.)

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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sun, Jan 14, 2018 at 02:31:37PM -0500,
 John Levine  wrote 
 a message of 38 lines which said:

> I continue to believe that allowing DNAMEs in TLDs is a bad idea,
> and so I see no reason to spend further effort on this extension.

Really, I do not understand, and I would appreciate explanations. The
original use case is not for DNAME in TLDs. So, whatever you think of
DNAME in TLDs does not mean the extension is useless.

> With respect to DNAMEs at the top level, someone else noted that the
> root zone isn't managed the same way as TLDs, so there's no obvious
> connection.

Already replied but see


> Since you can get the effect of a DNAME in the root zone by putting
> a DNAME at the apex of a TLD as Taiwan has done,

No, the goal here is to have no NS delegation (for reasons explained
in RFC 7535). So, this cannot work.

> it might be more productive to consider how to invent a policy to
> allow a DNAME-only TLD if you're not a ccTLD.

I'm not in policy, draft-bortzmeyer-dname-root and
draft-bortzmeyer-regext-epp-dname are purely technical.

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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sun, Jan 14, 2018 at 12:52:33AM +0100,
 Patrick Mevzek  wrote 
 a message of 17 lines which said:

> AFAIK there is no (not yet?) IANA EPP server to which TLD operators
> are clients,

Not between IANA and the TLD managers, but EPP is used between IANA
and Verisign


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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sat, Jan 06, 2018 at 08:01:02PM +0100,
 Patrick Mevzek  wrote 
 a message of 77 lines which said:

> * I have mixed feelings about section 10.
> Specifically you state:
> A trust relationship MUST exist between the EPP client and
>server, and provisioning of DNAME delegation MUST only be done after
>the identities of both parties have been confirmed using a strong
>authentication mechanism.
> 
> Does that mean that provisions in RFC5734 (specifically section 8) are not 
> enough to provide that?

I don't have a strong opinion here. Should the draft be adopted, I
would be happy to defer to the WG decision. In the mean time, I see no
harm in repeating this. Many RFC have security considerations sections
which are as surprising as "remember that water is wet and fire is
hot".

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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sun, Jan 07, 2018 at 08:26:46AM -0500,
 John Levine  wrote 
 a message of 20 lines which said:

> It can coexist with anything other than CNAME, NS/DS, or another
> DNAME, and you need A, , and MX records at the DNAME to do what
> many people wrongly believe that DNAME does.  See RFC 6672, sec 2.4.

You're right, of course. Sorry for the mistake. It may be because I
thought of only one use case (see below).

> Not to be oversnarky, but I'd want a field to upload a picture of
> the user shooting himself in the foot to demonstrate that he
> understands what DNAMEs will do.

Right. Warnings added


> I assume I missed a discussion of what problem this solves -- is it
> in the list archives?

Yes. Added to the future version of the draft but, basically, it is
draft-bortzmeyer-dname-root. Some people remarked that we don't even
have an EPP mapping for DNAME. It is not the biggest obstacle to
draft-bortzmeyer-dname-root but this new draft
draft-bortzmeyer-regext-epp-dname is an attempt to lift it.

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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Fri, Jan 05, 2018 at 03:46:28PM +,
 Gould, James  wrote 
 a message of 72 lines which said:

> Thanks for posting the draft for review.

And thanks for the detailed review.

> The following is my initial feedback:

Most of it has been incorporated

and will appear in -01. However:

> 1. If the registry starts accepting more resource record types in
> addition to or as an alternative to the existing record types, why
> not define a more generic RR extension that allows for the CRUD of
> the RR associated with a domain name?

Clearly, this is out-of-scope for me. The goal of this document is not
to allow arbitrary DNS Resource record types (such as TXT or
LOC). Such a mapping would allow the EPP server to implement a
"delegation-less" registry, letting the client add A, , etc
records. It would require more complexity, with the various RR
formats, and the ability to add, update and remove individual records
(RFC 5910 style)

Instead, I keep the idea that the EPP server registers only
delegations, either through NS records or, as here, a DNAME
record. This keeps the mapping much simpler.

> a. DNAME could be one of the supported RR types.

DNAME, like NS, is special. It cannot coexist with other records, for
instance.

> c. It would be up to server policy which RR types are supported.  A
> RR policy extension of the Registry Mapping could be leveraged to
> define the RR types supported by the server along with any RR
> restrictions.

Nice idea but clearly much more work. For someone braver than me :-)

> 2. It would be best to reference eppcom:labelType for the
> dnameTarget element instead of a string.  

Great. Done. 

> 3. It may be best to make the setting or removing of the dname explicit in 
> the extension to the update command, as in the following
> 
>   foo.bar.example
> 

I hesitate. More advices welcome (see
)

> 4. I assume that return of the dnameDeleg extension in the info
> response would be based on the existence of the dnameDeleg data,
> server policy, and support of the client for dnameDeleg based on the
> EPP login services provided by the client.

Yes (-00 did not mention the EPP login services. Added.)

> a. An alternative to leveraging the EPP login services of the
> client, is to extend the EPP info command with an empty element like
>  to explicitly specify the inclusion of the
> dnameDeleg extension in the response.

https://framagit.org/bortzmeyer/ietf-epp-dname/issues/6

> 5. For issue #3 listed at
> https://framagit.org/bortzmeyer/ietf-epp-dname/issues, I believe the
> client can determine support for DNAME via the services returned in
> the EPP greeting by the server.

No, because it is only the general support by the server, not the fact
it is accepted for all domain names. 1) A server may handle two TLD,
with different policies 2) A server may allow DNAME for a given
subdomain (say, gov.example) but not for other names. So, the EPP
greeting is necessary but not sufficient.

> 6. One additional complexity is how to handle transfers when the
> gaining registrar does not support dnameDeleg.  There are other
> mechanisms to determine the state of the transferred domain (e.g.,
> DNS, reports), but the gaining registrar will simply not be able to
> get or set the dname via EPP until they support dnameDeleg.

Documented. (The obvious solution is for the transfer to fail. Note
that RFC 5910 is silent about that.)

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

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sun, Nov 12, 2017 at 09:00:06PM +0800,
 Stephane Bortzmeyer <bortzme...@nic.fr> wrote 
 a message of 19 lines which said:

> we could imagine a registry accepting registrations implemented as a
> DNAME record, not NS records.
> 
> Would it make sense to create an extension (may be an addition to RFC
> 5731) to allow these "DNAME registrations"?
> 
> I'll be at the meeting tomorrow, if you prefer to discuss it AFK.

After the discussion in Singapore, here is the draft. Comments and
criticisms are welcome.

https://datatracker.ietf.org/doc/draft-bortzmeyer-regext-epp-dname/

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

Re: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

[Stephane Bortzmeyer]

On Wed, Nov 29, 2017 at 10:03:39AM -0800,
 Alexey Melnikov  wrote 
 a message of 63 lines which said:

> Is there a registry for codes like 2306? Either way, I couldn't
> figure out if this is a new code or already assigned one.

No registry, but 2306 was created by RFC 5730, which is a normative
reference.


  2306"Parameter value policy error"

  This response code MUST be returned when a server receives
  a command containing a parameter value that is
  syntactically valid but semantically invalid due to local
  policy.  For example, the server can support a subset of a
  range of valid protocol parameter values.  The error value
  SHOULD be returned via a  element in the EPP
  response.

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

[regext] News of draft-ellacott-historical-rdap?

[Stephane Bortzmeyer]

draft-ellacott-historical-rdap seems cool and already has running code
at APNIC. But it is also dangerous, since you can no longer erase data
(it is mentioned in the Sceurity Considerations section).

It was briefly discussed at IETF 99 in Prague

but nothing on the list, and it expires in one month. Is there still
some interest?

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

Re: [regext] EPP and DNAME records?

['Stephane Bortzmeyer']

On Mon, Nov 13, 2017 at 02:26:00AM +,
 Feher, Kal  wrote 
 a message of 34 lines which said:

> certainly in breach of current gTLD requirements for zone contents.

There are not only ICANN-regulated registries. Besides the root (my
personal use case), there are ccTLD and also all the registries at
lower levels (they typically don't use EPP today but it may change).

Also, this is a technical proposal, independent of the _current_
policy. ICANN may accept DNAME in the future (they should).

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

Re: [regext] EPP and DNAME records?

['Stephane Bortzmeyer']

On Mon, Nov 13, 2017 at 01:52:26AM +,
 Feher, Kal  wrote 
 a message of 71 lines which said:

> Why wouldnt we have DNAME at the apex of the registered name? Ie
> controlled by the domain owner.

It would force the domain holder to have nameservers configured for
this name. It is always a hassle but, in the case of RFC 7535, it is
simply not possible.

> I may be missing something of the use case here.

My personal use case was RFC 7535 + draft-wkumari-dnsop-internal.

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

[regext] EPP and DNAME records?

[Stephane Bortzmeyer]

[This comes from a discussion in DNSOP about a possible future
.internal.]

Some TLD include DNAMEs (for instance .cat and .asia) but apparently
only as parts of an IDN bundle. Nevertheless, we could imagine a
registry accepting registrations implemented as a DNAME record, not NS
records.

There is apparently no way to do it in EPP.

Would it make sense to create an extension (may be an addition to RFC
5731) to allow these "DNAME registrations"?

I'll be at the meeting tomorrow, if you prefer to discuss it AFK.

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