Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Roger D Carney]

Good Afternoon,

+1.

We agree that that we should move forward with the current 
draft-ietf-regext-change-poll draft and move this discussion along another path.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Friday, May 04, 2018 9:16 AM
To: James Galvin 
Cc: Patrick Mevzek ; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to 
leave the EPP server sending unsupported responses (mapping extension and / or 
command response extensions) to a client based on the login services up to a 
separate draft.

This comes down to the interpretation of how the server should handle the login 
services of the client in creating responses.  EPP extensions like the DNSSEC 
extension (RFC 5910) leverages the login services in the migration from RFC 
4310 to RFC 5910, since the info response may include the DNSSEC extension if 
there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of 
the DNSSEC extension is based on the login services.  Similar functionality 
exists within draft-ietf-regext-epp-fees in determining if and which version of 
the extension to return to the client.  Poll messages are unique since they are 
inserted ahead of time by the server without knowledge of what the client does 
support, and therefore runs the risk of coming across a message that the client 
does not support based on the login services.  Clients may or may not be able 
to handle the parsing and unmarshalling of unsupported extensions sent by the 
server.  For poll messaging this is of particular interest, since a client may 
have an issue acknowledging the unsupported poll messages to get to the rest of 
the messages in the queue.  This would represent a poison message in the poll 
queue.

Based on the thread, there are separate thoughts related to whether it is fine 
for the server to send a response that contains an extension that was not 
included in the client’s login services.  I believe that the greeting services 
and the login services are used to negotiate the set of extensions that client 
are server can use.  What should the EPP server do with unsupported extensions 
in any EPP response and with poll message EPP responses in particular?  This is 
a broader topic than draft-ietf-regext-change-poll, so I recommend that we 
don’t attempt to solve the problem specifically for 
draft-ietf-regext-change-poll but more generically across all of the extensions 
in a separate draft.


—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com
From: James Galvin >
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould >
Cc: Patrick Mevzek >, 
"regext@ietf.org" 
>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


The chairs would appreciate a suggestion from those in this discussion as to 
what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you 
have identified a technical issue but you have not been clear as to whether you 
want a change in the existing document or you want a new work item for the 
working group?

What would you propose? What do others think?

Antoin and Jim



On 23 Apr 2018, at 9:27, Gould, James wrote:

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subsequent poll 
ack.  The client could use regular expressions to extract the information or 

[regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-05.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   : Third Party DNS operator to Registrars/Registries 
Protocol
Authors : Jacques Latour
  Olafur Gudmundsson
  Paul Wouters
  Matthew Pounsett
Filename: draft-ietf-regext-dnsoperator-to-rrr-protocol-05.txt
Pages   : 15
Date: 2018-05-04

Abstract:
   There are several problems that arise in the standard
   Registrant/Registrar/Registry model when the operator of a zone is
   neither the Registrant nor the Registrar for the delegation.
   Historically the issues have been minor, and limited to difficulty
   guiding the Registrant through the initial changes to the NS records
   for the delegation.  As this is usually a one time activity when the
   operator first takes charge of the zone it has not been treated as a
   serious issue.

   When the domain uses DNSSEC it necessary to make regular (sometimes
   annual) changes to the delegation, updating DS record(s) in order to
   track KSK rollover.  Under the current model this is prone to delays
   and errors, as the Registrant must participate in updates to DS
   records.

   This document describes a simple protocol that allows a third party
   DNS operator to: establish the initial chain of trust (bootstrap
   DNSSEC) for a delegation; update DS records for a delegation; and,
   remove DS records from a secure delegation.  The DNS operator may do
   these things in a trusted manner, without involving the Registrant
   for each operation.  This same protocol can be used by Registrants to
   maintain their own domains if they wish.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-05
https://datatracker.ietf.org/doc/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnsoperator-to-rrr-protocol-05


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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Gould, James]

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to 
leave the EPP server sending unsupported responses (mapping extension and / or 
command response extensions) to a client based on the login services up to a 
separate draft.

This comes down to the interpretation of how the server should handle the login 
services of the client in creating responses.  EPP extensions like the DNSSEC 
extension (RFC 5910) leverages the login services in the migration from RFC 
4310 to RFC 5910, since the info response may include the DNSSEC extension if 
there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of 
the DNSSEC extension is based on the login services.  Similar functionality 
exists within draft-ietf-regext-epp-fees in determining if and which version of 
the extension to return to the client.  Poll messages are unique since they are 
inserted ahead of time by the server without knowledge of what the client does 
support, and therefore runs the risk of coming across a message that the client 
does not support based on the login services.  Clients may or may not be able 
to handle the parsing and unmarshalling of unsupported extensions sent by the 
server.  For poll messaging this is of particular interest, since a client may 
have an issue acknowledging the unsupported poll messages to get to the rest of 
the messages in the queue.  This would represent a poison message in the poll 
queue.

Based on the thread, there are separate thoughts related to whether it is fine 
for the server to send a response that contains an extension that was not 
included in the client’s login services.  I believe that the greeting services 
and the login services are used to negotiate the set of extensions that client 
are server can use.  What should the EPP server do with unsupported extensions 
in any EPP response and with poll message EPP responses in particular?  This is 
a broader topic than draft-ietf-regext-change-poll, so I recommend that we 
don’t attempt to solve the problem specifically for 
draft-ietf-regext-change-poll but more generically across all of the extensions 
in a separate draft.


—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com
From: James Galvin 
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould 
Cc: Patrick Mevzek , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


The chairs would appreciate a suggestion from those in this discussion as to 
what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you 
have identified a technical issue but you have not been clear as to whether you 
want a change in the existing document or you want a new work item for the 
working group?

What would you propose? What do others think?

Antoin and Jim




On 23 Apr 2018, at 9:27, Gould, James wrote:

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subsequent poll 
ack.  The client could use regular expressions to extract the information or 
could do a validating DOM parse and object unmarshalling to have something 
easier to work with.  There is no way for the server to know the capabilities 
of the client other than using the login services.  Both sets of clients can be 
fully supported if the server honors the login services sent by the client.  If 
the client wants to retrieve everything from the server for later processing, 
then the client can simply mirror the greeting services into the login 
services.  Clients that do unmarshall responses, will most likely use 
marshalling factories that will be used to dynamically create the login 
services.  This way 

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[James Galvin]

The chairs would appreciate a suggestion from those in this discussion 
as to what you would like to do next?


The change-poll document has been in WGLC that has now expired.  
However, you have identified a technical issue but you have not been 
clear as to whether you want a change in the existing document or you 
want a new work item for the working group?


What would you propose?  What do others think?

Antoin and Jim





On 23 Apr 2018, at 9:27, Gould, James wrote:


Patrick,



This may be an excellent topic for a working session at the next IETF. 
 It would be great to hear opinions from others on this topic, since 
there is obviously a gap in the interpretation of the greeting and 
login services as it relates to responses (command responses and poll 
response) provided by the server.




Your description still leaves out a case, that I cannot prove to be 
the dominant one but that is certainly not a negligible one: the 
client receives the message, DOES NOT validate it per XML schema, DOES 
NOT parse it, and just stores it (as is or with a simple 
transformation to any other serialization format, an operation that 
does not need to know about the schema nor the content at all) for out 
of band later examination, and ACKs it in EPP to be able to fetch the 
next one.




How can the client ack the message if it doesn’t at least parse it 
for the message id?  An EPP client should frame the responses per RFC 
5734 and will most likely parse the response to determine the result 
of the command and in the case of a poll message parse the message id 
to send the subsequent poll ack.  The client could use regular 
expressions to extract the information or could do a validating DOM 
parse and object unmarshalling to have something easier to work with.  
There is no way for the server to know the capabilities of the client 
other than using the login services.  Both sets of clients can be 
fully supported if the server honors the login services sent by the 
client.  If the client wants to retrieve everything from the server 
for later processing, then the client can simply mirror the greeting 
services into the login services.  Clients that do unmarshall 
responses, will most likely use marshalling factories that will be 
used to dynamically create the login services.  This way the server 
will not send a response that the client does not support and will not 
break the client.




As for "A client would need to proactively deal with the

unexpected if the server does not honor the login services of the

client.", I think this is already the case for many registries, and 
since a long time, so clients had to deal with that already. It is far 
from a new hypothetical problem.




Just because servers have been sending unsolicited extensions to 
clients does not make it correct or appropriate from a protocol 
perspective.  I believe we have examples of EPP extensions (RFC 5910 
and draft-ietf-regext-epp-fees) that includes language related to what 
the server should or should not due based on the client login 
services, so this should be understood.  I believe where it is not 
well understood is the handling of poll messages, which would be the 
point in creating a new draft.






If the registrar logs in without the secDNS extension, to use a "core" 
example, and if it does a domain:info on a domain name which has 
secDNS info (because it is one of his own domain for which he put 
DNSSEC material with it before but right now in this particular 
session it did not use the secDNS extension at login, or maybe less 
contrived before a transfer he does a domain:info with the associated 
authInfo on a domain name it does not sponsor)


then what should the registry do? Send the secDNS part of the 
domain:info or not?


I believe not sending it creates more harm than benefits, even if the 
registrar did not specify it at login, but clearly this is the core 
point of our disagreement.




The registry should not return the secDNS extension in the domain info 
response for a client that does support secDNS-1.0 (RFC 4310) or 
secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 
(https://tools.ietf.org/html/rfc5910#page-4).  There is similar 
language in the Registry Fee Extension related to inclusion of the fee 
extension in the command response (e.g., “does include elements in 
the response, when the extension has been selected during a  
command”).  The login services explicitly provide the object and 
command / response extensions supported by the client along with their 
versions, so why would the server not honor those services to 
determine if and what version of an extension to return to a client?  
The exchange of the server services in the greeting and the client 
services in the login allow the client and server to negotiate what 
extensions are supported on both sides.  Inclusion of an extension 
outside of the negotiated services should result with an error on the 
server side and the server 

Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag

[James Galvin]

With the publication of version 2 of this document on 27 April 2018, and 
given that there have not been any objections to this change, the chairs 
declare this WGLC closed and the document ready for submission to the 
IESG.


The document shepherd is James Gould.  Would you please proceed with the 
shepherd write-up.


Thanks to all!

Antoin and Jim



On 20 Apr 2018, at 15:06, Hollenbeck, Scott wrote:


-Original Message-
From: Andrew Newton [mailto:a...@hxr.us]
Sent: Friday, April 20, 2018 11:10 AM
To: Hollenbeck, Scott 
Cc: p...@dotandco.com; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: 
draft-ietf-regext-rdap-object-tag


On Fri, Apr 20, 2018 at 6:59 AM, Hollenbeck, Scott
 wrote:

Last call ends today, folks. Anything else?


In my opinion, going back to hyphen and introducing "objectTag_0" is 
a

conformance identifier is a significant change. I support it, but we
should probably give people time to comment on it.


Agreed - chairs, can we extend the last call by one week to give 
people time to think about the change and extend statements of support 
or concern? For the record, I support it, too.


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


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

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

[Gould, James]

Hi,

In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-04, I 
have the following feedback:


  1.  The description of the  element in 4.2.1 should be “One or 
more  elements that contain the role statuses” instead of “Zero or 
more  elements that contains the role type”.  I believe the info 
response should always include at least one role status value.
  2.  The description of the  element in 4.2.5 should be “Zero or 
more  elements that contain the role statuses” instead of “Zero or 
more  elements that contains the role type”.
  3.  In 4.2.5, change “A OPTIONAL  element” to “An OPTIONAL  
element”.
  4.  I recommend removing the third paragraph of section 8 “Implementation 
Status”, since the sub-sections explicitly define the specific implementation 
status information.  At a minimum, I would like the sentence “Verisign has 
already implemented this object mapping” to be removed.  There is the 
misspelling of “objecct” in that third paragraph.
  5.  I also recommend removing section 8.3, since I don’t believe 
implementation of the Reseller Extension is relevant to the Organization 
Mapping.
  6.  I would remove the Informative Reference to draft-ietf-regext-reseller 
from the draft (e.g., section 11.2).

—

JG

[cid:image001.png@01D255E2.EB933A30]

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

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

Verisign.com
From: regext  on behalf of Linlin Zhou 

Date: Friday, May 4, 2018 at 2:56 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-04.txt

Dear all,
The org drafts have been updated to version 04 to address all the received 
comments during WGLC. And a new section of implemetation status was added.  
We'd like to have the chairs' instruction to the next step for these two drafts.

Regards,
Linlin

zhoulin...@cnnic.cn

From: internet-drafts
Date: 2018-05-04 13:51
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-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   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-04.txt
Pages   : 41
Date: 2018-05-03

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear all,
The org drafts have been updated to version 04 to address all the received 
comments during WGLC. And a new section of implemetation status was added.  
We'd like to have the chairs' instruction to the next step for these two drafts.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-04 13:51
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-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   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-04.txt
Pages   : 41
Date: 2018-05-03
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-04
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-org-ext-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   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-ext-04.txt
Pages   : 24
Date: 2018-05-03

Abstract:
   This mapping, an extension to EPP object mappings like the EPP domain
   name mapping [RFC5731], to support assigning an organization to any
   existing object (domain, host, contact) as well as any future
   objects.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-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