[regext] The REGEXT WG has placed draft-loffredo-regext-rdap-jcard-deprecation in state "Candidate for WG Adoption"

[IETF Secretariat]

The REGEXT WG has placed draft-loffredo-regext-rdap-jcard-deprecation in state
Candidate for WG Adoption (entered by James Galvin)

The document is available at
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/


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

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Patrick Mevzek]

On Tue, Oct 27, 2020, at 10:55, Thomas Corte wrote:
> If a registry really wants registrars to understand and process their
> custom poll messages, it can still resort to simply reject the 
> command if it doesn't contain the namespace in question.

That would certainly have my preference and it has one big bonus attached to it:
no need of any change in the protocol, no need of any new extension/namespace,
no need of any new specification.

Sometimes the best solutions are not the technical ones.

And it is not so much a stretch: many, but not all, registries mandate a
"technical accreditation" at the beginning of the relationship with a given 
registrar.
Adding a requirement there to support some namespaces is not a big change
(a registrar is free of course to signal it during login and then just ignore
those messages if he wants to ignore them, but then the responsibility clearly
falls on his end and he is in control of his fate because he signaled the 
namespaces
at login, without the registry forcing delivery to it of messages with "dubious"
validity per RFC 5730).

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

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

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Gould, James]

Patrick,

Do you mean it's better to fail the login if the client doesn't support all of 
the possible EPP extensions supported by the poll queue?  I view that option as 
being highly impactful to the clients and it would morph a certain set of 
services as required by the client at login, which does not currently exist in 
EPP.  The approach taken in draft-ietf-regext-unhandled-namespaces will not 
impact clients at login, will not cause a poison message in the poll queue, 
provides an indication that an extension is not supported, and provides the 
extension to the client in a protocol compliant manner for later processing if 
desired.  

There has been no indication from the working group of a technical risk with 
implementing draft-ietf-regext-unhandled-namespaces.  I agreed to add text to 
explicitly state that draft-ietf-regext-unhandled-namespaces extends the use of 
the  element within section 3 "Use of EPP  for Unhandled 
Namespace Data", and to add an Implementation Considerations section to cover 
the recommendation of client and server monitoring to mitigate a client 
ignoring content returned by the server.

-- 
 
JG



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


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

Verisign.com 

On 11/2/20, 10:16 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Tue, Oct 27, 2020, at 10:55, Thomas Corte wrote:
> If a registry really wants registrars to understand and process their
> custom poll messages, it can still resort to simply reject the 
> command if it doesn't contain the namespace in question.

That would certainly have my preference and it has one big bonus attached 
to it:
no need of any change in the protocol, no need of any new 
extension/namespace,
no need of any new specification.

Sometimes the best solutions are not the technical ones.

And it is not so much a stretch: many, but not all, registries mandate a
"technical accreditation" at the beginning of the relationship with a given 
registrar.
Adding a requirement there to support some namespaces is not a big change
(a registrar is free of course to signal it during login and then just 
ignore
those messages if he wants to ignore them, but then the responsibility 
clearly
falls on his end and he is in control of his fate because he signaled the 
namespaces
at login, without the registry forcing delivery to it of messages with 
"dubious"
validity per RFC 5730).

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

___
regext mailing list
regext@ietf.org

https://secure-web.cisco.com/1E73rcs2l3iOpYDTtf4HlaAiULSq3R3UdqpRjAi55QTW-RXUeEqWrgJtJdDriw22K3nr_pIqXo325kguNJzfXgsWVhWpk0DOwWVtdVTf30Hn82dNXT4Z2n97-z9SnE-ijPC04qfQvvCuEAh1sYF37hFY24wfhhiHkw-4M52Qtd4y_nwedk3GWSHBTay1c-esqKc8GULE6Gbg-FftXmkyWGwsB_2u9YIo962MahDtgLBC-cfmAE1pB3G4x_UfFpQW2Ma4oLvOL4HgbKxIQ5xD4Q915Y9uxCivhZWiAE36XUuw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


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

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Patrick Mevzek]

On Mon, Nov 2, 2020, at 10:42, Gould, James wrote:
> Do you mean it's better to fail the login if the client doesn't support 
> all of the possible EPP extensions supported by the poll queue?

Between this and the specification as currently presented, I prefer the login 
failure,
yes.

No option is perfect, each is a compromise.

> I view that option as being highly impactful to the clients

If a sudden change by a registry, without formal agreement by the registrar at 
login,
start to make it not follow RFC 5730 anymore, I think this is also very 
impactful to
the clients.

> and provides the 
> extension to the client in a protocol compliant manner for later 
> processing if desired.  

I disagree with the "protocol compliant manner". You redefine RFC 5730 at least 
twice.

> There has been no indication from the working group of a technical risk 
> with implementing draft-ietf-regext-unhandled-namespaces. 

This is incorrect. I indicated 2 points where the draft redefines what is in
RFC 5730.
This is a technical risk.

As any risk, no matter how big it can be, one has of course to judge the 
probability
of it happening, and the consequences if it happens. Based on that, the risk
can be considered "not worth to address". It doesn't mean it doesn't exist
or can't come back later under different circumstances, just that based on
current circumstances the probability or the consequences are considered
low/small enough that one decides to just go over that risk.

It may not happen, or not happen yet, from one registry reporting on the list
(thanks Mario for the data), but the fact that it was not seen does not mean
the risk does not exist.

I guess we will see later, when/if the extension gets deployed by other 
registries.

>I agreed to add text to explicitly state that 
>draft-ietf-regext-unhandled-namespaces extends the use of the  
>element within section 3 "Use of EPP  for Unhandled Namespace Data", 
>and to add an Implementation Considerations section to cover the 
>recommendation of client and server monitoring to mitigate a client ignoring 
>content returned by the server.

Thanks for that, could help... those reading this specification.
Now take into account anyone having written an EPP client in the past, based
on the specifications in the past, so RFC 5730 and siblings, and not aware AT 
ALL
of your new specification. You may see it should be announced in advance by 
registries,
but in practice that does not happen always (changePoll was introduced by some 
for example
without notifications), and even so, it can still happen some people won't be 
aware
of the change.
That is exactly the risk, because the change is not 100% aligned with what was
in past specifications.

As I said already I don't think there is pretty much anything else/again to 
discuss.
The consensus is clear considering the silent majority, so the process part has 
been
covered, let's go forward.

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

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

[regext] I-D Action: draft-ietf-regext-simple-registration-reporting-02.txt

[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   : Simple Registration Reporting
Authors : Joseph Yee
  James Galvin
Filename: draft-ietf-regext-simple-registration-reporting-02.txt
Pages   : 33
Date: 2020-11-02

Abstract:
   Domain name registries and registrars report to each other by sharing
   bulk information through files.  This document creates two IANA
   registries to establish a standard reporting mechanism between domain
   name registries and registrars.  The first IANA registry lists
   standard data elements and their syntax for inclusion in the files.
   The second IANA registry lists standard reports based on the standard
   data elements.  Each report is a file formatted as a CSV file.  The
   advantage of this reporting mechanism is that report, each file, can
   be imported by recipients without any prior knowledge of their
   contents, although reporting is enhanced with a minimum of knowledge
   about the files.  The mechanism for the transmission and reception of
   the files is a matter of local policy.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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