Subject: [regext] Unhandled namespaces IETF 102 flashback

From: Martin Casanova <[email-masked]>
Date: Wed, 17 Oct 2018 17:50:21 +0200

Hello

I was viewing the discussions about the unhandled namespaces in the last
IETF meeting (102 in Montreal) again to reflect a bit more on the topic.

starting at minute 46:46

https://www.youtube.com/watch?v=qTJsVCM5Bmo

starting at minute  38:40

https://www.youtube.com/watch?v=2g44uJWtB2M

I would like to comment 4 statements(analogous) that were made in this
session:

1. To make sure the server remains RFC compliant when sending poll
messages with extensions it should not accept sessions where the client
did not specify all server supported extensions. (Server supported
language: ABC, Client only A and B)
    - This is a rather strict interpretation.  Of what I heard, some
registries allow the session anyway but use only extensions of the
common subset of client login and greeting in their reposes. Other
extensions are omitted in responses. Commands of other extensions that
the server does not support are answered with 2307 "Unimplemented object
service" but for that to happen the session must have been established.
Who is handling it this way, lets say for the DNSSec extension? 

2. Poll Messages are informational. Nothing important should be sent
over this channel.
- I think this could hinder the further development of all poll message
related extensions. The importance of the whole poll mechanism is
undermined by saying that the information in poll messages is anyway
only optional to process and not so "important". Maybe we will have even
more important stuff to communicate in the future via this channel. (low
balance etc.)

3. Poll messages could be purged if they were not delivered after a
certain time.
- This is ok for poll messages as a whole when they are not picked up at
all but it does not allow to distinguish between "normal" poll messages
and poll messages with extensions. In case you wanted to purge the
problematic messages with extensions there are the following problems:
- Different queues for messages with different extensions are not
foreseen by the RFC's and are also more complicated to implement. What
about messages that use 2 extensions of which only one was configured at
login ?
- An approach with only one queue would have to provide a mechanism to
the client to skip unwanted messages, so normal messages are not
blocked. This is also not foreseen by the RFC 5730.

4. The problem of breaking clients should never occur in production
because clients can prepare them selfs in OT&E
- Unfortunately there is no standard way for clients to trigger normally
"registry initiated" poll messages. There are some ideas to make them
testable but all of them are rather work intensive for the registry and
the registrar and/or require extensive out of band documentation. A
mechanism like described in the draft
draft-gould-casanova-regext-unhandled-namespaces helps registrars to
cope with new extensions because there is no strict deadline. They
prepare their client when they think they have the resources or the need
to process the new extensions in an automated way. In the mean time they
can be assured that nothing bad happens, no client breaking, no login
denied...

Thoughts ?

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
[email-masked], www.switch.ch 
 
Working for a better digital world

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Wed, 17 Oct 2018 18:30:39 +0200

Hello Martin,

> I would like to comment 4 statements(analogous) that were made in this

Overall, I agree that all four statements are problematic at best
(details inline below).

> registries allow the session anyway

This is what we're doing in our TANGO system. In today's environment with
thousands of TLDs, it's unrealistic to demand that every registrar keeps
track of every single new extension (or version thereof) introduced by a
registry, which they would have to do (just to enable their client to log
in) if the above was implemented.

> but use only extensions of the common
> subset of client login and greeting in their reposes. Other extensions
> are omitted in responses. Commands of other extensions that the server
> does not support are answered with 2307 "Unimplemented object service"
> but for that to happen the session must have been established. Who is
> handling it this way, lets say for the DNSSec extension? 

In an ideal world, this would be the case across the board. TANGO does
that for the supported fee extension (responses won't contain it unless
the registrar specified in in the EPP login), but e.g. never omits DNSSEC
data from <domain:info> responses, even if the registrar didn't announce
support for it.

> 2. Poll Messages are informational. Nothing important should be sent over
> this channel.
> undermined by saying that the information in poll messages is anyway only
> optional to process and not so "important". Maybe we will have even more
> important stuff to communicate in the future via this channel. (low
> balance etc.)

Transfer-out messages are important; not only do they enable registrars
to maintain a proper inventory, they also allow registrants to react in
time should a domain be transferred away illegitimately. Transfer-in
messages are maybe slightly less important, since a client can always
check for the outcome of a transfer after a timeout, but this kind of
busy waiting isn't exactly state-of-the-art.

Since there is no other way in EPP to get that kind of information, poll
messages are essential and hardly just informational.

> 3. Poll messages could be purged if they were not delivered after a

While this could be seen as a solution for getting rid of unparseable
messages left in the queue by the registrar (blocking the reception of
others), I'm against the concept in general. The queue should always be
emptied at the discretion of the registrar.

> because clients can prepare them selfs in OT&E

Again, with thousands of TLDs, it's ridiculous to assume that registrars
can constantly test and re-test their client systems in time for
production updates in all cases. Extensions, especially non-mandatory
ones, should therefore be rolled out in a fashion that ideally doesn't
affect the functionality of legacy clients not seeking the use any of the
new features, even if they don't retest in OT&E.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Gould, James" <[email-masked]>
Date: Wed, 17 Oct 2018 17:52:58 +0000

Martin,

Thanks for posting the flashback with the statements from the IETF-102 session.  I provide my feedback to the statements embedded below.

Jim and Antoin, I would like 10 minutes at the REGEXT meeting at IETF-103 to introduce and discuss the newly published draft-gould-casanova-regext-unhandled-namespaces.  Since I’m on the topic of the REGEXT agenda, I would also like 10 minutes to introduce and discuss the newly published draft-gould-regext-login-security-policy.  Just let me know how much time is available and I’ll accommodate.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Martin Casanova <[email-masked]>
Date: Wednesday, October 17, 2018 at 11:51 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] [regext] Unhandled namespaces IETF 102 flashback

Hello

I was viewing the discussions about the unhandled namespaces in the last IETF meeting (102 in Montreal) again to reflect a bit more on the topic.

starting at minute 46:46

starting at minute  38:40

I would like to comment 4 statements (analogous) that were made in this session:

1. To make sure the server remains RFC compliant when sending poll messages with extensions it should not accept sessions where the client did not specify all server supported extensions. (Server supported language: ABC, Client only A and B)
    - This is a rather strict interpretation.  Of what I heard, some registries allow the session anyway but use only extensions of the common subset of client login and greeting in their reposes. Other extensions are omitted in responses. Commands of other extensions that the server does not support are answered with 2307 "Unimplemented object service" but for that to happen the session must have been established. Who is handling it this way, lets say for the DNSSec extension?

JG – I believe this is much too strict and doesn’t really match what seems to be the intent of the service negotiation in RFC 5730, where the server states what services it supports (are available) and the client states what will be used in the session (selects what it will use).  Requiring that the client supports all of the server services is not a workable option.

2. Poll Messages are informational. Nothing important should be sent over this channel.
- I think this could hinder the further development of all poll message related extensions. The importance of the whole poll mechanism is undermined by saying that the information in poll messages is anyway only optional to process and not so "important". Maybe we will have even more important stuff to communicate in the future via this channel. (low balance etc.)

JG – I find transfer poll messages, low balance poll messages, and server-side changes via the change poll message as pretty important.  The poll queue is an important feature of EPP to support in-band communication from the server to the client that should be used for relevant and important information.  What would be the appropriate channel for important information?  I find EPP as a better option than e-mail.

3. Poll messages could be purged if they were not delivered after a certain time.
- This is ok for poll messages as a whole when they are not picked up at all but it does not allow to distinguish between "normal" poll messages and poll messages with extensions. In case you wanted to purge the problematic messages with extensions there are the following problems:
- Different queues for messages with different extensions are not foreseen by the RFC's and are also more complicated to implement. What about messages that use 2 extensions of which only one was configured at login ?
- An approach with only one queue would have to provide a mechanism to the client to skip unwanted messages, so normal messages are not blocked. This is also not foreseen by the RFC 5730.

JG – Yes, poll messages can and do get deleted by the server after a certain period of time, but the point is that clients should be capable of consuming all messages in a timely basis.  EPP is an extensible protocol (object and command / response), so every poll message is using an extension of some sort.  I don’t see any difference between a “normal” poll message and a poll message with extensions.  Having different queues for a client based on the extensions does not scale at all.  The poll queue should be a communication channel for an extensible set of messages.  Adding the capability of skipping messages and blocked messages is not what is defined in RFC 5730, so I don’t view that as a realistic option.

4. The problem of breaking clients should never occur in production because clients can prepare them selfs in OT&E
- Unfortunately there is no standard way for clients to trigger normally "registry initiated" poll messages. There are some ideas to make them testable but all of them are rather work intensive for the registry and the registrar and/or require extensive out of band documentation. A mechanism like described in the draft draft-gould-casanova-regext-unhandled-namespaces helps registrars to cope with new extensions because there is no strict deadline. They prepare their client when they think they have the resources or the need to process the new extensions in an automated way. In the mean time they can be assured that nothing bad happens, no client breaking, no login denied...

JG – I don’t believe we should assume that a problem will not occur because registrars prepare against OT&E.  This is a protocol question and not a process question, where we have poll messages that need to be delivered to the client that the client explicitly doesn’t support (whole message or a portion of the message).  The draft-gould-casanova-regext-unhandled-namespaces draft provides a solution to the protocol question that enables all clients to consume all poll messages, without filtering out information, and in compliance with the current protocol.

Thoughts ?

Martin

---

SWITCH

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>