[regext] I-D Action: draft-ietf-regext-unhandled-namespaces-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Extensible Provisioning Protocol (EPP) Unhandled 
Namespaces
Authors : James Gould
  Martin Casanova
Filename: draft-ietf-regext-unhandled-namespaces-04.txt
Pages   : 20
Date: 2020-10-21

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-unhandled-namespaces-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-unhandled-namespaces-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-unhandled-namespaces-04.txt

[Gould, James]

The WGLC for draft-ietf-regext-unhandled-namespaces ended on Friday, October 
16th.  The following are the changes included in 
draft-ietf-regext-unhandled-namespaces-04:



  1.  Changed from Best Current Practice (BCP) to Standards Track based on 
mailing list discussion. – This was agreed to ahead of the WGLC
  2.  Revised the dates in the examples to be more up-to-date. – The use of old 
dates was recognized while doing a final review of the draft by the document 
editors



Please review and provide feedback on anything missed.



Thanks,



--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 10/21/20, 10:11 AM, "regext on behalf of internet-dra...@ietf.org" 
 wrote:





A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.



Title   : Extensible Provisioning Protocol (EPP) Unhandled 
Namespaces

Authors : James Gould

  Martin Casanova

Filename: draft-ietf-regext-unhandled-namespaces-04.txt

Pages   : 20

Date: 2020-10-21



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.





The IETF datatracker status page for this draft is:


https://secure-web.cisco.com/1Uo4ZL1LqMt0n4lILN7LZh4rEVbmOX1fbnBLpQgdlRyAXadRatHuEk5n0rtEvzqABkBXq3WoZdaWKOfiBDmfNbi4iGhd11ncvMjaMiaj0BVFMzVOsxjqsNW4KqITQX-oceNPZZ66yaDSWdwIBMAkQk06a-E7KClTXA51WQVETDEd2x6VBN5nc-FfgL6KkJzRjXWyk8j4y0No_0MKmMNQV0HRgT3QyYDG_HkQlrEgUqmbJTVwc_95ART0sQB6nIRLktQi6e3bm7pIZ5LobSULSSQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F



There is also an HTML version available at:


https://secure-web.cisco.com/17zFqzkELgDB1wyRS03J-ULqcrKQWfq_EW8jDO6EmwH_4C2AoEAvqQDcLnriyGvxvpA5oxnM2kLa7qSCB5JCZfJyt5CzKEZK589kbcRq2aUh5RQiasBQ4XG18eQIY4KYQ6lMMjGjyvQxL3iD0FM0uDmBasQsVBLrlsryfJebeQlzs-Edxc0lYscj4WwQ4JlOmVtm-XNUwczFefXBfgfd-LbBLceufk80Za9NgetgozyOLrZ6UOvjpJnn8iGJxE5QFHUSI32D6PUlQk3S15T9krMx2SHIM4ColjbAkmOyLP9s/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-unhandled-namespaces-04.html



A diff from the previous version is available at:


https://secure-web.cisco.com/1V-3pXnXlPyj2YgcDpha6flp9y-96gNV1ReR-QvTM4NYnOxpIlf1X3ougOooIsYgoggpyPnEzgj1-4SWXXS3KwaimO6JWUmsKki_dHl8AIlWBynlpUyJd_8TvM2zTsz8KvmvTF0EG4i1pFTHQbXYlEBEXxqG0pm3X6S9H4XLVKnYBx9Kb1qSNyjU8PDjcxrxmVYK2ICWTuNfkd45yOcl3wl06aph18e9npZbk4K_rSYRFGbqN64Lklw-hkJO1G7mBy30u2Qtj0EBUBnnjm-dfBXre3dr88xOm_CFAY7T4jeU/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-unhandled-namespaces-04





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/





___

regext mailing list

regext@ietf.org


https://secure-web.cisco.com/1cYbnDwqeJCyE6aIbizwM7NvsMBOYfQZWP2Lg0t3v-cLwgszQd7poDsDCK0EstrnmNUUkQaHkROzKqpzBdyAayQ8hB-gGvQtNKeXdB3G_lmipK3NaWFk45okw-ZjfzvwpQeg9bRdrXez5A4UVdewpI-NxOA4oxUS9Rv8AuURLt5t2l-kuDfJwBIuHBWpEul6O1qZFa8cQsWf3ZLBEEfL-dFHEgsy4cBei9S8Mfnt4T8ciDIsqpdN1MCELmEaXT4jLYEx6tD8QrHWaB1PGkPyELLX4p4hCisIGfCNfrLnclJ4/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-rfc7483bis-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : JSON Responses for the Registration Data Access 
Protocol (RDAP)
Authors : Scott Hollenbeck
  Andy Newton
Filename: draft-ietf-regext-rfc7483bis-04.txt
Pages   : 85
Date: 2020-10-21

Abstract:
   This document describes JSON data structures representing
   registration information maintained by Regional Internet Registries
   (RIRs) and Domain Name Registries (DNRs).  These data structures are
   used to form Registration Data Access Protocol (RDAP) query
   responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7483bis-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rfc7483bis-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-04.txt

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of internet-
> dra...@ietf.org
> Sent: Wednesday, October 21, 2020 10:32 AM
> To: i-d-annou...@ietf.org
> Cc: regext@ietf.org
> Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rfc7483bis-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Registration Protocols Extensions WG of the
> IETF.
>
> Title   : JSON Responses for the Registration Data Access 
> Protocol
> (RDAP)
> Authors : Scott Hollenbeck
>   Andy Newton
>   Filename: draft-ietf-regext-rfc7483bis-04.txt
>   Pages   : 85
>   Date: 2020-10-21
>
> Abstract:
>This document describes JSON data structures representing
>registration information maintained by Regional Internet Registries
>(RIRs) and Domain Name Registries (DNRs).  These data structures are
>used to form Registration Data Access Protocol (RDAP) query
>responses.

This version includes an update to the description of the rdapConformance 
values as discussed on-list. With this, I believe all WG last call comments for 
which we have a sense of direction have been addressed.

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Patrick Mevzek]

James,

On Mon, Oct 19, 2020, at 08:31, Gould, James wrote:
> Considering a default opt-in puts all currently existing EPP 
> clients at risk.
> 
> JG - draft-ietf-regext-unhandled-namespaces addresses an 
> interoperability issue with the server returning extensions that the 
> client specified is not supported.  The  element is already a 
> feature supported by RFC 5730, so this is not something "forced on 
> them".  

You are misreading me or misquoting me.
What your draft forces on is the use of extValue
as NOT described by RFC 5730 hence putting all current clients at risk,
because you "silently" change some core expectations of RFCs 5730+.

I know the problem you are trying to address (I even think I was one of the 
people
raising it in the first place but note that in 20 years or more that EPP 
exists, it obviously 
did not move people so much even if it is a real problem),
I am just trying to explain that this draft
creates an interoperability problem by just changing the semantics of RFC 5730
without letting clients decide if they want it or not, they are forced by the 
server,
hence this default opt-in migration of the current park of EPP clients will
create problems.

> This is not a new feature from a protocol 
> perspective that will cause an interoperability issue.  

It is, because extValue is defined as containing *client* data that created an 
error,
and you are stuffing it with *server* data.

Plus the return code of 1000 + extValue case that I tried to explain, which 
doesn't seem to me
really covered by existing RFCs, so you are just redefining things, hoping that
all clients immediately will just implement your draft and hence everything is 
fine
but unfortunately that is not what is going to happen...

Maybe all of this is fine, redesigning EPP from scratch today, I could agree
with all this. But I am just pointing out that specifications already exist
and are NOT aligned with the way you try to use them in this draft. This is the
interoperability problem, not the features themselves, the fact that you add
them on top of things where they do not fit 100%.

> There is no normative language in RFC 5730 that would 
> prohibit the use of  for the use case covered in 
> draft-ietf-regext-unhandled-namespaces.   

I believe there is and I quoted you so. Note the mention of "client-provided 
element", but
you seem to just ignore that point.

A specification can not list everything prohibited. It lists what is allowed
(and it says clearly "client-provided element") and then as a safe view you can 
expect
the rest not to be allowed.

> There may be clients out there that will consider value/extValue 
> only for error
> return codes (>=2000) and will get confused when getting back 1000 
> but with extValue
> as this draft calls for.
> 
> JG - RFC 5730 did not envision this case, which is the point with the 
> standardization of draft-ietf-regext-unhandled-namespaces.  

Which is the core of the problem and the interoperability risk.
You redefine core parts of RFC 5730 without taking into accounts that clients
may not be aware of your change (your draft) and hence will have problems
if the server forces that new view on them, without any possible negotiation.

At this point it seems we are just repeating our own arguments on both side,
so I don't think either will move their position and we have to keep our
disagreement, which is fine.

I wanted to record my disagreement on this draft during WGLC, that is all.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-secure-authinfo-transfer-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Extensible Provisioning Protocol (EPP) Secure 
Authorization Information for Transfer
Authors : James Gould
  Richard Wilhelm
Filename: draft-ietf-regext-secure-authinfo-transfer-04.txt
Pages   : 28
Date: 2020-10-21

Abstract:
   The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
   use of authorization information to authorize a transfer.  The
   authorization information is object-specific and has been defined in
   the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
   Mapping, in RFC 5733, as password-based authorization information.
   Other authorization mechanisms can be used, but in practice the
   password-based authorization information has been used at the time of
   object create, managed with the object update, and used to authorize
   an object transfer request.  What has not been fully considered is
   the security of the authorization information that includes the
   complexity of the authorization information, the time-to-live (TTL)
   of the authorization information, and where and how the authorization
   information is stored.  This document defines an operational
   practice, using the EPP RFCs, that leverages the use of strong random
   authorization information values that are short-lived, that are not
   stored by the client, and that are stored using a cryptographic hash
   by the server to provide for secure authorization information used
   for transfers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-secure-authinfo-transfer-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-secure-authinfo-transfer-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] FW: I-D Action: draft-ietf-regext-secure-authinfo-transfer-04.txt

[Gould, James]

The WGLC for draft-ietf-regext-secure-authinfo-transfer ended on Friday, 
October 16th.  The following are the changes included in 
draft-ietf-regext-secure-authinfo-transfer-04:



  1.  Converted from xml2rfc v2 to v3.
  2.  Updated Acknowledgements to match the approach taken by the RFC Editor 
with draft-ietf-regext-login-security.
  3.  Changed from Best Current Practice (BCP) to Standards Track based on 
mailing list discussion.


Please review and provide feedback on anything missed.

Thanks,




--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 10/21/20, 3:29 PM, "regext on behalf of internet-dra...@ietf.org" 
 wrote:





A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.



Title   : Extensible Provisioning Protocol (EPP) Secure 
Authorization Information for Transfer

Authors : James Gould

  Richard Wilhelm

Filename: 
draft-ietf-regext-secure-authinfo-transfer-04.txt

Pages   : 28

Date: 2020-10-21



Abstract:

   The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the

   use of authorization information to authorize a transfer.  The

   authorization information is object-specific and has been defined in

   the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact

   Mapping, in RFC 5733, as password-based authorization information.

   Other authorization mechanisms can be used, but in practice the

   password-based authorization information has been used at the time of

   object create, managed with the object update, and used to authorize

   an object transfer request.  What has not been fully considered is

   the security of the authorization information that includes the

   complexity of the authorization information, the time-to-live (TTL)

   of the authorization information, and where and how the authorization

   information is stored.  This document defines an operational

   practice, using the EPP RFCs, that leverages the use of strong random

   authorization information values that are short-lived, that are not

   stored by the client, and that are stored using a cryptographic hash

   by the server to provide for secure authorization information used

   for transfers.





The IETF datatracker status page for this draft is:


https://secure-web.cisco.com/1EgRjgku8x3Km5JfhgQuWfmGV6lwNhSwZOtZ2lDscdUkSS52HJ3sTfBo7_cMRE7DUiv_QgMaeIkQdUfaACitDc5RyhnI93rUeCJB2tFkZy_nWr-PfZAYj5vwXUNQh718p_1Pt5qyDX0hbDYTRl-yPzyhRPYGDCKPurQ-9eNdDWNl3n3yZLljD-qJTRlSDDCiWeCmd1DDJL-Nuy4RgUmhMfAJ4f016F6eVVugCeu2x-ywUMssOKMTinUQ3Z_2D6Wy39RKS3s0JJvNGgDuqkkHfvA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F



There is also an HTML version available at:


https://secure-web.cisco.com/1g-oFG2Rb0q9OudOZLHcWqayl3iWcDsYYYKy_6mZX5TsIDTEMFbpB8B8L4mb9TWJ-vFrG2RHBB7bsYZ2z_-XKj-6BddfRt9vXlGSTzJx474CwTJvAVoCwjlVA8jxti_HkcFOeSzwKetNXaIhmsJZ2aPEe3VyhHqJJZGabO40l1olRshbuxP_OHRZbmpOqQ5xw55XgLktAb2HU4e2cnkdpaDV_OU13sILJk3y7ygn1ketFtPURul2FndhvLi5xlp8yfh4qF3tJkGnzZjyquShCwkLTcqXHIhpBByxMjXKAWvw/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-secure-authinfo-transfer-04.html



A diff from the previous version is available at:


https://secure-web.cisco.com/1HzsdHG6E7e8J9WSPH21O9ZCeVdqvKbyoCVxIuh_fnzuTDUjS0XmsEJ1q1BmFd_kpxgEjtGnAGIV55-i56OxtBOQV6XvwaYkP-g6ThI4FE9vJToZ_G0_kQLQz3kof8i7NRmB6Qzd0nXBM61logPXuDrs20JR9HIOd4vf7aGyHF73BgclQZi2X8pRvaBc-KiZeps-bPXnjE3g3B_5e70EUOiFOBOFlHdwAtuUCwHF93nB6lmkNqxi_pWcDNMpfDxVlclRNn3L8-vgt7P1TXHC_Yle0wx2fbGTSUx6JO2rnfu4/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-secure-authinfo-transfer-04





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/





___

regext mailing list

regext@ietf.org


https://secure-web.cisco.com/17C2eFpLRJfccIq47DXAl5UQJCNzM_o4m5jyYP_s06DJOGkItUWrzLbgT9LA8u1ANCu2TUWFe73Vrrey46g4bls0KvUQpstLcHWLZA8iaFc1iibb18LEYLg2-QiVXpbGqvf1_s4TJXy8FMCpRpVFM2gZ_xJmXUuVt7_rsMX30M7kJTo-3THwoYhypnSxpHF1GhIV92GlKFED3WfXO50NDzyeNAukn5Bf6amWblGqyhPAzIEDB1PhHPTcCWI_NAm-ePr9DZbr3nsZhA-g2SiIi1yvh4EwL1_qsiWX3Y2Juiio/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Gould, James]

Patrick,

I provide me responses embedded below.

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 

On 10/21/20, 12:22 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

James,

On Mon, Oct 19, 2020, at 08:31, Gould, James wrote:
> Considering a default opt-in puts all currently existing EPP 
> clients at risk.
> 
> JG - draft-ietf-regext-unhandled-namespaces addresses an 
> interoperability issue with the server returning extensions that the 
> client specified is not supported.  The  element is already a 
> feature supported by RFC 5730, so this is not something "forced on 
> them".  

You are misreading me or misquoting me.
What your draft forces on is the use of extValue
as NOT described by RFC 5730 hence putting all current clients at risk,
because you "silently" change some core expectations of RFCs 5730+.

I know the problem you are trying to address (I even think I was one of the 
people
raising it in the first place but note that in 20 years or more that EPP 
exists, it obviously 
did not move people so much even if it is a real problem),
I am just trying to explain that this draft
creates an interoperability problem by just changing the semantics of RFC 
5730
without letting clients decide if they want it or not, they are forced by 
the server,
hence this default opt-in migration of the current park of EPP clients will
create problems.

JG - I'm not clear of the risk of returning information in the  
element to clients.  There won't be a schema validation error like the case of 
returning a non-supported extension to a validating client.  There won't be a 
marshaling error for the client, since unmarshaling the  in the 
 element should already be supported.  The most likely issue is that 
the client will ignore the information, which does not pose an operational 
risk.  I've implemented draft-ietf-regext-unhandled-namespaces on the server 
side and in a validating client within the Verisign EPP SDK, and I don't see 
any potential risk for the client.  Martin implemented 
draft-ietf-regext-unhandled-namespaces in a Production server and hasn't come 
across any reported client-side issues.  A server can choose to implement 
draft-ietf-regext-unhandled-namespaces and when doing so should notify the 
clients ahead of time, so this is not something that would be thrown onto 
clients without notice.  

> This is not a new feature from a protocol 
> perspective that will cause an interoperability issue.  

It is, because extValue is defined as containing *client* data that created 
an error,
and you are stuffing it with *server* data.

Plus the return code of 1000 + extValue case that I tried to explain, which 
doesn't seem to me
really covered by existing RFCs, so you are just redefining things, hoping 
that
all clients immediately will just implement your draft and hence everything 
is fine
but unfortunately that is not what is going to happen...

Maybe all of this is fine, redesigning EPP from scratch today, I could agree
with all this. But I am just pointing out that specifications already exist
and are NOT aligned with the way you try to use them in this draft. This is 
the
interoperability problem, not the features themselves, the fact that you add
them on top of things where they do not fit 100%.

JG - RFC 5730 did not foresee the issue associated with returning poll messages 
to clients that don't support the extensions in the poll message.  We discussed 
this at length at multiple REGEXT meetings, and the best solution to this 
problem is defined in draft-ietf-regext-unhandled-namespaces.  A draft can be 
defined to cover the usage of an existing element in the RFC for a specific 
feature, which in this case is to enable servers to comply with the EPP RFC for 
poll messages and when there is the need to return additional information to 
the client (e.g., DNSSEC information).  

> There is no normative language in RFC 5730 that would 
> prohibit the use of  for the use case covered in 
> draft-ietf-regext-unhandled-namespaces.   

I believe there is and I quoted you so. Note the mention of 
"client-provided element", but
you seem to just ignore that point.

A specification can not list everything prohibited. It lists what is allowed
(and it says clearly "client-provided element") and then as a safe view you 
can expect
the rest not to be allowed.

JG - Yes for an error it makes sense to include the "client-provided element".  
The case defined in draft-ietf-regext-unhandled-namespaces is not an error and 
the use of the  element for this use case is defined in 
draft-ietf-regext-unhandled-namespaces.  The description of the element does 
not prohibit the use of the element to address a specific well-defined probl

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Patrick Mevzek]

On Wed, Oct 21, 2020, at 15:56, Gould, James wrote:
> JG - I'm not clear of the risk of returning information in the 
>  element to clients.  There won't be a schema validation 
> error like the case of returning a non-supported extension to a 
> validating client.  There won't be a marshaling error for the client, 
> since unmarshaling the  in the  element should 
> already be supported.  The most likely issue is that the client will 
> ignore the information, which does not pose an operational risk.

That is purely a judgment call.
The specifications say: this part is filled with content from client.
This is clear and non-ambiguous.

Hence a client parsing it is expecting to see there... data it already sent
since it is the client, per the specification. You can say it is a bad client
if it starts to misbehave because it sees other things there, but you can't 
also know or take into account all servers and clients out there, and their
specificities.

> I've 
> implemented draft-ietf-regext-unhandled-namespaces on the server side 
> and in a validating client within the Verisign EPP SDK, and I don't see 
> any potential risk for the client. 

Again, you take as granted that everyone will update their clients at the moment
your specification becomes RFC (That won't happen as it doesn't happen for any 
RFC, no matter how good it is) or the fact that all clients work the
same as yours.

And for all clients not updated or doing things differently than yours, this 
draft may break them as soon as the EPP servers they connect to implement it.

> Martin implemented 
> draft-ietf-regext-unhandled-namespaces in a Production server and 
> hasn't come across any reported client-side issues.  A server can 
> choose to implement draft-ietf-regext-unhandled-namespaces and when 
> doing so should notify the clients ahead of time, so this is not 
> something that would be thrown onto clients without notice. 

Yes, in theory.
In practice, deployments do not happen like that, unfortunately.
  
I am just trying to give some data about past experiences.

>  A draft can be defined to 
> cover the usage of an existing element in the RFC for a specific 
> feature,

No, you are explicitly redefining usage as described in RFC 5730.

It looks minor in your eyes, not in mine, so our vision will remain separate.

> JG - Yes for an error it makes sense to include the "client-provided 
> element".  The case defined in draft-ietf-regext-unhandled-namespaces 
> is not an error and the use of the  element for this use case 
> is defined in draft-ietf-regext-unhandled-namespaces. 

... and not defined in RFC 5730 which is the problem for every client out there
that won't or can't or not yet upgrade to your specification.

> The description 
> of the element does not prohibit the use of the element to address a 
> specific well-defined problem solved by 
> draft-ietf-regext-unhandled-namespaces.  

Yes, it does prohibit because it says "client provided" and you are putting
things in it that are not "client provided".
Your specification redefines core parts of the current EPP specification.

And to be honest, one moment you say "RFC 5730 couldn't predict the need
to handle undefined namespaces hence does not speak about them" (obviously)
so that you can justify overriding one of its specification
and here you say "RFC 5730 does not prohibit what this draft is trying to do
(as if RFC 5730 could have known that in advance)". I believe this is one
argument and its opposite so difficult to have both at the same time, but 
maybe I am just getting at my limits in English, which is very possible.
 
> JG - We can agree to disagree on the value and risks associated with 
> draft-ietf-regext-unhandled-namespaces.  The Document Shepherd can 
> include a reference to your disagreement in his writeup, but I don't 
> believe there is consensus to make a change.

I am not saying otherwise and I sure don't expect a change because
it is already presented as the best or unique solution on the problem, it 
has been discussed extensively and to me this specific solution creates its
own set of problems, hence my disagreement.

If I am the only one seeing that the text redefines RFC 5730 in 
different and incompatible ways, and the only one believing that not all 
clients will suddenly
be upgraded to use this specification (as if all EPP servers out there will
be updated...), then so be it, it does not really matter.

Again, I am not trying to convince anyone, I know it won't happen,
I just phrased my justifications on the problems I see.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext