Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

Patrick

To be clear the domain info response will be sent just without the DNSSec part. 
Therefore a not DNSSec interested registrar will just not see the DNSSec 
configuration but all the rest of the domain info resData. I don't see a 
problem with that.

In our case a registrar currently needs to be accredited by us (DNSEC_ENABLED) 
in order to successfully login with DNSSec extension configured and he will 
only be able to transfer a DNSSec domain to him if the configured DNSSec at 
login. 

In case he is DNSSec enabled but still logs in without this extension he will 
get a failure with error message similar to  “Not allowed to transfer DNSSec 
Domain” when trying to transfer a DNSSec domain to him.

So actually there is a way to know why it didn't work for him.

As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.

Martin 

Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek 
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 20:31
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login
> services defines what the server can return to the client, so if the
> client does not support the DNSSEC extension it is completely reasonable
> for the server not to return it.  If a client wants to see the DNSSEC
> information returned they should include the URI in their login
> services.

James, please, again, take into account some real life examples that happen 
today:

registries restrict the use of secDNS at login for only the registrars having 
passed
a specific accreditation test (trying to login with it without prior registry 
vetting triggers an authentication error, so the registrar can only do its 
business if it removes this extension from list at login)
thus, in your case (just removing the content), a registrar not wanting to do 
DNSSEC and not wanting to transfer
to him a currently DNSSEC-enabled domain will have no way to know that.

And saying to registrars: "then pass registry accreditation tests to be able to 
login with secDNS and see **others** domain names with secDNS data while you do 
not want to do any DNSSEC related stuff", is certainly not going to fly...

As long as we take into account only some cases and not others we will never be
able to deliver an extension used by multiple registries.
Also, before anything happen I will be very interested by intention of support
(which means deployment) from registries.

Otherwise, like I said, this problem exists since EPP started so it is not new,
and it seems the current status quo fits most of the player (due to the number 
of people
having participated here), so we are maybe devoting resources to trying to 
design
something perfect... that noone will then use :-(

--
  Patrick Mevzek

___
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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Jody Kolker]

Hi Martin,

<<
As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.
>>

How does DNSSEC data get configured by the DNS-Operator of a domain if the 
DNS-Operator is not the registrar?  Is the DNSSEC data set without the 
registrar knowing it was added?  If so, how?

Thanks,
Jody Kolker


-Original Message-
From: regext  On Behalf Of Martin Casanova
Sent: Monday, July 16, 2018 2:09 PM
To: Patrick Mevzek ; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Patrick

To be clear the domain info response will be sent just without the DNSSec part. 
Therefore a not DNSSec interested registrar will just not see the DNSSec 
configuration but all the rest of the domain info resData. I don't see a 
problem with that.

In our case a registrar currently needs to be accredited by us (DNSEC_ENABLED) 
in order to successfully login with DNSSec extension configured and he will 
only be able to transfer a DNSSec domain to him if the configured DNSSec at 
login. 

In case he is DNSSec enabled but still logs in without this extension he will 
get a failure with error message similar to  "Not allowed to transfer DNSSec 
Domain" when trying to transfer a DNSSec domain to him.

So actually there is a way to know why it didn't work for him.

As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.

Martin

Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek 
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 20:31
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login
> services defines what the server can return to the client, so if the 
> client does not support the DNSSEC extension it is completely 
> reasonable for the server not to return it.  If a client wants to see 
> the DNSSEC information returned they should include the URI in their 
> login services.

James, please, again, take into account some real life examples that happen 
today:

registries restrict the use of secDNS at login for only the registrars having 
passed a specific accreditation test (trying to login with it without prior 
registry vetting triggers an authentication error, so the registrar can only do 
its business if it removes this extension from list at login) thus, in your 
case (just removing the content), a registrar not wanting to do DNSSEC and not 
wanting to transfer to him a currently DNSSEC-enabled domain will have no way 
to know that.

And saying to registrars: "then pass registry accreditation tests to be able to 
login with secDNS and see **others** domain names with secDNS data while you do 
not want to do any DNSSEC related stuff", is certainly not going to fly...

As long as we take into account only some cases and not others we will never be 
able to deliver an extension used by multiple registries.
Also, before anything happen I will be very interested by intention of support 
(which means deployment) from registries.

Otherwise, like I said, this problem exists since EPP started so it is not new, 
and it seems the current status quo fits most of the player (due to the number 
of people having participated here), so we are maybe devoting resources to 
trying to design something perfect... that noone will then use :-(

--
  Patrick Mevzek

___
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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

See my comment below..


Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek 
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 21:32
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 21:08, Martin Casanova wrote:
> To be clear the domain info response will be sent just without the
> DNSSec part. Therefore a not DNSSec interested registrar will just not
> see the DNSSec configuration but all the rest of the domain info
> resData. I don't see a problem with that.

Here is the problem as already exposed: you may have registrars that do not 
want to deal
with DNSSEC on a philosophical principle. They may want to specifically not try 
to
transfer a currently DNSSEC enabled domain to them, because they know it will 
break
resolution and they do not want to handle the customer saying that they broke
the domain.

M: The Registrar does not need to check the domain with domain info in order to 
check if he is allowed to to do or not.
M: If he is not than we will prevent it (see next comment)

Besides using the DNS, in your case, this registrar has no way to know in 
advance
that the transfer will be a problem. And I suspect telling them 'Please be 
DNSSEC
accredited with us and login with secDNS extension' will fall on a deaf ear.

M: No we never told such a thing to a registrar. However we do put in the 
manual that a DNSSec Domain can only be transfered to a DNSSec enabled 
Registrar (up to now at least)

> In case he is DNSSec enabled but still logs in without this extension he
> will get a failure with error message similar to  “Not allowed to
> transfer DNSSec Domain” when trying to transfer a DNSSec domain to him.

What happens for a non-DNSSEC enabled registrar (and hence not using secDNS on 
login)
when he tries to transfer to him a DNSSEC-enabled domain?
Is this refused?

M: Exactly. Through the transitive relation that we prevent him to start a 
DNSSec enabled session and a non enabled session will never authorize an 
incoming transfer of a DNSSec domain.


Also to leave the discussion on track, this DNSSEC part of domain:info response 
was only
one example of the same problem ("unhandled namespaces") outside of the poll 
messages,
because I think the problem is global and we should tackle it globally (or not 
at all
and leave it at the current status quo).

M: Thats exactly what we should discuss in a minute :)


--
  Patrick Mevzek

Martin


___
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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

@Thoma Corte: Sorry if my formulation was not precise enough:

“The precondition of this approach is, that we actually can ask all registrars 
to prepare their clients to at least tolerate new poll messages and to update 
their business logic in order to process the newly given information properly 
if they wish to do so.” 

With this statement I wanted to support the   approach. No 
(validating) client will have a  technical problem receiving such a message 
regardless of what was configured at login. But as I was speaking to a 
registrar he told me: “So far you only sent me outgoing transfer poll messages 
and thats all my client is prepared for. ” So in our case we need to announce 
to registrars that they should build tolerant clients to be prepared to also 
receive unexpected poll messages with content in  eg. also low 
balance notifications in the future.. And that not every poll message will be 
automatically an outgoing transfer notification anymore.

@Patrick
In deed, for domain info requests on DNSSec domains we so far left out the 
DNSSec part in the domain info response if the client was not DNSSec enabled at 
login. In the future this content could also be transmitted in the . 
To me it falls also under the “unhandled namespace” problem.

Martin Casanova

Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek 
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 18:02
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which
> messages to accept
> will be outside the EPP protocol and this WG.

But please also remember that if we want to tackle this problem in a generic 
way (and also taking care of different servers and clients strategies regarding 
handling of namespaces and inline/offline parsing and use) it is not limited to 
a single extension (the thread started long ago with changePoll) nor in fact 
limited to poll messages.

Imagine registrar A wanting to request a transfer from registrar B. In some 
registries it means that regitrar A can do a domain:info on the domain, with 
the authInfo to get access to all details, and specifically the contacts.
But a domain can have a secDNS part in the domain:info reply.
What happens if the registrar A did not login with the secDNS extension (maybe 
this case does not exist in gTLDs where DNSSEC is mandatory but again we have 
other registries cases to take into account)?

Should the domain:info return an error? Return everything as is? Return 
everything but the secDNS part?

The last case is the worst to me: some registrars may like not to support 
DNSSEC at all (and hence will not log in at all, or you have other cases where 
registries mandate specific tests to be "DNSSEC" accredited so it may not even 
be possible to log in with secDNS extension even if the registrar would like 
to) but, and especially for this, being able to detect beforehand if some 
client is trying to transfer to them a domain using DNSSEC, that they would 
like to refuse transferring.


Of course the above is only one example with a domain:info and the secDNS 
extension but I am sure we can find others.

This illustrates I think the distinction I made in earlier messages and the 
different semantic I attach to extensions listed as login: for me they are 
those that the client announce it will use. Of course, it has no control over 
messages or objects he is not the origin or the sponsor, all cases where other 
namespaces may appear.


--
  Patrick Mevzek

___
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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Ulrich Wisser]

Hi,

are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two categories.
- do never poll
- poll and ignore anyway

I know that we have registrars who validate, but those usually support all
our extensions.

Could anybody produce numbers on registrars who do all three?
  1. poll
  2. validate
  3. do not support all extensions

/Ulrich





Martin Casanova  schrieb am Mo., 16. Juli 2018
um 15:09 Uhr:

> Patrick
>
> To be clear the domain info response will be sent just without the DNSSec
> part. Therefore a not DNSSec interested registrar will just not see the
> DNSSec configuration but all the rest of the domain info resData. I don't
> see a problem with that.
>
> In our case a registrar currently needs to be accredited by us
> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
> configured and he will only be able to transfer a DNSSec domain to him if
> the configured DNSSec at login.
>
> In case he is DNSSec enabled but still logs in without this extension he
> will get a failure with error message similar to  “Not allowed to transfer
> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>
> So actually there is a way to know why it didn't work for him.
>
> As a matter of fact we will have to over think this rule now because with
> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
> (which does not need to be the registrar) . So a domain of a non DNSSec
> accredited registrar could end up with  DNSSec data. In case he is DNSSec
> accredited he might be interested to keep his DNSSec Data synchronized with
> the data at the registry originated by CDS. That is exactly our use case
> where we want to use the change poll extension.
>
> Martin
> 
> Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick
> Mevzek [p...@dotandco.com]
> Gesendet: Montag, 16. Juli 2018 20:31
> An: regext@ietf.org
> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
> Action: draft-ietf-regext-change-poll-07.txt)
>
> On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> > I believe that the login
> > services defines what the server can return to the client, so if the
> > client does not support the DNSSEC extension it is completely reasonable
> > for the server not to return it.  If a client wants to see the DNSSEC
> > information returned they should include the URI in their login
> > services.
>
> James, please, again, take into account some real life examples that
> happen today:
>
> registries restrict the use of secDNS at login for only the registrars
> having passed
> a specific accreditation test (trying to login with it without prior
> registry vetting triggers an authentication error, so the registrar can
> only do its business if it removes this extension from list at login)
> thus, in your case (just removing the content), a registrar not wanting to
> do DNSSEC and not wanting to transfer
> to him a currently DNSSEC-enabled domain will have no way to know that.
>
> And saying to registrars: "then pass registry accreditation tests to be
> able to login with secDNS and see **others** domain names with secDNS data
> while you do not want to do any DNSSEC related stuff", is certainly not
> going to fly...
>
> As long as we take into account only some cases and not others we will
> never be
> able to deliver an extension used by multiple registries.
> Also, before anything happen I will be very interested by intention of
> support
> (which means deployment) from registries.
>
> Otherwise, like I said, this problem exists since EPP started so it is not
> new,
> and it seems the current status quo fits most of the player (due to the
> number of people
> having participated here), so we are maybe devoting resources to trying to
> design
> something perfect... that noone will then use :-(
>
> --
>   Patrick Mevzek
>
> ___
> 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
>
-- 
Ulrich Wisser
ulr...@wisser.se
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

Hello Ulrich

I don't know the numbers but I think you are right that most registrars don't 
care too much yet.
On the other hand there are some new extensions in the pipeline that use the 
poll mechanism. (change poll, balance etc.)

Thats why I believe it will/should become more important in the future.

The number of validating clients may be small but I don't believe that we can 
ignore them and send our poll message with extensions regardless of the 
configured login services.
Even if some of the registrars don't implement according to the standards, I 
think at least the registries should do so and creating a poisoned message is 
therefore not an option for us.

So the only alternative to deal with it is to not send the extension part and 
in some cases this means to not send a poll message at all.

Therefore a client has no option of knowing that he is missing out on some 
information unless studying the manuals of the registry...

I think that this is hindering the development of EPP Poll extensions for no 
good reason. Out of sight - out of mind...

Martin




Von: Ulrich Wisser [ulr...@wisser.se]
Gesendet: Montag, 16. Juli 2018 21:58
An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Hi,

are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two categories.
- do never poll
- poll and ignore anyway

I know that we have registrars who validate, but those usually support all our 
extensions.

Could anybody produce numbers on registrars who do all three?
  1. poll
  2. validate
  3. do not support all extensions

/Ulrich





Martin Casanova mailto:martin.casan...@switch.ch>> 
schrieb am Mo., 16. Juli 2018 um 15:09 Uhr:
Patrick

To be clear the domain info response will be sent just without the DNSSec part. 
Therefore a not DNSSec interested registrar will just not see the DNSSec 
configuration but all the rest of the domain info resData. I don't see a 
problem with that.

In our case a registrar currently needs to be accredited by us (DNSEC_ENABLED) 
in order to successfully login with DNSSec extension configured and he will 
only be able to transfer a DNSSec domain to him if the configured DNSSec at 
login.

In case he is DNSSec enabled but still logs in without this extension he will 
get a failure with error message similar to  “Not allowed to transfer DNSSec 
Domain” when trying to transfer a DNSSec domain to him.

So actually there is a way to know why it didn't work for him.

As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.

Martin

Von: regext [regext-boun...@ietf.org] im 
Auftrag von Patrick Mevzek [p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 20:31
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login
> services defines what the server can return to the client, so if the
> client does not support the DNSSEC extension it is completely reasonable
> for the server not to return it.  If a client wants to see the DNSSEC
> information returned they should include the URI in their login
> services.

James, please, again, take into account some real life examples that happen 
today:

registries restrict the use of secDNS at login for only the registrars having 
passed
a specific accreditation test (trying to login with it without prior registry 
vetting triggers an authentication error, so the registrar can only do its 
business if it removes this extension from list at login)
thus, in your case (just removing the content), a registrar not wanting to do 
DNSSEC and not wanting to transfer
to him a currently DNSSEC-enabled domain will have no way to know that.

And saying to registrars: "then pass registry accreditation tests to be able to 
login with secDNS and see **others** domain names with secDNS data while you do 
not want to do any DNSSEC related stuff", is certainly not going to fly...

As long as we take into account only some cases and not others we will never be
able to deliver an extension used by multiple registries.
Also, before anything happen I will be very interested by intention of support
(which means deployment) from registries.

Otherwise, 

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

Hello Jody

Von: Jody Kolker [jkol...@godaddy.com]
Gesendet: Montag, 16. Juli 2018 21:48
An: Martin Casanova; Patrick Mevzek; regext@ietf.org
Betreff: RE: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Hi Martin,

<<
As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.
>>

How does DNSSEC data get configured by the DNS-Operator of a domain if the 
DNS-Operator is not the registrar?  Is the DNSSEC data set without the 
registrar knowing it was added?  If so, how?

M: This done by the polling specific DNS Records (CDS) from the configured name 
servers of a domains. (RFC-7344 and RFC-8078) which we are currently 
implementing. It could be and will be often the case that the DNS-Operator and 
the registrar are the same entity but its not a must.
"We support RFC-7344 and RFC-8078 for automated DNSSEC delegation trust 
maintenance. Enable fully automated DNSSEC bootstraping, key rollover or 
removal in your favourite name server software. Once a day your name servers 
will be checked for new CDS signaling records. Changes in CDS signaling records 
are accepted and published in our .ch or .li zone after a delay of 3 working 
days if our acceptance criterias are met. "


Thanks,
Jody Kolker
Martin Casanova


-Original Message-
From: regext  On Behalf Of Martin Casanova
Sent: Monday, July 16, 2018 2:09 PM
To: Patrick Mevzek ; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Patrick

To be clear the domain info response will be sent just without the DNSSec part. 
Therefore a not DNSSec interested registrar will just not see the DNSSec 
configuration but all the rest of the domain info resData. I don't see a 
problem with that.

In our case a registrar currently needs to be accredited by us (DNSEC_ENABLED) 
in order to successfully login with DNSSec extension configured and he will 
only be able to transfer a DNSSec domain to him if the configured DNSSec at 
login.

In case he is DNSSec enabled but still logs in without this extension he will 
get a failure with error message similar to  "Not allowed to transfer DNSSec 
Domain" when trying to transfer a DNSSec domain to him.

So actually there is a way to know why it didn't work for him.

As a matter of fact we will have to over think this rule now because with CDS 
DNSSec Data can be configured by the DNS-Operator of a domain as well (which 
does not need to be the registrar) . So a domain of a non DNSSec accredited 
registrar could end up with  DNSSec data. In case he is DNSSec accredited he 
might be interested to keep his DNSSec Data synchronized with the data at the 
registry originated by CDS. That is exactly our use case where we want to use 
the change poll extension.

Martin

Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek 
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 20:31
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login
> services defines what the server can return to the client, so if the
> client does not support the DNSSEC extension it is completely
> reasonable for the server not to return it.  If a client wants to see
> the DNSSEC information returned they should include the URI in their
> login services.

James, please, again, take into account some real life examples that happen 
today:

registries restrict the use of secDNS at login for only the registrars having 
passed a specific accreditation test (trying to login with it without prior 
registry vetting triggers an authentication error, so the registrar can only do 
its business if it removes this extension from list at login) thus, in your 
case (just removing the content), a registrar not wanting to do DNSSEC and not 
wanting to transfer to him a currently DNSSEC-enabled domain will have no way 
to know that.

And saying to registrars: "then pass registry accreditation tests to be able to 
login with secDNS and see **others** domain names with secDNS data while you do 
not want to do any DNSSEC related stuff", is certainly not going to fly...

As long as we take into account only some cases and not others we will never be 
able to deliver an extension used by multiple registries.
Also, before anything happen I will be very 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> JG - Why does the extension data need to reside within the 
>  node?  EPP already has an extension mechanism that 
> can be used, so why not use it in this case? 

I have two reasons for this.
The first one being that the XML document in itself can be useful, outside of 
the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some 
document, registrars can use it, for example, to process it and generate some 
code based on it. The XML document in this case, that is without any structure 
coming from EPP, could evevn be distributed out of band (one may argue that EPP 
being a *provisioning* protocol it is not the best to just send information and 
while you define the  command on this new structure, I doubt many EPP 
clients will implement or need to implement it).

The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking the 
 3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC are 
their own RFCs and while they are purely related to domain names, it would not 
look strange to me that they are top elements themselves, like I wrote each RFC 
and/or namespace could be a top element grouping policies related to it.

This would also simplify the whole  content.

> JG - Maybe you can provide some sample XML that combines the policy for 
> a Registry Zone that supports what is in the Registry Mapping and in the 
> Launch Phase Policy Extension to help understand your proposal.  

I will try to do that based on other discussions of this draft, to see where 
the consensus goes to.

> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.
> 
> JG - The schedule can certainly be enhanced.  Can you propose an 
> alternative structure to define it?  

The current example

   
 pendingDelete
 Pending Delete Batch
 
 0 14 * * *
 
   

could be with ISO8601:

   
 pendingDelete
 Pending Delete Batch
 R/14:00:00-05:00/P1D
   



The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date of 
the ISO8601 format)


On a related note, there may be a need here to also encode things such as: 
contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)


 
> As for timezones, all EPP standards always used UTC for all 
> timestamps (and even if some registries on the field do not respect 
> that), and I think it would be best to stick to that, so that removes 
> the "tz" attribute.
> 
> JG - Yes, that is the case for communicating dates (create date, 
> expiration date), but not the case when it comes to defining a schedule 
> for a batch component that runs based on a local time zone.  

I still think it is simpler to have UTC everywhere, this also makes registries 
fully aware that their operations are indeed international because some of 
their registrars may really be from the opposite side of the world.

But at least as long as the timezone is mandatory (and non ambiguous, which 
means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a 
step in the good direction.

> I find this unfortunate:
> :  The zone name that can be at any level
> 
> When you parse it, you read it as "a registry name", but then it is a 
> zone.
> So while it could probably not be  it should at least be
> .
>  
> JG- The label name could be changed, but I believe the most important 
> item is the meaning of the element.  Since the  element 
> is a sub-element of the  element, wouldn't it be 
> redundant to replicate the zone in the label () or 
> the namespace ()?  I don't believe defining a new namespace 
> will help here.  I believe leaving it as 
> EXAMPLE... 
> with a description of the  element as meeting the need.   

My problem is probably exacerbated by the use of "registry" as namespace alias. 
I believe both the name of the extension and hence its XML namespace should be 
changed.

> You are speaking about "regex" in various places without referencing 
> how is this formatted. There are multiple de facto regex "standards" so 
> care must be taken there to reference precisely what kind of regex are 
> manipulated.
> Also, for example for passwords, some registries policies are not 
> possible to express (only) in regex I think, so there might be a blind 
> spot here.
> 
> JG - Do you have a proposal of how to precisely define the regex?  I'm 
> looking for the other registries to review the draft and weigh in on how 
> they can effectively communicate their policies.

I think it would be important to specify 

[regext] Suggestion of work methodology?

[Patrick Mevzek]

Hello,

This is a meta discussion on the way we work.
So just exposing some ideas, if they could interest anyone.
Feel free to participate in you want, here or in private.

You may have seen this email on the DNSOP working group:
https://mailarchive.ietf.org/arch/msg/dnsop/gQ0qju2MPDBz4R5KkRYMKL_ioeg
which was prompted by the "Camel" presentation of the DNS at the previous IETF
meeting, and similar interests in other working groups.
The TLS WG seems to have gone into the same kind of questions/directions.

Many points boil down to: not everything that can be done should be done.
(and the future is difficult to predict, hence thinking of being able right at 
the beginning to cover all future use cases, specially those not 
documented/voiced, can be tricky at least or completely ending in the wrong 
direction at worst).

And I think part of the low participation is caused by the following.

Sometimes this working group receives drafts that clearly caters for a specific 
registry or registrar. This is all fine per se and the fact of discussing 
things in public should be welcomed and appreciated. However it may be 
difficult for the other participants to really understand the use case, as this 
may not be always very clear. So you either let it go, or try to understand it, 
or try to offer comments on the proposition to make it more generic, which 
could be completely going an opposite route from the initial needs.

Should every EPP extension used by only one registry be standardized through an 
RFC? Especially a "Proposed Standard" one? I am not sure about that.

It is good of course that an extension is documented and even follows some 
wireframe. This is the purpose of the EPP extensions registry I think, and 
should be enough for some cases. The guidance of the working group would be, 
besides the EPP experts review on the document to advise if this is of generic 
interest or not, so that documents really coming into the WG as adopted 
documents and later WGLC on them and such are really made in such a way they 
are deemed to be useful for the EPP community at large.

For anything that is supposed to benefit the greater good I think that the 
Implementation Section should be mandatory, to be done before a WGLC, with at 
least 2 separate server implementations and 2 separate client implementations.
(and ideally at least one client implementation capable to speak to the 2 
servers ones). It is only when implementations start to exist that the finest 
details of the design can be tested, so their existence should be mandatory 
before pushing a document towards the "Proposed Standard" state.
The corrolary being that the writers will have to find registries and 
registrars willing to implement their proposition, which is one way to show 
interest and consensus.

It would help also I think if the concerned registries speak up and support the 
specific work. I know that we are all under a "one participant one voice" rule, 
but it is clear too that work is done for specific registries or registrars, or 
group of them (like gTLDs).
And for the same reason if any registry thinks that some proposition goes 
completely in the other direction from what they do or plan to do, and even if 
they may not be required to implement the extension, it should be good if they 
speak up. It could help reshape the design to make sure it accomodate more 
cases.

-- 
  Patrick Mevzek

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

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Gould, James]

Patrick,

In this case the server is communicating an error condition, but the condition 
does not result in an error code being returned.  A poll message really cannot 
fail, otherwise you get into the poison message scenario.  Even if we disagreed 
that this is an error condition, the RFC 5730 description does not use a 
normative SHOULD or MUST so it can be used in a 1301 response .  The  
element can contain the entire extension XML along with a reason for each 
unhandled extension for later processing.  By inclusion of the unhandled XML in 
the  element, the client can get the entire poll message for acking, 
and there is no issue with returning extensions that may cause client-side XML 
parsing errors or marshaling errors.  
  
—
 
JG



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

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

Verisign.com  

On 7/16/18, 12:11 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Thu, Jun 14, 2018, at 11:22, Martin Casanova wrote:
> While implementing, another idea came to mind, which I want to put to
> discussion here:
> 
> 
> 
>   
> 
>   Command completed successfully; ack to dequeue
> 
>   
> 
>   urn:ietf:params:xml:ns:changePoll-1.0
> 
> Msg incomplete due to missing extURI at login
> cmd! To fix include at epp/command/login/svcs/svcExtension/extURI
>   
>   
> 
>   urn:ietf:params:xml:ns:secDNS-1.1
> 
> Msg incomplete due to missing extURI at login
> cmd! To fix include at : 
epp/command/login/svcs/svcExtension/extURI
>   


First on a technical level, replying to registrar basically "fix your 
client", is not really something nice, nor what registries should be doing.
Notifications are external to registrars, they can appear without any 
action triggered by them so basically you are filling their "inbox" with some 
external messages they may or may not care about, and then you are taxing them 
of being bad because they can not read all messages, and maybe they would not 
like to.

Some registrars may wish, for their own reasons, not to support some 
extensions and then at the same time you can not have one message in their 
queue that blocks all others after.

But more important, on a technical level, I believe the spirit of RFC5730 
is that value/extValue element appears for *error messages*, that is all having 
code 2000 or more. Hence they would not fit for a 1301 return code.
 
Also note:
A  element that identifies a client-provided element
(including XML tag and value) that caused a server error
condition.


=> a client-provided element... the message you describe is in the response 
of a poll command by a client, and this poll command has none of that data you 
put in the  element of the server reply.


So while I see the underlying idea, I think you are bending RFC5730 quite a 
lot to achieve it.

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

___
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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Ulrich Wisser]

Hi Martin,

as was said in the wg session, you are a registrar to a registry. You
probably have a contract and in most cases, you have to go through some
sort of OTE.
So how would you get into a situation where you cannot validate data from
the registry? Of course you could choose to not support one of the
extensions and just ignore those messages. By all means, do that. And I
mean do that, ignore the message. From a registry perspective there is no
good way to handle this. None of the proposals leads to actual fixing of
the problem. It just helps lazy registrars to ignore the problem. That can
be achieved cheaper!

/Ulrich


Martin Casanova  schrieb am Mo., 16. Juli 2018
um 18:09 Uhr:

> Hello Ulrich
>
> I don't know the numbers but I think you are right that most registrars
> don't care too much yet.
> On the other hand there are some new extensions in the pipeline that use
> the poll mechanism. (change poll, balance etc.)
>
> Thats why I believe it will/should become more important in the future.
>
> The number of validating clients may be small but I don't believe that we
> can ignore them and send our poll message with extensions regardless of the
> configured login services.
> Even if some of the registrars don't implement according to the standards,
> I think at least the registries should do so and creating a poisoned
> message is therefore not an option for us.
>
> So the only alternative to deal with it is to not send the extension part
> and in some cases this means to not send a poll message at all.
>
> Therefore a client has no option of knowing that he is missing out on some
> information unless studying the manuals of the registry...
>
> I think that this is hindering the development of EPP Poll extensions for
> no good reason. Out of sight - out of mind...
>
> Martin
>
>
>
> --
> *Von:* Ulrich Wisser [ulr...@wisser.se]
> *Gesendet:* Montag, 16. Juli 2018 21:58
> *An:* Martin Casanova
> *Cc:* Patrick Mevzek; regext@ietf.org
>
> *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re:
> I-D Action: draft-ietf-regext-change-poll-07.txt)
> Hi,
>
> are we really sure this is a problem worth solving?
> At .se registrars (with very few exceptions) fall into two categories.
> - do never poll
> - poll and ignore anyway
>
> I know that we have registrars who validate, but those usually support all
> our extensions.
>
> Could anybody produce numbers on registrars who do all three?
>   1. poll
>   2. validate
>   3. do not support all extensions
>
> /Ulrich
>
>
>
>
>
> Martin Casanova  schrieb am Mo., 16. Juli 2018
> um 15:09 Uhr:
>
>> Patrick
>>
>> To be clear the domain info response will be sent just without the DNSSec
>> part. Therefore a not DNSSec interested registrar will just not see the
>> DNSSec configuration but all the rest of the domain info resData. I don't
>> see a problem with that.
>>
>> In our case a registrar currently needs to be accredited by us
>> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
>> configured and he will only be able to transfer a DNSSec domain to him if
>> the configured DNSSec at login.
>>
>> In case he is DNSSec enabled but still logs in without this extension he
>> will get a failure with error message similar to  “Not allowed to transfer
>> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>>
>> So actually there is a way to know why it didn't work for him.
>>
>> As a matter of fact we will have to over think this rule now because with
>> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
>> (which does not need to be the registrar) . So a domain of a non DNSSec
>> accredited registrar could end up with  DNSSec data. In case he is DNSSec
>> accredited he might be interested to keep his DNSSec Data synchronized with
>> the data at the registry originated by CDS. That is exactly our use case
>> where we want to use the change poll extension.
>>
>> Martin
>> 
>> Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick
>> Mevzek [p...@dotandco.com]
>> Gesendet: Montag, 16. Juli 2018 20:31
>> An: regext@ietf.org
>> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re:
>> I-D Action: draft-ietf-regext-change-poll-07.txt)
>>
>> On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
>> > I believe that the login
>> > services defines what the server can return to the client, so if the
>> > client does not support the DNSSEC extension it is completely reasonable
>> > for the server not to return it.  If a client wants to see the DNSSEC
>> > information returned they should include the URI in their login
>> > services.
>>
>> James, please, again, take into account some real life examples that
>> happen today:
>>
>> registries restrict the use of secDNS at login for only the registrars
>> having passed
>> a specific accreditation test (trying to login with it without prior
>> registry vetting triggers an 

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Patrick Mevzek]

On Mon, Jul 16, 2018, at 21:08, Martin Casanova wrote:
> To be clear the domain info response will be sent just without the 
> DNSSec part. Therefore a not DNSSec interested registrar will just not 
> see the DNSSec configuration but all the rest of the domain info 
> resData. I don't see a problem with that.

Here is the problem as already exposed: you may have registrars that do not 
want to deal
with DNSSEC on a philosophical principle. They may want to specifically not try 
to 
transfer a currently DNSSEC enabled domain to them, because they know it will 
break
resolution and they do not want to handle the customer saying that they broke
the domain.

Besides using the DNS, in your case, this registrar has no way to know in 
advance
that the transfer will be a problem. And I suspect telling them 'Please be 
DNSSEC
accredited with us and login with secDNS extension' will fall on a deaf ear.

> In case he is DNSSec enabled but still logs in without this extension he 
> will get a failure with error message similar to  “Not allowed to 
> transfer DNSSec Domain” when trying to transfer a DNSSec domain to him.

What happens for a non-DNSSEC enabled registrar (and hence not using secDNS on 
login)
when he tries to transfer to him a DNSSEC-enabled domain?
Is this refused?
 
Also to leave the discussion on track, this DNSSEC part of domain:info response 
was only
one example of the same problem ("unhandled namespaces") outside of the poll 
messages,
because I think the problem is global and we should tackle it globally (or not 
at all
and leave it at the current status quo).

-- 
  Patrick Mevzek
 

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

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Gould, James]

Patrick,

Yes, I believe the idea that Martin came up with to use the  element 
with the inclusion of the full unhandled XML block is the best option thus far. 
 It honors the client login services, it includes all of the XML for later 
processing, and it does not cause XML parsing failures or marshaling failures.  
I implemented each of the discussed approaches using a stub server and a 
validating client, and this approach works best in my opinion.   
  
—
 
JG



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

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

Verisign.com  

On 7/16/18, 12:20 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Thu, Jun 14, 2018, at 16:04, Gould, James wrote:
> This approach looks good to me.  It has the advantage of providing the 
> unhandled information in an element that is meant for machine processing 
> instead of using the  element that’s meant is meant to be 
> human readable.  The other advantage is that the contents of the  
> element is not processed by the XML parser (e.g., 
> processContents=”skip”), meaning it would not cause an XML parser error.
> 
> This approach could include the entire unhandled extension block without 
> causing client-side parsing or unmarshalling issues.

This "could" should be a "must", otherwise a registrar has no way to just 
download the message for later consumption without having the need to login 
will all possible extensions. 

Again please take into account this example that exists today:
some registries restrict the extensions can be used on login, because some 
may be related to specific accredition, like secdns.
So some registrars may not even be able to put some extensions there, but 
may get notifications with messages using these exceptions, as they do not 
control what kind of messages they get and some may appear due to actions from 
other parties, like other registrars or the registry itself.

But like I said all of this still quite bends the RFC5730 spirit I think 
where value/extValue should be mostly for errors and value should reference a 
client provided element, which is not the case in these examples.

This latest idea from Martin and you is probably the best one we discussed 
about as of yet, and if I could get convinced to add myself on the consensus 
for it, I am still uneasy by how it uses RFC5730 structures.

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

___
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] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Gould, James]

Patrick,

My replies are embedded below.
  
—
 
JG



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

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

Verisign.com  

On 7/16/18, 3:14 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> JG - Why does the extension data need to reside within the 
>  node?  EPP already has an extension mechanism that 
> can be used, so why not use it in this case? 

I have two reasons for this.
The first one being that the XML document in itself can be useful, outside 
of the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some 
document, registrars can use it, for example, to process it and generate some 
code based on it. The XML document in this case, that is without any structure 
coming from EPP, could evevn be distributed out of band (one may argue that EPP 
being a *provisioning* protocol it is not the best to just send information and 
while you define the  command on this new structure, I doubt many EPP 
clients will implement or need to implement it).

The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking 
the  3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC 
are their own RFCs and while they are purely related to domain names, it would 
not look strange to me that they are top elements themselves, like I wrote each 
RFC and/or namespace could be a top element grouping policies related to it.

This would also simplify the whole  content.

JG - The elements included in the draft ("top" structure) are directly 
associated with the existing mature EPP RFCs.  New EPP extensions (drafts and 
RFCs) that are defined can include or be associated with new policy extensions 
of the registry object.  The entire EPP command and response is a full XML 
document, so I don't see any advantage to creating a new extensibility point 
within the registry mapping to put policy extensions under the 
 element.  We should use the extensibility mechanism that is 
already defined in EPP.  

> JG - Maybe you can provide some sample XML that combines the policy for 
> a Registry Zone that supports what is in the Registry Mapping and in the 
> Launch Phase Policy Extension to help understand your proposal.  

I will try to do that based on other discussions of this draft, to see 
where the consensus goes to.

> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.
> 
> JG - The schedule can certainly be enhanced.  Can you propose an 
> alternative structure to define it?  

The current example

   
 pendingDelete
 Pending Delete Batch
 
 0 14 * * *
 
   

could be with ISO8601:

   
 pendingDelete
 Pending Delete Batch
 R/14:00:00-05:00/P1D
   



The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date 
of the ISO8601 format)


On a related note, there may be a need here to also encode things such as: 
contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)

  JG - I believe the format of the schedule is a good area for discussion, 
since use of the cron format was simply the first attempt.  Yes, policy 
associated with deletion of unused (unlinked) objects (contacts and hosts) is a 
good topic for inclusion.  
 
> As for timezones, all EPP standards always used UTC for all 
> timestamps (and even if some registries on the field do not respect 
> that), and I think it would be best to stick to that, so that removes 
> the "tz" attribute.
> 
> JG - Yes, that is the case for communicating dates (create date, 
> expiration date), but not the case when it comes to defining a schedule 
> for a batch component that runs based on a local time zone.  

I still think it is simpler to have UTC everywhere, this also makes 
registries fully aware that their operations are indeed international because 
some of their registrars may really be from the opposite side of the world.

But at least as long as the timezone is mandatory (and non ambiguous, which 
means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a 
step in the good direction.

JG-Yes UTC everywhere would make things simpler, but the reality is that there 
are registries that do run batches based on the local time zone.  

 

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Martin Casanova]

James, Patrick

Partly I understand Patrick's argument that the introduction of new types of 
poll messages could cause a problem for clients if their business logic is not 
prepared for it, even if technically the message can be received without any 
problem. Also our rule of restricting not enabled clients to  login with DNSSec 
has to fall. This rule will be obsolete with the CDS process anyway (RFC-7344 
and RFC-8078)

The precondition of this approach is, that we actually can ask all registrars 
to prepare their clients to at least tolerate new poll messages and to update 
their business logic in order to process the newly given information properly 
if they wish to do so. I think this should be the case and no problem for most 
registrars already.

However we also considered to implement a server side flag to give registrars 
an out of band way  to “opt out” of receiving poll messages with certain 
extensions.  Also because we are still discussing if and how triggering of 
normally registry initialed messages by clients could be realized for 
integration testing of their business logic.
 
I think it should be good practice to have a process where new poll messages 
are allowed as per default, eventually with an optional mechanism to spare 
certain clients from receiving messages they actually don't care about, in 
order to drive the progress of using EPP extensions.

I will participate this afternoon remotely. See you soon.

Martin Casanova

Von: regext [regext-boun...@ietf.org] im Auftrag von Gould, James 
[jgould=40verisign@dmarc.ietf.org]
Gesendet: Montag, 16. Juli 2018 13:06
An: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Patrick,

Yes, I believe the idea that Martin came up with to use the  element 
with the inclusion of the full unhandled XML block is the best option thus far. 
 It honors the client login services, it includes all of the XML for later 
processing, and it does not cause XML parsing failures or marshaling failures.  
I implemented each of the discussed approaches using a stub server and a 
validating client, and this approach works best in my opinion.

—

JG



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

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

Verisign.com 

On 7/16/18, 12:20 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Thu, Jun 14, 2018, at 16:04, Gould, James wrote:
> This approach looks good to me.  It has the advantage of providing the
> unhandled information in an element that is meant for machine processing
> instead of using the  element that’s meant is meant to be
> human readable.  The other advantage is that the contents of the 
> element is not processed by the XML parser (e.g.,
> processContents=”skip”), meaning it would not cause an XML parser error.
>
> This approach could include the entire unhandled extension block without
> causing client-side parsing or unmarshalling issues.

This "could" should be a "must", otherwise a registrar has no way to just 
download the message for later consumption without having the need to login 
will all possible extensions.

Again please take into account this example that exists today:
some registries restrict the extensions can be used on login, because some 
may be related to specific accredition, like secdns.
So some registrars may not even be able to put some extensions there, but 
may get notifications with messages using these exceptions, as they do not 
control what kind of messages they get and some may appear due to actions from 
other parties, like other registrars or the registry itself.

But like I said all of this still quite bends the RFC5730 spirit I think 
where value/extValue should be mostly for errors and value should reference a 
client provided element, which is not the case in these examples.

This latest idea from Martin and you is probably the best one we discussed 
about as of yet, and if I could get convinced to add myself on the consensus 
for it, I am still uneasy by how it uses RFC5730 structures.

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

___
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] Milestones changed for regext WG

[IETF Secretariat]

Changed milestone "Submit for publication "Allocation Token Extension for
EPP"", resolved as "Done".

URL: https://datatracker.ietf.org/wg/regext/about/

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

[regext] Milestones changed for regext WG

[IETF Secretariat]

Changed milestone "Submit for publication "Organization Extension for EPP"",
resolved as "Done".

Changed milestone "Submit for publication "EPP Organization Mapping"",
resolved as "Done".

URL: https://datatracker.ietf.org/wg/regext/about/

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

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Mario Loffredo]

Hi James,
my  answers to your questions are below.

Regards,
Mario

Il 16/07/2018 04:24, Gould, James ha scritto:


Mario,

In reviewing the mailing list feedback on 
draft-gould-carney-regext-registry, I missed your feedback.  Thanks 
for taking the time to review draft-gould-carney-regext-registry and 
provide your feedback.  I provide responses to your feedback below.


—

JG


cid:image001.png@01D255E2.EB933A30

*James Gould
*Distinguished Engineer
jgo...@verisign.com

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

Verisign.com 

*From: *regext  on behalf of Mario Loffredo 


*Date: *Thursday, June 7, 2018 at 10:40 AM
*To: *Roger Carney , regext 
*Subject: *[EXTERNAL] Re: [regext] New Version Notification for 
draft-gould-carney-regext-registry-00.txt


Hi Roger,

I couldn't attend the last Interim Meeting so I apologise if some 
comments below could be obsolete:


1) According to section 1.1 of RFC 5731, a server cannot support the 
host object. So, even if the server implements a policy about IP 
addresses included in domain:hostAddr elements, it doesn't implement 
check (or any other) operation on hosts
Therefore, a minOccurs="0" attribute should be added to the element 
maxCheckHost of hostType.


Good point that draft-gould-carney-regext-registry may not properly 
support defining the policies for a zone that supports hostAddr 
instead of hostObj in RFC 5731.  We’ll take a closer look at how 
hostAddr can be supported in draft-gould-carney-regext-registry 
including the XML schema definition of maxCheckHost.




2) Why should supportedStatus only contain standard status ? The 
supportedStatusType definition is less strict than the description and 
this seems good to me because supportedStatusType can match custom 
status too.


It would be good to understand how custom statuses are supported to 
effectively define the policy for custom statuses.  Can you provide a 
description of how custom statuses are supported?  You are correct 
that the supportedStatusType is not an enumerated type, so therefore 
any status can be included.



In the same way the rgpStatus of RGP extension is supported. Usually, 
due to local regulations, custom statuses are applied to domains and 
affect the set of operations a client can request. I think that the 
Registry Mapping extension would be very helpful if servers could 
provide clients with a formal description of the operations clients are 
allowed to request on a domain according to their statuses, no matter 
the statuses are standard or custom. IMHO, the only reference of the 
extension declaring the custom statuses in the registry:svcExtension 
element would not be enough.

I hope this could clarify my previous statement.



3) The description of expiryPolicy contains the following sentence:

"autoRenew": The domain object will auto-renew at expiry.
  The client can receive a credit for the 
auto-renew if the
                         domain object is deleted within the 
auto-renew grace period."


Does it make sense to replace "if the domain object is deleted" with 
"if the domain object is deleted or transferred" ?


Yes, adding “or transferred” to the description makes sense for the 
auto-renew grace period.



4) Considering that RFC 5730 defines a response code returned when a 
server receives an unimplemented command (i.e. 2101) , maybe it's 
worth to add information about unimplemented operations.


Good point, we can put some thought into how to define this.


5) In my opinion, the schedule format has some limits. Java EE Timer 
expressions 
(https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm) 
seem to be more flexible especially regarding dayOfMonth values:


1 to 31. For example: dayOfMonth="15".

–7 to –1 (a negative number means the /n/th day or days before the end 
of the month). For example: dayOfMonth="–3".


Last. For example: dayOfMonth="Last".

[1st, 2nd, 3rd, 4th, 5th, Last] [Sun, Mon, Tue, Wed, Thu, Fri, Sat]. 
For example: dayOfMonth="2nd Fri".


The schedule format was our first attempt, so we can consider your 
proposal as well.




6) Finally, I hope that in the future the draft will address the 
mapping of the possible extensions described in RFC 5730.


I’m unsure what you mean by “mapping of the possible extensions 
described in RFC 5730”.  Can you describe this a little more?



This answer is strictly related to the previous one of point 2. 
According to RFC5730 there could be three kinds of extensions.  By the 
term "extensions", I mean both the custom extensions (applied only to a 
specific registry) and  new standardized extensions (completing in the 
future the standardization process). Both could deeply affect the server 
policy.
Just to give you an example,  the Login Security extension is currently 
under the WG evaluation. If it will complete the standardization track, 
it will heavily affect clients authentication for those servers that 
will implement it. 

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Patrick Mevzek]

On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which 
> messages to accept
> will be outside the EPP protocol and this WG.

But please also remember that if we want to tackle this problem in a generic 
way (and also taking care of different servers and clients strategies regarding 
handling of namespaces and inline/offline parsing and use) it is not limited to 
a single extension (the thread started long ago with changePoll) nor in fact 
limited to poll messages.

Imagine registrar A wanting to request a transfer from registrar B. In some 
registries it means that regitrar A can do a domain:info on the domain, with 
the authInfo to get access to all details, and specifically the contacts.
But a domain can have a secDNS part in the domain:info reply.
What happens if the registrar A did not login with the secDNS extension (maybe 
this case does not exist in gTLDs where DNSSEC is mandatory but again we have 
other registries cases to take into account)?

Should the domain:info return an error? Return everything as is? Return 
everything but the secDNS part?

The last case is the worst to me: some registrars may like not to support 
DNSSEC at all (and hence will not log in at all, or you have other cases where 
registries mandate specific tests to be "DNSSEC" accredited so it may not even 
be possible to log in with secDNS extension even if the registrar would like 
to) but, and especially for this, being able to detect beforehand if some 
client is trying to transfer to them a domain using DNSSEC, that they would 
like to refuse transferring.


Of course the above is only one example with a domain:info and the secDNS 
extension but I am sure we can find others.

This illustrates I think the distinction I made in earlier messages and the 
different semantic I attach to extensions listed as login: for me they are 
those that the client announce it will use. Of course, it has no control over 
messages or objects he is not the origin or the sponsor, all cases where other 
namespaces may appear.


-- 
  Patrick Mevzek

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