[regext] Unhandled namespaces IETF 102 flashback

[Martin Casanova <[e-mail]>]

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 [phone], direct [phone]
[e-mail], www.switch.ch 
 
Working for a better digital world