Re: [regext] Unhandled namespaces IETF 102 flashback

["Gould, James" <[e-mail]>]

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

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

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

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

From: regext <[e-mail]> on behalf of Martin Casanova <[e-mail]>
Date: Wednesday, October 17, 2018 at 11:51 AM
To: "[e-mail]" <[e-mail]>
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

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?

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

Martin Casanova, Domain Applications

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

phone [phone], direct [phone]

[e-mail]<mailto:[e-mail]>, www.switch.ch<http://www.switch.ch>



Working for a better digital world