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

[Martin Casanova]

Ulrich


I am impressed by your process of checking who tested and who did not and 
actively contact those who did not test. We did something like that as well 
when we turned off TLS1.0 so I agree to this procedure for some cases.

It kind of confirms my statement that a technical change needs long deadlines 
and intense assistance by the registry.


So in the case of poll extensions how would you proceed? Would you ask all the 
clients to include the new extensions in their login command by the date x? How 
would you proceed with the ones that don't react on your request after the dead 
line?


Some of the options are:

1. Block logins without that extension? (Actually we do not want to force 
anyone to use the poll extension)

2. Send poll messages with extensions anyway? (not exactly according to the 
current RFC)

3. Don’t send such poll extensions or poll messages at all for such clients? 
(creating the poll messages is an asynchronous process and the server has 
actually no way of knowing with which extensions the client might logs in the 
next time to get his poll messages. Also different concurrent sessions can 
support different extensions)

4. Maintaining an out of band server side list of which registrar subscribed to 
which poll extension? (ok but a lot of work for every registry and registrars 
dealing with lots of registries)


I think as well that a registrar who does not want to use a poll extension 
should always be free to ignore them. So it boils down to a technical question 
of how to handle the special case of unknown name-spaces in poll messages. For 
this question we tried to find an easy answer with the  approach. It 
signals to the interested registrar that there is something new but should not 
break current client implementations.


Martin


Von: Ulrich Wisser [ulr...@wisser.se]
Gesendet: Dienstag, 17. Juli 2018 15:25
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)

Martin,

if I understand you right, the problem is ignorant registrars. And the solution 
is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.

Clear communication with registrars and all internal departments sounds more 
feasible.
We deploy these changes six months in advance in our OTE environment.
We check who tested and actively contact registrars that don't.
The only time we had to do a rollback was when the product owner thought that 
would be unnecessary.

/Ulrich


Martin Casanova mailto:martin.casan...@switch.ch>> 
schrieb am Di., 17. Juli 2018 um 05:10 Uhr:

Hi Ulrich


We do have contracts yes. However experience shows us that some registrars just 
don't have the necessary technical skills or means to react on any changes we 
ask them to implement. To pull a change through, long dead lines must be 
granted and even after that, only a part of them actually got active. Many 
registrars only react after we don’t support the outdated options anymore and 
then call our support to ask why it fails, even though they were reminded 
several times.


In this cases customer relations will ask the technical team to make an 
exception for so and so registrar until he fixed his client which leads to more 
work having to configure opt out for single registrars. Also there is no 
standard way of triggering registry initiated messages in OTE yet.


So knowing this we were looking for a more elegant way than going through this 
hassle for every new poll extension we plan to implement. (That's the situation 
where clients cannot validate data from the registry)


To ask the registrars to ignore “unknown” extensions would be the same as 
asking them not to validate the poll responses at all or to at least skip poll 
messages for which validation fails due to unhandled name-spaces since this 
could occur any time a new poll extension is implemented.


If the extended poll messages are sent regardless of the configured login 
services, would that not contradict the idea that only the intersecting set of 
extensions configured in greeting and login are activated for a session? That’s 
how I understood Scott Hollenbeck examples but I may be wrong.


If there is a consent in the WG about these two last points I agree it is also 
an easy solution to just send the message and expect the clients to cope with 
it.


Martin


Von: Ulrich Wisser [ulr...@wisser.se<mailto:ulr...@wisser.se>]
Gesendet: Dienstag, 17. Juli 2018 02:27

An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org<mailto: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 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 s

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

[Ulrich Wisser]

Martin,

if I understand you right, the problem is ignorant registrars. And the
solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.

Clear communication with registrars and all internal departments sounds
more feasible.
We deploy these changes six months in advance in our OTE environment.
We check who tested and actively contact registrars that don't.
The only time we had to do a rollback was when the product owner thought
that would be unnecessary.

/Ulrich


Martin Casanova  schrieb am Di., 17. Juli 2018
um 05:10 Uhr:

> Hi Ulrich
>
>
> We do have contracts yes. However experience shows us that some registrars
> just don't have the necessary technical skills or means to react on any
> changes we ask them to implement. To pull a change through, long dead lines
> must be granted and even after that, only a part of them actually got
> active. Many registrars only react after we don’t support the outdated
> options anymore and then call our support to ask why it fails, even though
> they were reminded several times.
>
>
> In this cases customer relations will ask the technical team to make an
> exception for so and so registrar until he fixed his client which leads to
> more work having to configure opt out for single registrars. Also there is
> no standard way of triggering registry initiated messages in OTE yet.
>
>
> So knowing this we were looking for a more elegant way than going through
> this hassle for every new poll extension we plan to implement. (That's the
> situation where clients cannot validate data from the registry)
>
>
> To ask the registrars to ignore “unknown” extensions would be the same as
> asking them not to validate the poll responses at all or to at least skip
> poll messages for which validation fails due to unhandled name-spaces since
> this could occur any time a new poll extension is implemented.
>
>
> If the extended poll messages are sent regardless of the configured login
> services, would that not contradict the idea that only the intersecting set
> of extensions configured in greeting and login are activated for a session?
> That’s how I understood Scott Hollenbeck examples but I may be wrong.
>
>
> If there is a consent in the WG about these two last points I agree it is
> also an easy solution to just send the message and expect the clients to
> cope with it.
>
>
> Martin
>
> --
> *Von:* Ulrich Wisser [ulr...@wisser.se]
> *Gesendet:* Dienstag, 17. Juli 2018 02:27
>
> *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 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
>>
>>
>>
>> --

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

[Martin Casanova]

Hi Ulrich


We do have contracts yes. However experience shows us that some registrars just 
don't have the necessary technical skills or means to react on any changes we 
ask them to implement. To pull a change through, long dead lines must be 
granted and even after that, only a part of them actually got active. Many 
registrars only react after we don’t support the outdated options anymore and 
then call our support to ask why it fails, even though they were reminded 
several times.


In this cases customer relations will ask the technical team to make an 
exception for so and so registrar until he fixed his client which leads to more 
work having to configure opt out for single registrars. Also there is no 
standard way of triggering registry initiated messages in OTE yet.


So knowing this we were looking for a more elegant way than going through this 
hassle for every new poll extension we plan to implement. (That's the situation 
where clients cannot validate data from the registry)


To ask the registrars to ignore “unknown” extensions would be the same as 
asking them not to validate the poll responses at all or to at least skip poll 
messages for which validation fails due to unhandled name-spaces since this 
could occur any time a new poll extension is implemented.


If the extended poll messages are sent regardless of the configured login 
services, would that not contradict the idea that only the intersecting set of 
extensions configured in greeting and login are activated for a session? That’s 
how I understood Scott Hollenbeck examples but I may be wrong.


If there is a consent in the WG about these two last points I agree it is also 
an easy solution to just send the message and expect the clients to cope with 
it.


Martin


Von: Ulrich Wisser [ulr...@wisser.se]
Gesendet: Dienstag, 17. Juli 2018 02:27
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 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 mailto:martin.casan...@switch.ch>> 
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<mailto:ulr...@wisser.se>]
Gesendet: Montag, 16. Juli 2018 21:58
An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org<mailto: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.

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 t

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<mailto:regext-boun...@ietf.org>] im 
Auftrag von Patrick Mevzek [p...@dotandco.com<mailto:p...@dotandco.com>]
Gesendet: Montag, 16. Juli 2018 20:31
An: regext@ietf.org<mailto: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

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 mult

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)

[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)

[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)

[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)

[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)

[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

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 <http://verisigninc.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

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] 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)

[Patrick Mevzek]

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

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

[Patrick Mevzek]

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

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

[Gould, James]

Martin,

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.  Below is an example of a 
change poll message where the client does not support either the domain or 
changePoll namespaces.  This is unlikely, but it demonstrates how it would work 
for an object and a command / response extension.  As Patrick has pointed out, 
a client could process the contents of the  data offline.



  

  Command completed successfully; ack to dequeue
  

 
   domain.example
   EXAMPLE1-REP
   
   jd1234
   sh8013
   sh8013
   ClientX
   ClientY
   2012-04-03T22:00:00.0Z
   2014-04-03T22:00:00.0Z
 

Message incomplete due to missing 
"urn:ietf:params:xml:ns:domain-1.0" objURI in login services
  
  

 
   update
   2013-10-22T14:25:57.0Z
   12345-XYZ
   URS Admin
   urs123
   URS Lock
 

Message incomplete due to missing 
"urn:ietf:params:xml:ns:changePoll-1.0" extURI in login services
  


  2018-06-14T13:46:33.453Z
  Registry initiated update of domain.


  ABC-12345
  54321-XYZ

  




—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com<http://verisigninc.com/>

From: regext  on behalf of Martin Casanova 

Date: Thursday, June 14, 2018 at 5:23 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


Hello

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
  



It is validating against the schemas. The value is referring to a MISSING 
client provided element in this case. The reason is again human readable and 
referring to a server error which is

not quite the case here but still is indicating a condition that is not ideal..

from RFC-5730

  o  Zero or more OPTIONAL  elements that can be used to

 provide additional error diagnostic information, including:



 *  A  element that identifies a client-provided element

(including XML tag and value) that caused a server error

condition.



 *  A  element containing a human-readable message that

describes the reason for the error.  The language of the

response is identified via an OPTIONAL "lang" attribute.  If

not specified, the default attribute value MUST be "en"

(English).

Regards.
Martin

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone +41 44 268 15 55, direct +41 44 268 16 25

martin.casan...@switch.ch<mailto:roland.eugs...@switch.ch>, 
www.switch.ch<http://www.switch.ch>



Working for a better digital world


On 24.05.2018 10:31, Martin Casanova wrote:
Hello

Sorry I have not been checking the mails of this mailing list for a while...

In my opinion as registries we have a special role and should stick to the 
RFC’s as close as possible for a strong EPP standard everybody can rely on. 
Therefore I find it valuable to discuss the RFC’s and get everybody's input.

I think that there is an issue with potentially breaking some clients, although 
for some clients it may not be a problem as was pointed out.

Also I don't see a big problem for clients to not receive full information in a 
message of a freshly implemented Change Poll Extension response since they 
didn't get it at all before the extension was implemented.

The suggestion of James Gould to give a hint about the missing extension part 
in the  field of the poll response may be a way to go. This filed is 
intended for humans and thats what we want to do: Inform a human to prepare his 
client and configure the Login command accordingly if he wants t

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

[Martin Casanova]

Hello

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
  


It is validating against the schemas. The value is referring to a
MISSING client provided element in this case. The reason is again human
readable and referring to a server error which is

not quite the case here but still is indicating a condition that is not
ideal..

from RFC-5730

  o  Zero or more OPTIONAL  elements that can be used to
 provide additional error diagnostic information, including:

 *  A  element that identifies a client-provided element
(including XML tag and value) that caused a server error
condition.

 *  A  element containing a human-readable message that
describes the reason for the error.  The language of the
response is identified via an OPTIONAL "lang" attribute.  If
not specified, the default attribute value MUST be "en"
(English).

Regards.

Martin

SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world




On 24.05.2018 10:31, Martin Casanova wrote:
> Hello
>
> Sorry I have not been checking the mails of this mailing list for a
> while...
>
> In my opinion as registries we have a special role and should stick to
> the RFC’s as close as possible for a strong EPP standard everybody can
> rely on. Therefore I find it valuable to discuss the RFC’s and get
> everybody's input.
>
> I think that there is an issue with potentially breaking some clients,
> although for some clients it may not be a problem as was pointed out.
>
> Also I don't see a big problem for clients to not receive full
> information in a message of a freshly implemented Change Poll
> Extension response since they didn't get it at all before the
> extension was implemented.
>
> The suggestion of James Gould to give a hint about the missing
> extension part in the  field of the poll response may be a way to
> go. This filed is intended for humans and thats what we want to do:
> Inform a human to prepare his client and configure the Login command
> accordingly if he wants to receive the information of the extension.
>
> However the ChangePoll Extension is not the only one we need to inform
> about. How should we inform about a changes in DNSSec Data? We also
> would have to indicate that the DNSSec extension should be configured
> in order to include something like
>
>  xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">2371
> 13
> 2
> F991B7FDE40A2C4CD7BEFBBE9A1073D1FC3E34EC6DC31E2931320D1CD8392390
> 
> 
>
> in the extension part..
>
> We are planing to do something like this as we are going to implement
> the RFC-8078 / RFC-7344 CDS feature. Of course there will also be an
> out of band communication with our registrars about this.
>
> Martin
>
> --  SWITCH 
> Martin Casanova, Domain Applications
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
> phone +41 44 268 15 55, direct +41 44 268 16 25
> martin.casan...@switch.ch, www.switch.ch 
>  
> Working for a better digital world
>
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world

___
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

Sorry I have not been checking the mails of this mailing list for a while...

In my opinion as registries we have a special role and should stick to
the RFC’s as close as possible for a strong EPP standard everybody can
rely on. Therefore I find it valuable to discuss the RFC’s and get
everybody's input.

I think that there is an issue with potentially breaking some clients,
although for some clients it may not be a problem as was pointed out.

Also I don't see a big problem for clients to not receive full
information in a message of a freshly implemented Change Poll Extension
response since they didn't get it at all before the extension was
implemented.

The suggestion of James Gould to give a hint about the missing extension
part in the  field of the poll response may be a way to go. This
filed is intended for humans and thats what we want to do: Inform a
human to prepare his client and configure the Login command accordingly
if he wants to receive the information of the extension.

However the ChangePoll Extension is not the only one we need to inform
about. How should we inform about a changes in DNSSec Data? We also
would have to indicate that the DNSSec extension should be configured in
order to include something like

2371
13
2
F991B7FDE40A2C4CD7BEFBBE9A1073D1FC3E34EC6DC31E2931320D1CD8392390



in the extension part..

We are planing to do something like this as we are going to implement
the RFC-8078 / RFC-7344 CDS feature. Of course there will also be an out
of band communication with our registrars about this.

Martin

--  SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
martin.casan...@switch.ch, www.switch.ch 
 
Working for a better digital world





___
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)

[Thomas Corte]

Hello,

On 5/22/18 14:23, Gould, James wrote:

> Patrick,
> 
> Referring to the language in the RFC is the starting point in the
> discussion related to defining the problem that may or may not require a
> solution.  I disagree that we should look at the various implementation
> policies implemented in the wild by registries and registrars to develop
> the appropriate interpretation of the RFC.  I see three options with the
> interpretation of the RFC:
> ...
>  3. There is a problem and a common solution is required
>  1.  The RFC does not support servers returning services that the
> client does not include in the login services and a common
> solution is required.  It’s pretty straight forward for the
> server not to return an extension in the response to an object
> command (e.g., domain create), so the real problem is associated
> with the poll messages. 
>  2. With this option, we can start the discussion on defining a
> common solution for the handling of poll messages that the client
> does not support based on the login services.
> 
>  
> 
> I believed I jumped to a proposal for a common solution without
> determining whether the problem is important enough to address.  I do not
> agree with option 1 based on what is defined in RFC 5730, so it comes
> down between option 2 and 3. 

I agree with option 3 only. Our registrar client systems use a validating
parser for registry responses, and it's always a major pain to fix issues
when unexpected XML namespaces start showing up.

That being said, for some registries (such as Afilias) it seems to be a
challenge to even produce schema-compliant server responses when it comes
to the standard EPP RFC schemas.

Best regards,

Thomas Corte

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
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,



Referring to the language in the RFC is the starting point in the discussion 
related to defining the problem that may or may not require a solution.  I 
disagree that we should look at the various implementation policies implemented 
in the wild by registries and registrars to develop the appropriate 
interpretation of the RFC.  I see three options with the interpretation of the 
RFC:



  1.  There is no problem
 *   The RFC supports servers returning services that the client does not 
include in the login services.  This includes responses to object commands 
(e.g., domain create) and poll messages.
  2.  There is a problem, but it is not important enough to create a common 
solution
 *   The RFC does not support servers returning services that the client 
does not include in the login services, but it is not important enough to the 
clients to define a common solution.  It’s pretty straight forward for the 
server not to return an extension in the response to an object command (e.g., 
domain create), so the real problem is associated with the poll messages.
 *   With this option, no common solution will be defined for the handling 
of poll messages that the client does not support based on the login services.
  3.  There is a problem and a common solution is required
 *The RFC does not support servers returning services that the client 
does not include in the login services and a common solution is required.  It’s 
pretty straight forward for the server not to return an extension in the 
response to an object command (e.g., domain create), so the real problem is 
associated with the poll messages.
 *   With this option, we can start the discussion on defining a common 
solution for the handling of poll messages that the client does not support 
based on the login services.



I believed I jumped to a proposal for a common solution without determining 
whether the problem is important enough to address.  I do not agree with option 
1 based on what is defined in RFC 5730, so it comes down between option 2 and 3.



Any thoughts on these options or other options?



Thanks,



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 5/22/18, 3:25 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, May 21, 2018, at 16:15, Gould, James wrote:

> The EPP greeting per RFC 5730 "identifies the services supported by the

> server".  The EPP login command services per RFC 5730 includes "

> elements that contain URIs representing the objects to be managed during

> the session" and "MAY contain one or more  elements that

> identify objects extensions to be used during the session".  I don't

> view the services included in the greeting or the login command as

> information, but used to negotiate the object and extension services to

> be used by the client and server during the session.  The client must

> not pass services that the server does not support based on the EPP

> greeting services, and the server must not pass services that the client

> does not support based on the login command services.



James,



Just repeating the same interpretation of some text in order to come to the 
same conclusion as the preferred one without wanting to see other points in the 
global picture is a sure way to close the discussion, and not to open it.



> A client that is capable

> of accepting every possible services in the response can simply mirror

> the greeting services in the login services.



Read my messages. You have examples when this does not correspond to 
reality.



It is fine having only one implementation in mind and defining stuff to 
conform to it but, sorry, there are others, and other use cases too.



>  If we come to agreement on the meaning of the

> greeting and login services then we can move onto the question of

> handling poll messages that contain services that may not be supported

> by a client.



I think you are putting the cart before the horse. Like I said multiple 
times the problem, if it exists (as I am not sure it exists), must first be 
clearly specified, taking into account all use cases. Only after that we can 
discuss on how to read the current documentation and see what the conclusions 
are.



Starting by interpreting the text to come to a favorable conclusion is not 
really trying to discuss or come into agreement or consensus in my mind.



But again, I think we rehashed this point often enough now, so besides some 
specific document to discuss, or other new views to exchange, it may be better 
to let the thread die.



--

  Patrick Mevzek



___

regext mailing list

regext@ietf.org

   

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

[Patrick Mevzek]

On Mon, May 21, 2018, at 16:15, Gould, James wrote:
> The EPP greeting per RFC 5730 "identifies the services supported by the 
> server".  The EPP login command services per RFC 5730 includes " 
> elements that contain URIs representing the objects to be managed during 
> the session" and "MAY contain one or more  elements that 
> identify objects extensions to be used during the session".  I don't 
> view the services included in the greeting or the login command as 
> information, but used to negotiate the object and extension services to 
> be used by the client and server during the session.  The client must 
> not pass services that the server does not support based on the EPP 
> greeting services, and the server must not pass services that the client 
> does not support based on the login command services. 

James,

Just repeating the same interpretation of some text in order to come to the 
same conclusion as the preferred one without wanting to see other points in the 
global picture is a sure way to close the discussion, and not to open it.

> A client that is capable 
> of accepting every possible services in the response can simply mirror 
> the greeting services in the login services.

Read my messages. You have examples when this does not correspond to reality.

It is fine having only one implementation in mind and defining stuff to conform 
to it but, sorry, there are others, and other use cases too.

>  If we come to agreement on the meaning of the 
> greeting and login services then we can move onto the question of 
> handling poll messages that contain services that may not be supported 
> by a client.

I think you are putting the cart before the horse. Like I said multiple times 
the problem, if it exists (as I am not sure it exists), must first be clearly 
specified, taking into account all use cases. Only after that we can discuss on 
how to read the current documentation and see what the conclusions are.

Starting by interpreting the text to come to a favorable conclusion is not 
really trying to discuss or come into agreement or consensus in my mind.

But again, I think we rehashed this point often enough now, so besides some 
specific document to discuss, or other new views to exchange, it may be better 
to let the thread die.

-- 
  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,

I believe the goal here is to discuss the protocol itself and not deal with the 
registry or registrar policies that conflict with it.  

The EPP greeting per RFC 5730 "identifies the services supported by the 
server".  The EPP login command services per RFC 5730 includes " 
elements that contain URIs representing the objects to be managed during the 
session" and "MAY contain one or more  elements that identify objects 
extensions to be used during the session".  I don't view the services included 
in the greeting or the login command as information, but used to negotiate the 
object and extension services to be used by the client and server during the 
session.  The client must not pass services that the server does not support 
based on the EPP greeting services, and the server must not pass services that 
the client does not support based on the login command services.  With this in 
place, the server can make decisions on what it will return the client based on 
what the client support.  There should be no assumption that clients can 
receive and consume responses that include services that the client did not 
include in the login services.  A client that is capable of accepting every 
possible services in the response can simply mirror the greeting services in 
the login services.  Clients that are only capable of supporting a subset of 
the services should reflect that in the login services.  If we come to 
agreement on the meaning of the greeting and login services then we can move 
onto the question of handling poll messages that contain services that may not 
be supported by a client.
  
—
 
JG



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

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

Verisign.com  

On 5/21/18, 12:12 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Tue, May 8, 2018, at 16:21, Pieter Vandepitte wrote:
> There's no such thing as a client which all 
> of a sudden must support or handle new extensions. 

Probably because the intersection of
"clients validating absolutely all EPP frames received by registry"
and
"clients using blindly all extensions as announced by registry on greeting"
is nil.

However you may not have seen this case or not have been in one, but, for 
having been in one, I know it exists case where the registry says: at day X you 
can not connect anymore to the EPP server if you do not use on login namespace 
X and are prepared to receive messages with it.

Then you are just resolving the problem we discuss by moving it into 
business-land: saying to the registrars to upgrade and thinking that you then 
can send messages with the new extensions because you are sure they will be 
able to handle it because they selected it on login...
Maybe they instead just did a quick change to alter the login (specially if 
it the case of just one extension going from version A to B) and did not bother 
implementing things further than that

> The client says it 
> does not understand it, 

That is not exactly the meaning I read from the login part. I am more 
reading it "I will not deal with this extension, I will not use it in my 
messages". See my following messages for an example.

> 2. The purpose of the server's greeting service and the client's login 
> services: 
> 
> It's not a negotiate. It's informational, and in case of the login svcs 
> it's a kind request to only "talk the languages" of the supported 
> extensions. Should a server return an error when it receives a request 
> containing extensions it does understand, but which are not mentioned by 
> the client? No, even not for extensions it does not understand.

We are now talking about the opposite case (what messages from the client 
should the server accept) and here I disagree with you: the client clearly 
designates at login which namespaces it want to handle, so the server should 
never accept messages with other namespaces from the client. This is also being 
conservative and helps defeat errors in the client. I know at least one 
registry server behaving exactly like that.

> 3. Validating clients: clients should be permissive in what they accept. 
> A client must interpret the server's response as good as possible (i.e. 
> ignoring XSD violations, use of non-supported schema's, ...).
> 
> What about poll responses potentially containing extensions not 
> supported by the client? Because of (3) that should not be a problem, 
> but since in my opinion a server should be conservative (to be able to 
> serve both validating and non-validating clients), it should send the 
> response in another way.

This opens a new complete can of worms. Some registries send then emails, 
others give messages by HTTPS connections, etc.
Many 

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

[Patrick Mevzek]

On Fri, May 4, 2018, at 16:15, Gould, James wrote:
> My recommendation is to move forward with draft-ietf-regext-change-poll 
> and to leave the EPP server sending unsupported responses (mapping 
> extension and / or command response extensions) to a client based on the 
> login services up to a separate draft.

I completely agree with this split.

The problem that was discussed after this draft has in fact nothing to do in 
its core with poll messages, the issue, if there is one, is more global than 
that. I will try to expose it in another email.

-- 
  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)

[Pieter Vandepitte]

I agree: move on, and make this discussion a new work item for the group.

It was an interesting discussion by the way... 

My opinion: 

First of all, I don't know about real world examples of issues concerning 
unsupported extensions by one of our registrars. When we introduce new 
extensions, or update existing ones, this is all communicated long in advance 
to all of our registrars so they can prepare the change. They have plenty of 
time to implement the extensions, and if they don't implement them, I guess 
they just ignore it (non-validating clients). There's no such thing as a client 
which all of a sudden must support or handle new extensions. 

Now to answer the questions:

1. Do you believe that it is protocol compliant for the server to return 
something that the client did not explicitly include in the login services?

No. As Postel said: "be conservative in what you do". The client says it does 
not understand it, so be kind and don't return it.

2. The purpose of the server's greeting service and the client's login 
services: 

It's not a negotiate. It's informational, and in case of the login svcs it's a 
kind request to only "talk the languages" of the supported extensions. Should a 
server return an error when it receives a request containing extensions it does 
understand, but which are not mentioned by the client? No, even not for 
extensions it does not understand.

3. Validating clients: clients should be permissive in what they accept. A 
client must interpret the server's response as good as possible (i.e. ignoring 
XSD violations, use of non-supported schema's, ...).

What about poll responses potentially containing extensions not supported by 
the client? Because of (3) that should not be a problem, but since in my 
opinion a server should be conservative (to be able to serve both validating 
and non-validating clients), it should send the response in another way. This 
is in my opinion a task for the working group. (Top of mind suggestion: encode 
part of the response which is not understood as a CDATA block)

kind regards

Pieter




> On 04 May 2018, at 20:27, Roger D Carney <rcar...@godaddy.com> wrote:
> 
> Good Afternoon,
>  
> +1.
>  
> We agree that that we should move forward with the current 
> draft-ietf-regext-change-poll draft and move this discussion along another 
> path.
>  
>  
> Thanks
> Roger
>  
>  
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
> Sent: Friday, May 04, 2018 9:16 AM
> To: James Galvin <gal...@elistx.com>
> Cc: Patrick Mevzek <p...@dotandco.com>; regext@ietf.org
> Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
> Action: draft-ietf-regext-change-poll-07.txt)
>  
> Jim,
>  
> My recommendation is to move forward with draft-ietf-regext-change-poll and 
> to leave the EPP server sending unsupported responses (mapping extension and 
> / or command response extensions) to a client based on the login services up 
> to a separate draft.  
>  
> This comes down to the interpretation of how the server should handle the 
> login services of the client in creating responses.  EPP extensions like the 
> DNSSEC extension (RFC 5910) leverages the login services in the migration 
> from RFC 4310 to RFC 5910, since the info response may include the DNSSEC 
> extension if there is DNSSEC data.  The inclusion of the DNSSEC extension and 
> the version of the DNSSEC extension is based on the login services.  Similar 
> functionality exists within draft-ietf-regext-epp-fees in determining if and 
> which version of the extension to return to the client.  Poll messages are 
> unique since they are inserted ahead of time by the server without knowledge 
> of what the client does support, and therefore runs the risk of coming across 
> a message that the client does not support based on the login services.  
> Clients may or may not be able to handle the parsing and unmarshalling of 
> unsupported extensions sent by the server.  For poll messaging this is of 
> particular interest, since a client may have an issue acknowledging the 
> unsupported poll messages to get to the rest of the messages in the queue.  
> This would represent a poison message in the poll queue. 
>  
> Based on the thread, there are separate thoughts related to whether it is 
> fine for the server to send a response that contains an extension that was 
> not included in the client’s login services.  I believe that the greeting 
> services and the login services are used to negotiate the set of extensions 
> that client are server can use.  What should the EPP server do with 
> unsupported extensions in any EPP response and with poll message EPP 
> responses in particular?  This is a broader topic than 
> draft-ietf-regext-change-poll, so I

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

[Roger D Carney]

Good Afternoon,

+1.

We agree that that we should move forward with the current 
draft-ietf-regext-change-poll draft and move this discussion along another path.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Friday, May 04, 2018 9:16 AM
To: James Galvin <gal...@elistx.com>
Cc: Patrick Mevzek <p...@dotandco.com>; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to 
leave the EPP server sending unsupported responses (mapping extension and / or 
command response extensions) to a client based on the login services up to a 
separate draft.

This comes down to the interpretation of how the server should handle the login 
services of the client in creating responses.  EPP extensions like the DNSSEC 
extension (RFC 5910) leverages the login services in the migration from RFC 
4310 to RFC 5910, since the info response may include the DNSSEC extension if 
there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of 
the DNSSEC extension is based on the login services.  Similar functionality 
exists within draft-ietf-regext-epp-fees in determining if and which version of 
the extension to return to the client.  Poll messages are unique since they are 
inserted ahead of time by the server without knowledge of what the client does 
support, and therefore runs the risk of coming across a message that the client 
does not support based on the login services.  Clients may or may not be able 
to handle the parsing and unmarshalling of unsupported extensions sent by the 
server.  For poll messaging this is of particular interest, since a client may 
have an issue acknowledging the unsupported poll messages to get to the rest of 
the messages in the queue.  This would represent a poison message in the poll 
queue.

Based on the thread, there are separate thoughts related to whether it is fine 
for the server to send a response that contains an extension that was not 
included in the client’s login services.  I believe that the greeting services 
and the login services are used to negotiate the set of extensions that client 
are server can use.  What should the EPP server do with unsupported extensions 
in any EPP response and with poll message EPP responses in particular?  This is 
a broader topic than draft-ietf-regext-change-poll, so I recommend that we 
don’t attempt to solve the problem specifically for 
draft-ietf-regext-change-poll but more generically across all of the extensions 
in a separate draft.


—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com<http://verisigninc.com/>
From: James Galvin <gal...@elistx.com<mailto:gal...@elistx.com>>
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>>
Cc: Patrick Mevzek <p...@dotandco.com<mailto:p...@dotandco.com>>, 
"regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


The chairs would appreciate a suggestion from those in this discussion as to 
what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you 
have identified a technical issue but you have not been clear as to whether you 
want a change in the existing document or you want a new work item for the 
working group?

What would you propose? What do others think?

Antoin and Jim



On 23 Apr 2018, at 9:27, Gould, James wrote:

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subseque

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

[Gould, James]

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to 
leave the EPP server sending unsupported responses (mapping extension and / or 
command response extensions) to a client based on the login services up to a 
separate draft.

This comes down to the interpretation of how the server should handle the login 
services of the client in creating responses.  EPP extensions like the DNSSEC 
extension (RFC 5910) leverages the login services in the migration from RFC 
4310 to RFC 5910, since the info response may include the DNSSEC extension if 
there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of 
the DNSSEC extension is based on the login services.  Similar functionality 
exists within draft-ietf-regext-epp-fees in determining if and which version of 
the extension to return to the client.  Poll messages are unique since they are 
inserted ahead of time by the server without knowledge of what the client does 
support, and therefore runs the risk of coming across a message that the client 
does not support based on the login services.  Clients may or may not be able 
to handle the parsing and unmarshalling of unsupported extensions sent by the 
server.  For poll messaging this is of particular interest, since a client may 
have an issue acknowledging the unsupported poll messages to get to the rest of 
the messages in the queue.  This would represent a poison message in the poll 
queue.

Based on the thread, there are separate thoughts related to whether it is fine 
for the server to send a response that contains an extension that was not 
included in the client’s login services.  I believe that the greeting services 
and the login services are used to negotiate the set of extensions that client 
are server can use.  What should the EPP server do with unsupported extensions 
in any EPP response and with poll message EPP responses in particular?  This is 
a broader topic than draft-ietf-regext-change-poll, so I recommend that we 
don’t attempt to solve the problem specifically for 
draft-ietf-regext-change-poll but more generically across all of the extensions 
in a separate draft.


—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com<http://verisigninc.com/>
From: James Galvin <gal...@elistx.com>
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould <jgo...@verisign.com>
Cc: Patrick Mevzek <p...@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


The chairs would appreciate a suggestion from those in this discussion as to 
what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you 
have identified a technical issue but you have not been clear as to whether you 
want a change in the existing document or you want a new work item for the 
working group?

What would you propose? What do others think?

Antoin and Jim




On 23 Apr 2018, at 9:27, Gould, James wrote:

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subsequent poll 
ack.  The client could use regular expressions to extract the information or 
could do a validating DOM parse and object unmarshalling to have something 
easier to work with.  There is no way for the server to know the capabilities 
of the client other than using the login services.  Both sets of clients can be 
fully supported if the server honors the login services sent by the client.  If 
the client wants to retrieve everything from the server for later processing, 
then the client can simply mirror the greeting services into the login 
services.  Clients that do unmarshall responses, will most likely use 
marshalling factories that will be used to dynamical

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

[James Galvin]

The chairs would appreciate a suggestion from those in this discussion 
as to what you would like to do next?


The change-poll document has been in WGLC that has now expired.  
However, you have identified a technical issue but you have not been 
clear as to whether you want a change in the existing document or you 
want a new work item for the working group?


What would you propose?  What do others think?

Antoin and Jim





On 23 Apr 2018, at 9:27, Gould, James wrote:


Patrick,



This may be an excellent topic for a working session at the next IETF. 
 It would be great to hear opinions from others on this topic, since 
there is obviously a gap in the interpretation of the greeting and 
login services as it relates to responses (command responses and poll 
response) provided by the server.




Your description still leaves out a case, that I cannot prove to be 
the dominant one but that is certainly not a negligible one: the 
client receives the message, DOES NOT validate it per XML schema, DOES 
NOT parse it, and just stores it (as is or with a simple 
transformation to any other serialization format, an operation that 
does not need to know about the schema nor the content at all) for out 
of band later examination, and ACKs it in EPP to be able to fetch the 
next one.




How can the client ack the message if it doesn’t at least parse it 
for the message id?  An EPP client should frame the responses per RFC 
5734 and will most likely parse the response to determine the result 
of the command and in the case of a poll message parse the message id 
to send the subsequent poll ack.  The client could use regular 
expressions to extract the information or could do a validating DOM 
parse and object unmarshalling to have something easier to work with.  
There is no way for the server to know the capabilities of the client 
other than using the login services.  Both sets of clients can be 
fully supported if the server honors the login services sent by the 
client.  If the client wants to retrieve everything from the server 
for later processing, then the client can simply mirror the greeting 
services into the login services.  Clients that do unmarshall 
responses, will most likely use marshalling factories that will be 
used to dynamically create the login services.  This way the server 
will not send a response that the client does not support and will not 
break the client.




As for "A client would need to proactively deal with the

unexpected if the server does not honor the login services of the

client.", I think this is already the case for many registries, and 
since a long time, so clients had to deal with that already. It is far 
from a new hypothetical problem.




Just because servers have been sending unsolicited extensions to 
clients does not make it correct or appropriate from a protocol 
perspective.  I believe we have examples of EPP extensions (RFC 5910 
and draft-ietf-regext-epp-fees) that includes language related to what 
the server should or should not due based on the client login 
services, so this should be understood.  I believe where it is not 
well understood is the handling of poll messages, which would be the 
point in creating a new draft.






If the registrar logs in without the secDNS extension, to use a "core" 
example, and if it does a domain:info on a domain name which has 
secDNS info (because it is one of his own domain for which he put 
DNSSEC material with it before but right now in this particular 
session it did not use the secDNS extension at login, or maybe less 
contrived before a transfer he does a domain:info with the associated 
authInfo on a domain name it does not sponsor)


then what should the registry do? Send the secDNS part of the 
domain:info or not?


I believe not sending it creates more harm than benefits, even if the 
registrar did not specify it at login, but clearly this is the core 
point of our disagreement.




The registry should not return the secDNS extension in the domain info 
response for a client that does support secDNS-1.0 (RFC 4310) or 
secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 
(https://tools.ietf.org/html/rfc5910#page-4).  There is similar 
language in the Registry Fee Extension related to inclusion of the fee 
extension in the command response (e.g., “does include elements in 
the response, when the extension has been selected during a  
command”).  The login services explicitly provide the object and 
command / response extensions supported by the client along with their 
versions, so why would the server not honor those services to 
determine if and what version of an extension to return to a client?  
The exchange of the server services in the greeting and the client 
services in the login allow the client and server to negotiate what 
extensions are supported on both sides.  Inclusion of an extension 
outside of the negotiated services should result with an error on the 
server side and the server 

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

[Gould, James]

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subsequent poll 
ack.  The client could use regular expressions to extract the information or 
could do a validating DOM parse and object unmarshalling to have something 
easier to work with.  There is no way for the server to know the capabilities 
of the client other than using the login services.  Both sets of clients can be 
fully supported if the server honors the login services sent by the client.  If 
the client wants to retrieve everything from the server for later processing, 
then the client can simply mirror the greeting services into the login 
services.  Clients that do unmarshall responses, will most likely use 
marshalling factories that will be used to dynamically create the login 
services.  This way the server will not send a response that the client does 
not support and will not break the client.



As for "A client would need to proactively deal with the

unexpected if the server does not honor the login services of the

client.", I think this is already the case for many registries, and since a 
long time, so clients had to deal with that already. It is far from a new 
hypothetical problem.



Just because servers have been sending unsolicited extensions to clients does 
not make it correct or appropriate from a protocol perspective.  I believe we 
have examples of EPP extensions (RFC 5910 and draft-ietf-regext-epp-fees) that 
includes language related to what the server should or should not due based on 
the client login services, so this should be understood.  I believe where it is 
not well understood is the handling of poll messages, which would be the point 
in creating a new draft.





If the registrar logs in without the secDNS extension, to use a "core" example, 
and if it does a domain:info on a domain name which has secDNS info (because it 
is one of his own domain for which he put DNSSEC material with it before but 
right now in this particular session it did not use the secDNS extension at 
login, or maybe less contrived before a transfer he does a domain:info with the 
associated authInfo on a domain name it does not sponsor)

then what should the registry do? Send the secDNS part of the domain:info or 
not?

I believe not sending it creates more harm than benefits, even if the registrar 
did not specify it at login, but clearly this is the core point of our 
disagreement.



The registry should not return the secDNS extension in the domain info response 
for a client that does support secDNS-1.0 (RFC 4310) or secDNS-1.1 (RFC 5910) 
according to section 2 of RFC 5910 
(https://tools.ietf.org/html/rfc5910#page-4).  There is similar language in the 
Registry Fee Extension related to inclusion of the fee extension in the command 
response (e.g., “does include elements in the response, when the extension has 
been selected during a  command”).  The login services explicitly 
provide the object and command / response extensions supported by the client 
along with their versions, so why would the server not honor those services to 
determine if and what version of an extension to return to a client?  The 
exchange of the server services in the greeting and the client services in the 
login allow the client and server to negotiate what extensions are supported on 
both sides.  Inclusion of an extension outside of the negotiated services 
should result with an error on the server side and the server should not return 
an unsupported extension back in a response.  The server does not know the 
capabilities of the client, where sending an unsolicitated extension may result 
in a client-side failure in the case for a validating client or a client that 
unmarshalls the response.



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 

On 4/22/18, 3:27 PM, "regext on behalf of 

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

[Patrick Mevzek]

On Fri, Apr 20, 2018, at 16:06, Gould, James wrote:
> Thank you for the detailed description of your reasoning.  I will leave 
> it that we disagree on the purpose of the login services, the need for 
> the server to honor the login services for poll messaging, and the 
> impacts in returning unsupported responses or response extensions to 
> clients.

Ok.

> On the impact, there are two elements to consider including 
> first the XML parser in validating a response against the XML schemas, 
> and second is the unmarshalling of the XML to a representative object.  
> A client could disable the XML parser validation and move along to the 
> unmarshalling step.  In the unmarshalling step the client would need to 
> deal with receipt of unsupported content.  The client could throw an 
> exception because the XML (e.g., DOM tree) could not be unmarshalled, 
> ignore the unsupported content, or come up with some other 
> representation of the unsupported content (e.g., convert to list of XML 
> blobs or DOM objects).  A client would need to proactively deal with the 
> unexpected if the server does not honor the login services of the 
> client. 

Your description still leaves out a case, that I can not prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.

In this case, there are absolutely none of the problem you expose:
the registry has no extra work to do, the registrar has no extra work to do to 
understand messages in unknown namespaces, registrar is not blocked at all for 
any new namespace introduced, the registrar has no problem if the registry 
message does not validate per its own XML schema, the registrar does not have 
to be proactive it can deal with new cases and problems later, etc.
I really fail to see the drawbacks but of course anyone is free to do 
differently and stick to validate and parse everything in band in real time.

As for "A client would need to proactively deal with the 
unexpected if the server does not honor the login services of the 
client.", I think this is already the case for many registries, and since a 
long time, so clients had to deal with that already. It is far from a new 
hypothetical problem.

> Since this is not a problem unique to draft-ietf-regext-change-poll, I 
> agree that it's best suited to be addressed in a separate Internet Draft 
> that addresses service-aware EPP poll messaging.

I agree this should be a separate draft, to become eventually an Informational 
Standard or a Best Practice depending on its content.

> Is there interest in such a draft by the working group?  

I am interested by the subject but disagree on the offered solution.

Also, it may be useful to be able (as difficult as it may be) to understand a 
little more on the current situation, and to see how registries currently 
handle this problem.

Note that this happens very early and not only from poll messages.
If the registrar logs in without the secDNS extension, to use a "core" example, 
and if it does a domain:info on a domain name which has secDNS info (because it 
is one of his own domain for which he put DNSSEC material with it before but 
right now in this particular session it did not use the secDNS extension at 
login, or maybe less contrived before a transfer he does a domain:info with the 
associated authInfo on a domain name it does not sponsor)
then what should the registry do? Send the secDNS part of the domain:info or 
not?
I believe not sending it creates more harm than benefits, even if the registrar 
did not specify it at login, but clearly this is the core point of our 
disagreement.

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

___
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,

Thank you for the detailed description of your reasoning.  I will leave it that 
we disagree on the purpose of the login services, the need for the server to 
honor the login services for poll messaging, and the impacts in returning 
unsupported responses or response extensions to clients.  On the impact, there 
are two elements to consider including first the XML parser in validating a 
response against the XML schemas, and second is the unmarshalling of the XML to 
a representative object.  A client could disable the XML parser validation and 
move along to the unmarshalling step.  In the unmarshalling step the client 
would need to deal with receipt of unsupported content.  The client could throw 
an exception because the XML (e.g., DOM tree) could not be unmarshalled, ignore 
the unsupported content, or come up with some other representation of the 
unsupported content (e.g., convert to list of XML blobs or DOM objects).  A 
client would need to proactively deal with the unexpected if the server does 
not honor the login services of the client.  With the inclusion of the greeting 
and login services, it seems clear to me that the intention of the protocol is 
not to have the clients deal with the unexpected.  

Since this is not a problem unique to draft-ietf-regext-change-poll, I agree 
that it's best suited to be addressed in a separate Internet Draft that 
addresses service-aware EPP poll messaging.  Is there interest in such a draft 
by the working group?  

Thanks,
  
—
 
JG



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

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

Verisign.com  
On 4/20/18, 1:58 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Wed, Apr 18, 2018, at 15:43, Gould, James wrote:
> This particular thread was started Martin Casanova, who brings up an 
> excellent point that needs to be considered.  Martin, you may want to 
> weigh on this.

You can probably admit that, based on the amount of time the problem exists 
(basically since registries started to use EPP), and the number since then on 
mailing-lists about this problem, that it is not an hot topic.
That does not mean it can not be addressed, but it may mean that 
registries/registrars already found out solutions to this.

> I have the following questions and related thoughts:
> 
> 
>   1.  Do you believe that it is protocol compliant for the server to 
> return something that the client did not explicitly include in the login 
> services?

It is certainly not ideal, but not a big problem either (in this specific 
case for the specific reasons I gave and will give below), and certainly to my 
eyes less a problem than putting format into a  element that is defined 
for human consumption (even more so when you mix both text and XML elements in 
the same  element, which is a peril waiting to happen)

>   2.  What is the purpose of the server’s greeting services and the 
> client’s login services?
>  *   I believe that the server and client services are used to 
> negotiate the common set of supporting services.  The client should not 
> pass services that the server does not support and vice-versa.

It is not a full negotiation since there is only one exchange and only a 
binary result possible (accepting the login or not).

Text says:
"A  element that contains one or more  elements that
  contain namespace URIs representing the objects to be managed
  during the session."

Note that it says objects, not messages or commands.
For me it is more tailored to let the client advertise which objects he 
wants to manipulate at the registry, that is which namespaces will appear in 
its commands.
Imagine a registry handling both domain names and let's say AS number or IP 
blocks, within the same EPP server.
Upon login, some clients may have rights to only manage domains or only 
manage AS numbers. So they advertise what they would like to do, based on 
server greeting. And then the server can act on that.

For me the  definition in RFC5730 does not restrict the notifications 
messages namespaces. So I think from this disagreement, we go then on separate 
ways.

>   3.  What do you do with validating clients?
>  *   The Verisign EPP SDK is one implementation of a validating 
> client, but there can be others.  A validating client would either need 
> to be updated to support the extension or turn off validation and be 
> capable of processing a message that it doesn’t support.  If the 
> protocol is followed, there should be no issue with validating the XML 
> per the supported XML schemas in either the server or the client based 
> on #2.

Again, the validating client can recognize it can not validate the 
notification message 

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

[Patrick Mevzek]

On Wed, Apr 18, 2018, at 15:43, Gould, James wrote:
> This particular thread was started Martin Casanova, who brings up an 
> excellent point that needs to be considered.  Martin, you may want to 
> weigh on this.

You can probably admit that, based on the amount of time the problem exists 
(basically since registries started to use EPP), and the number since then on 
mailing-lists about this problem, that it is not an hot topic.
That does not mean it can not be addressed, but it may mean that 
registries/registrars already found out solutions to this.

> I have the following questions and related thoughts:
> 
> 
>   1.  Do you believe that it is protocol compliant for the server to 
> return something that the client did not explicitly include in the login 
> services?

It is certainly not ideal, but not a big problem either (in this specific case 
for the specific reasons I gave and will give below), and certainly to my eyes 
less a problem than putting format into a  element that is defined for 
human consumption (even more so when you mix both text and XML elements in the 
same  element, which is a peril waiting to happen)

>   2.  What is the purpose of the server’s greeting services and the 
> client’s login services?
>  *   I believe that the server and client services are used to 
> negotiate the common set of supporting services.  The client should not 
> pass services that the server does not support and vice-versa.

It is not a full negotiation since there is only one exchange and only a binary 
result possible (accepting the login or not).

Text says:
"A  element that contains one or more  elements that
  contain namespace URIs representing the objects to be managed
  during the session."

Note that it says objects, not messages or commands.
For me it is more tailored to let the client advertise which objects he wants 
to manipulate at the registry, that is which namespaces will appear in its 
commands.
Imagine a registry handling both domain names and let's say AS number or IP 
blocks, within the same EPP server.
Upon login, some clients may have rights to only manage domains or only manage 
AS numbers. So they advertise what they would like to do, based on server 
greeting. And then the server can act on that.

For me the  definition in RFC5730 does not restrict the notifications 
messages namespaces. So I think from this disagreement, we go then on separate 
ways.

>   3.  What do you do with validating clients?
>  *   The Verisign EPP SDK is one implementation of a validating 
> client, but there can be others.  A validating client would either need 
> to be updated to support the extension or turn off validation and be 
> capable of processing a message that it doesn’t support.  If the 
> protocol is followed, there should be no issue with validating the XML 
> per the supported XML schemas in either the server or the client based 
> on #2.

Again, the validating client can recognize it can not validate the notification 
message (if it does it synchronously which you suppose and for which I already 
said that there are ways to do it differently), and just dump it aside for 
further/later processing and before being updated if you insist on in-session 
immediate validation.

I think you are missing some use cases. Let me share things I have seen in 
various places.

First, from my experience, many registries (I can not give precise numbers I 
would say in the ballpark of 1 among 2) define their own namespace extension 
for notification messages, with more or less format.
I doubt that a validating client such as Verisign EPP SDK would work great in 
this case if it wants to be used for many ccTLDs especially and validate all 
notifications messages. It just does not fit what is happening.
Note that you do not have this problem in gTLDs where far less extensions are 
used.

Of course it would be so much simpler if they were not so many extensions doing 
the same things, but the situation is like it is for now and I doubt this will 
change soon, or anytime in fact.

Another important point: I know multiple EPP clients (mine included for part of 
the following, but I know others too) that exhibit, on purpose, one or more of 
the following traits:

1) not validating incoming EPP messages and even more often not validating 
outgoing ones.
Why? Because when you try to support many registries you tend to observe that 
not all registries are strictly conforming to their own EPP schemas; so it 
happens that you get as client some EPP messages that do not validate at all, 
even if given  by the registry. Of course you will say that this is the server 
fault and that it should be fixed (or the schema amended) and it is of course 
the true technical explanation but then when you have to conduct your business 
you can not wait on the registry to be fixed, your client should not be halted 
by some bogus format, it should find workarounds.

Note that it also happened for core schema. I 

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

[Gould, James]

Patrick,


This particular thread was started Martin Casanova, who brings up an excellent 
point that needs to be considered.  Martin, you may want to weigh on this.

I have the following questions and related thoughts:


  1.  Do you believe that it is protocol compliant for the server to return 
something that the client did not explicitly include in the login services?
 *   I believe that the server should not return something that the client 
does not include in the login services.
  2.  What is the purpose of the server’s greeting services and the client’s 
login services?
 *   I believe that the server and client services are used to negotiate 
the common set of supporting services.  The client should not pass services 
that the server does not support and vice-versa.
  3.  What do you do with validating clients?
 *   The Verisign EPP SDK is one implementation of a validating client, but 
there can be others.  A validating client would either need to be updated to 
support the extension or turn off validation and be capable of processing a 
message that it doesn’t support.  If the protocol is followed, there should be 
no issue with validating the XML per the supported XML schemas in either the 
server or the client based on #2.



You are correct that there are a set of existing EPP extensions that do include 
poll messages (e.g., RGP Poll Mapping, Low Balance Mapping, Launch Phase 
Extension, and object mappings that support transfer poll messages like Email 
Forwarding and Defensive Registration).  This is based on the extensions 
registered in the EPP Extension Registry 
(https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).  With 
the exception of the RGP Poll Mapping and the Low Balance Mapping, the poll 
messages are associated with actions that the client previously took, so it’s 
reasonable to assume that the client supports it.  The Change Poll messages and 
the Maintenance Notice poll messages (draft-sattler-epp-registry-maintenance) 
are not associated with client actions, where there can be no assumption of 
support.  Based on past experience there have been no issues raised that I’m 
aware in returning messages independent of what the client includes in the 
login services, but I don’t believe we can blindly ignore the issue.



Since it looks like Patrick and I are most likely at an impasse, I ask the list 
to weigh in on the two options that include:



  1.  Server does not consider the login services when returning poll messages. 
 Clients may be required to consume poll messages that they don’t support.
  2.  Server considers the login services and filters non-supported extensions 
(object and command / response) from the poll message response with an encoded 
 indicating the extension namepaces not supported.  I include the 
proposed ABNF for the  element below along with a sample of the 
client’s lack of support of the Change Poll extension.


 ABNF for the  element:

msg   = msg-text *LWSP *(not-supported-service *LWSP)
msg-text  = *VCHAR
not-supported-service = “” service-namespace “”
service-namespace = 1*VCHAR

Sample poll message of registry initiated domain update, where the client does 
not support the Change Poll extension with the XML namespace 
“urn:ietf:params:xml:ns:changePoll-1.0”:



  

  
   Command completed successfully; ack to dequeue


  2013-10-22T14:25:57.0Z
  Registry initiated update of domain.
urn:ietf:params:xml:ns:changePoll-1.0

  


  
domain.example
EXAMPLE1-REP



jd1234
sh8013
sh8013
ClientX
ClientY
2012-04-03T22:00:00.0Z
ClientZ
2013-10-22T14:25:57.0Z
2014-04-03T22:00:00.0Z
  


  ABC-12345
  54321-XYZ

  


Thanks,

—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 

On 4/18/18, 2:19 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Apr 16, 2018, at 16:03, Gould, James wrote:

> Thanks for your thoughts of the 4 options presented for handling the

> returning of a poll message that the client does not support based on

> the client login services.  To note, this is not specific to draft-ietf-

> regext-change-poll, so it is an important topic for defining a generic

> solution for all poll messages.



I agree, hence:

1) I change the subject

2) I am also wondering if we are not overdesigning something: obviously

this problem exists since the beginning of EPP and can only have grown much 
worse with the additions of new registries, new registrars and new EPP 
extensions... but as far as I know this subject has never been discussed

and no registrar came complaining