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