Subject: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces

From: Antoin Verschuren <[email-masked]>
Date: Fri, 24 Jan 2020 15:50:52 +0100

This is a formal adoption request for Extensible Provisioning Protocol (EPP) Unhandled Namespaces: 
https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/

Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review text, or be a document shepherd.

This call for adoption ends Friday, 7 February 2020.

If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin

---

From: Roger D Carney <[email-masked]>
Date: Fri, 24 Jan 2020 16:16:22 +0000

+1 to add to milestones.

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Antoin Verschuren
Sent: Friday, January 24, 2020 8:51 AM
To: regext <[email-masked]>
Subject: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces

Notice: This email is from an external sender.

Thanks,

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Sat, 25 Jan 2020 11:39:25 +0100

I support adoption.

Mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Gould, James" <[email-masked]>
Date: Tue, 28 Jan 2020 16:51:22 +0000

Patrick,

My feedback to your comments are included below.  

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

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

On 1/28/20, 2:11 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Fri, Jan 24, 2020, at 09:50, Antoin Verschuren wrote:
    > Please review this draft to see if you think it is suitable for 
    > adoption by REGEXT, and comment to the list, clearly stating your view.
    
    The subject can be interesting to the working group and might warrant an RFC
    (although registries and registrars worked for 20 years without trouble
    in handling this case, so one might imagine it is maybe too late or
    not a big enough problem).

JG - This topic came up with the introduction of a new poll message with the Change Poll Message in https://tools.ietf.org/html/rfc8590.  It's primarily an issue associated with the poll queue, where it's unclear how the server can introduce a new poll message without breaking the protocol.  I don't believe anyone can make the case that this is not a protocol issue.  The practice outlined in draft-gould-casanova-regext-unhandled-namespaces provides a concrete solution.     
    
    However, as discussed previously, in its current form this draft will
    introduce interoperability problems[1], so this just exchanges one problem with another.
    
    So I am mildly convinced work is required, and mildly unconvinced that
    the draft as it stands completely address the issue.
    
    [1] TL;DR: a registrar has no way to automatically discover
    a registry is using the mechanism outlined in this document,
    as not announced in the greeting part.

JG - draft-gould-casanova-regext-unhandled-namespaces addresses a protocol and subsequently an interoperability issue, since the server will be capable of fully honoring the services the client includes in the login command.  I'm not sure how a practice that fully follows the EPP RFCs and fully honors the client login services will introduce an interoperability problem based on the lack of discoverability of the practice in the greeting.        
    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 28 Jan 2020 12:13:03 -0500

On Tue, Jan 28, 2020, at 11:51, Gould, James wrote:
> JG - This topic came up with the introduction of a new poll message 
> with the Change Poll Message in https://tools.ietf.org/html/rfc8590.  

But the problem existed far before it (and it didn't bother, for
good or bad reasons)

One case among others (putting aside the problem of transfers for domains with attached DNSSEC configuration):

- registrarA has domainX with secDNS data
- registrarB transfers the domain; registrarB login to EPP server DOES NOT include
secDNS-1.1 as it is optional
- registrarB does a domain:info, now what to expect in reply?
Should it include the secDNS part or not?
This is the whole debate, and the problem is not trivial.
Notifications are just a specific case among the whole problem
(which is truly more just about feature negotiation at session beginning).

Notifications are asynchronous. They can be produced at time T1 where
registrar was having an EPP session where extension X1 was negotiated, but
the message can be retrieved far later, at time T2, where registrar has
another EPP session where that extension was not used. Now, the notification
needs to be processed in some way because it blocks all the queue
otherwise.

> It's primarily an issue associated with the poll queue, where it's 
> unclear how the server can introduce a new poll message without 
> breaking the protocol.

The problem is ABSOLUTELY NOT just tied to poll messages. I would prefer
all parts of the problem to be addressed, OR at the very least if not
possible then the document clearly mentioning it deals only with part
of the problem and leaves the rest for sometimes later/somewhere else.
But in my mind that lowers its usefulness.

> JG - draft-gould-casanova-regext-unhandled-namespaces addresses a 
> protocol and subsequently an interoperability issue,

(that no one took care to document or even raise on the mailing list
for like 16 years...)

> since the server 
> will be capable of fully honoring the services the client includes in 
> the login command.  I'm not sure how a practice that fully follows the 
> EPP RFCs and fully honors the client login services will introduce an 
> interoperability problem based on the lack of discoverability of the 
> practice in the greeting.  

Again: because the client has no way to know if the registry it is talking
to right now, implements this "extension" or not. So it has no way of knowing
what to do with the <extValue> it gets (if it should start to parse them,
if it should start to be worried to get extValue content when it didn't have
any in the "past", etc.)
(and no, parsing of "reason" node does not count as discoverability)
And clients, are clients to multiple registries. They have to accommodate all
of them, even if they do their internal hall of fame/shame based on their
preferences, they still have to accommodate if they want to do business...

I am sure you can imagine that not all registries will implement it even
if it becomes a full fledged RFC, so
registrars have to discriminate. If they can not, they have to do heuristics.
This makes the current situation more fragile, and hence poses an interoperability
problem (and will, in my view, lessen the probability that many registries
will implement it, feeling that the status quo - again not worrisome enough
for 16 years for anyone to work on that before - while not perfect is certainly
good enough and not worse than what is proposed in the draft).

If you say: big deal, registrars can just ignore the <extValue> content in that case
then: why even bothering sending it?

I will leave it at that for now, and see further discussions if the
draft is adopted by the working group.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 28 Jan 2020 18:36:10 +0000

Patrick,

My comments are embedded below.

-- 
 
JG

James Gould
Distinguished Engineer

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

On 1/28/20, 12:13 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

JG - No, according to the RFC 5730 (based on the login services), and RFC 5910 (based on the text in section 2), the server should not include the secDNS information.  draft-gould-casanova-regext-unhandled-namespaces provides an option for the server to return the information that will not break registrarB by returning something that registrarB does not support, per the login services.

JG - Yes, you are correct.  Should the registry return the poll message that registrar at T2 clearly does not support, which represents a poison message if the client is unable to process it?   The poison message scenario is addressed by implementing draft-gould-casanova-regext-unhandled-namespaces. 

JG - draft-gould-casanova-regext-unhandled-namespaces does address both general EPP responses in section 4 (https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces-00#section-4 ) and poll messages in section 5 (https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces-00#section-5).  What I meant was that the poll queue was the primary issue that triggered creating draft-gould-casanova-regext-unhandled-namespaces, but we did address both cases.  Let me know whether anything is missing. 

    

JG - If signaling is important for the client with the server's implementation of a BCP such as draft-gould-casanova-regext-unhandled-namespaces and draft-gould-regext-secure-authinfo-transfer, how about defining a namespace URI for the BCP which can be used in an <extURI> element in the greeting by the server and in the login command by the client.  In the case of draft-gould-casanova-regext-unhandled-namespaces, inclusion or exclusion of the URI in the login command services would not change anything for the server.  Does the definition of a namespace URI for a BCP draft that is included in an <extURI> element of the greeting services and login services make sense to you?

JG - It's more important to send it for a poll message so that information is not lost and the poll message can be safely acknowledged.  Cases like returning secDNS can be done via the <extValue> content, based on draft-gould-casanova-regext-unhandled-namespaces, instead of a server deciding not returning it.  The content is not expected to be automatically parsed and processed, but the existence of an <extValue> element in the response should signal the client that they may need to add support for an extension that the server does support.  It may be the case that the client does support the extension, but their login services is incorrect, so the <extValue> element would signal the client that they need to update their login services.  

    -- 
      Patrick Mevzek
      [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 28 Jan 2020 18:40:58 +0000

> Sent: Friday, January 24, 2020 9:51 AM
> Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-gould-casanova-
> regext-unhandled-namespaces
>
> Please review this draft to see if you think it is suitable for adoption by
> REGEXT, and comment to the list, clearly stating your view.
>

I support adoption of this draft. I'm willing to review it and contribute text as needed.

Scott