Subject: [regext] New Version Notification for draft-gould-casanova-regext-unhandled-namespaces-00.txt

From: "Gould, James" <[email-masked]>
Date: Mon, 1 Oct 2018 14:34:22 +0000

Hi,

Based on an action item from IETF-102, Martin Casanova and I created the BCP draft-gould-casanova-regext-unhandled-namespaces to describe an approach for EPP unhandled namespaces.  Please review and provide feedback.  We would like to have an agenda item (10 minutes) at the IETF-103 REGEXT WG meeting to introduce and discuss the draft.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 10/1/18, 10:20 AM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-gould-casanova-regext-unhandled-namespaces-00.txt
    has been successfully submitted by James Gould and posted to the
    IETF repository.
    
    Name:		draft-gould-casanova-regext-unhandled-namespaces
    Revision:	00
    Title:		Extensible Provisioning Protocol (EPP) Unhandled Namespaces
    Document date:	2018-10-01
    Group:		Individual Submission
    Pages:		18
    URL:            https://www.ietf.org/internet-drafts/draft-gould-casanova-regext-unhandled-namespaces-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/
    Htmlized:       https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-gould-casanova-regext-unhandled-namespaces

    Abstract:
       The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
       includes a method for the client and server to determine the objects
       to be managed during a session and the object extensions to be used
       during a session.  The services are identified using namespace URIs.
       How should the server handle service data that needs to be returned
       in the response when the client does not support the required service
       namespace URI, which is referred to as an unhandled namespace?  An
       unhandled namespace is a significant issue for the processing of RFC
       5730 poll messages, since poll messages are inserted by the server
       prior to knowing the supported client services, and the client needs
       to be capable of processing all poll messages.  This document defines
       an operational practice that enables the server to return information
       associated with unhandled namespace URIs that is compliant with the
       negotiated services defined in RFC 5730.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

---

From: Martin Casanova <[email-masked]>
Date: Thu, 4 Oct 2018 16:37:09 +0200

Hi all

This is a programmatic approach to let the client know that there is
some information in an EPP extension that the server would like to
communicate to the client.
The intent is, that the client would include the missing extension in
the login services at login in case automatic processing is desired
(parsing, validating). Otherwise the <extValue> part can still simply be
ignored without any downside for the client.

In any case the information is there, so it can also be processed at a
later point in time if the message has been persisted. This is a benefit
because once a poll message was polled and acknowledged, there is no way
for the client to request the same poll message again. We are planing to
implement poll messages with the draft-ietf-regext-change-poll extension
for the following registry initiated use cases where the registrar is
not directly involved in:

1. Changes on DS records through our automated DNSSec provisioning
process according to RFC 7344 and RFC 8078
2. Deactivation and ultimately Deletion of domain names that play a role
in distributing malware or for other (legal) reasons
3. Other Transform commands like changing of authinfo or name server by
the registry

In some cases sending the poll message without the relevant extensions
would not make much sense since the registrar would have to guess why
the poll message was sent and what actually changed.
If you can agree to this reasoning please provide some feedback but any
contribution to the discussion is welcome :)

Thanks,

Martin Casanova

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

On 01.10.2018 16:34, Gould, James wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

--