Re: [regext] REGEXT Interim Meeting 2018OCT16

[Gould, James]

Patrick,



I like how you have broken down the problem into discrete registry 
implementation cases that can be applied to any EPP extension.  To make the 
core object-extension (draft-gould-carney-regext-registry) workable, we need to 
target case 1 (fully RFC-compliant registry implementers) and case 3b 
(implement base and standard policy extensions along with a server-specific 
policy extension for unique policies), since the goal is to define policies 
associated with the SHOULDs, MAYs, and options included in RFCs.  Case 3b could 
also be a sub-option for case 1 (1a), since a fully compliant registry 
implementer may have unique RFC-compliant policies that they need to define.  
Targeting case 2 does not make any sense, since those not implementing 
draft-gould-carney-regext-registry will most likely not speak up.  Targeting 
case 3a is highly unlikely to be successful, since why would an implementer 
change their policy to support defining their policy externally?  Also, case 3a 
is equivalent to case 1 from a draft-gould-carney-regext-registry  perspective. 
 I also have a 3c case, where the implementer creates a Registry Mapping-like 
implementation by not following the normative language or/and customizing the 
XML schema.  In the end, the best that we can do is to define a solid base 
draft that covers the SHOULDs, MAYs, and options of the EPP RFCs, with the 
ability to define system-level and zone-level policy extensions that cover the 
policies of specific EPP extensions or a server-specific policy.  I would 
imagine that if there is a need for a server-specific policy extension, that 
the implementer would define just one.  For clarity, I include the revised 
draft-gould-carney-regext-registry implementation cases below:



  1.  Fully RFC-compliant Registry Implementers - Implementation driven by 
policy/business/marketing case.
 *   Optionally create Server Policy Extension for server-specific policies
  2.  Registry Non-Implementers - Registries not implementing for a variety of 
reasons.
  3.  Non RFC-compliant Registry Implementers
 *   Change policies to be compliant with RFCs
 *   Define Server Policy Extension for server-specific policies (e.g., RFC 
overrides)
 *   Create Registry Mapping-like implementation (e.g., not following 
normative language and/or XML schema in draft-gould-carney-regext-registry)



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 12/11/18, 1:53 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:

> > * Ensure that the hostAddr model of RFC 5731 is supported

> > 
*

> > *Discussion*

> >  * In the case of a zone that supports domain:hostAddr instead of

> > domain:hostObj,

>

> No. It is not "instead".

> Have a look at the example on page 19 of some registry documentation

> at

> 
https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf



[..]



> The purpose of draft-gould-carney-regext-registry and the policy

> extensions is to define the policies around the SHOULDs, MAYs, and

> options included in extension RFCs, I-Ds, custom extensions, and to

> define the server-specific policies.  If a registry chooses not to

> follow the MUSTs in the extensions, that is their choice.  They can

> define their custom, non-compliant policies in a server-specific policy

> extension of draft-gould-carney-regext-registry.  Custom policy

> extensions can be created that define system-level and zone-level

> policies that don't need to go through the IETF.  There is no need to

> attempt to address non-compliant policies in the standards track I-Ds.



I think you are missing the point I try to raise here.

It is of course very easy to dismiss this specific case (but there are tons 
of others)

because the RFC says "MUST", and the case does not follow it, so it is 
deemed invalid

per RFC specifications and can then be ignored.

Technically, yes.

But this has consequences for the future.



First, let me reiterate how important I think this extension is, and I 
wished we

had it many years ago already. With it, life of registrars would be 
tremendously easier. Which would then also make registries life easier.



**IF** (and this is the big if and the core of my point) it gets 
implemented, and this is where I fear problems, even more so because there is 
basically no discussion

on this list from other registries about it.



For me the future can morph into the following cases:



1) a registry is fully conformant with all RFCs and hence could implement 
this

extension as is without difficulties. It is just a 

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Patrick Mevzek]

On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:
> > * Ensure that the hostAddr model of RFC 5731 is supported 
> > * 
> > *Discussion*
> >  * In the case of a zone that supports domain:hostAddr instead of 
> > domain:hostObj, 
> 
> No. It is not "instead".
> Have a look at the example on page 19 of some registry documentation
> at 
> https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

[..]

> The purpose of draft-gould-carney-regext-registry and the policy 
> extensions is to define the policies around the SHOULDs, MAYs, and 
> options included in extension RFCs, I-Ds, custom extensions, and to 
> define the server-specific policies.  If a registry chooses not to 
> follow the MUSTs in the extensions, that is their choice.  They can 
> define their custom, non-compliant policies in a server-specific policy 
> extension of draft-gould-carney-regext-registry.  Custom policy 
> extensions can be created that define system-level and zone-level 
> policies that don't need to go through the IETF.  There is no need to 
> attempt to address non-compliant policies in the standards track I-Ds.  

I think you are missing the point I try to raise here.
It is of course very easy to dismiss this specific case (but there are tons of 
others)
because the RFC says "MUST", and the case does not follow it, so it is deemed 
invalid
per RFC specifications and can then be ignored.
Technically, yes.
But this has consequences for the future.

First, let me reiterate how important I think this extension is, and I wished we
had it many years ago already. With it, life of registrars would be 
tremendously easier. Which would then also make registries life easier.

**IF** (and this is the big if and the core of my point) it gets implemented, 
and this is where I fear problems, even more so because there is basically no 
discussion
on this list from other registries about it.

For me the future can morph into the following cases:

1) a registry is fully conformant with all RFCs and hence could implement this
extension as is without difficulties. It is just a policy/business/marketing 
case
to decide to implement it or not, the specification is not a barrier

2) registries that decided not to implement it anyway, for whatever reasons and 
case they are in

3) registries that DO NOT respect all RFCs to the letter and/or are in cases 
not handled by this new extension and that are thinking about implementing it 
or not.
If they want to implement it they have the choice:
a) either to change their policies and business rules that either contradicts 
core
EPP documents or are incompatible with the extension as written right now
b) or to create **another** EPP extension just to code for the differences 
between the kind of policies that can be encoded in your extension and the 
registry policies that do not fit in

The above are facts, the below are my assumptions.

- case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall 
in this case
- case 2 is irrelevant for this discussion as nothing we discuss can change that
- case 3 is the interesting point, and my assumption is that this will group 
basically all ccTLDs, and my further assumptions are that of course registries 
will not change their policies just because this extension is not tailored to 
them (so 3a will mostly be empty) and I doubt many will go the length of 
writing a new extension just to codify their policies (so 3b will be negligible)
[BTW 3b introduces again the exact same problem we had with EPP extensions 
since the beginning: fragmentation. Multiple registries have a "trade" 
operation for example. To encode that as policy, there is a risk each one 
drafting an extension for it, and then you come back to the case of multiple 
non-interoperable extensions that do the same things which is a nightmare]

So I fear that at the end we will have something beautiful that caters for all 
the
generic/simple cases, but that left out all complicated cases, and hence the 
implementation will not be widespread.

The fact that no registry claimed to be willing to implement it or to write an 
extension for their own policy is very troublesome for me. But maybe it 
happened in private or will be announced in the future.


-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Gould, James]

Patrick,

Please review the latest version of draft-gould-carney-regext-registry, since I 
believe it has changes that are applicable to your feedback (e.g., batch 
schedule, host attribute support).  I provide my responses to your feedback 
below.  
  
—
 
JG



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

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

Verisign.com  

On 11/26/18, 8:02 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the  elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this 
content
will not be described in an automated content, and relying on human
documentation is not enough.

I agree that the key, value pair approach is an anti-pattern that has been 
tried before without success.  

> * The schedule format to use with the  
>  element 
> * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

The key is not the word "condensed", but "effective".  Please review the latest 
update to the approach taken for the schedule in 
draft-gould-carney-regext-registry-04.  

> * Ensure that the hostAddr model of RFC 5731 is supported 
> * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at 
https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP 
specifications.

But besides that it is important to be clear on the purpose of this 
extension:
being as "pure" and perfect as possible, with the hope that non-conforming 
current
cases will then suddenly decide to fix their thing in order to be able to 
use it, or
being as inclusive as possible so that as many registries as possible are 
using it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and 
hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change 
just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads 
about
this extension. It is an important question, that is itself tied to the 
amount
of energy devoted to each extension, which extension becomes working group 
documents
and which extensions really solve problem of more than one registry and 
hence
may have the chance to be implemented by a sizeable chunk of current 
players.

The purpose of draft-gould-carney-regext-registry and the policy extensions is 
to define the policies around the SHOULDs, MAYs, and options included in 
extension RFCs, I-Ds, custom extensions, and to define the server-specific 
policies.  If a registry chooses not to follow the MUSTs in the extensions, 
that is their choice.  They can define their custom, non-compliant policies in 
a server-specific policy extension of draft-gould-carney-regext-registry.  
Custom policy extensions can be created that define system-level and zone-level 
policies that don't need to go through the IETF.  There is no need to attempt 
to address non-compliant policies in the standards track I-Ds.  

HTH,

-- 
  Patrick Mevzek

___
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] REGEXT Interim Meeting 2018OCT16

[Patrick Mevzek]

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the  elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this content
will not be described in an automated content, and relying on human
documentation is not enough.

> * The schedule format to use with the  
>  element 
> * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

> * Ensure that the hostAddr model of RFC 5731 is supported 
> * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP 
specifications.

But besides that it is important to be clear on the purpose of this extension:
being as "pure" and perfect as possible, with the hope that non-conforming 
current
cases will then suddenly decide to fix their thing in order to be able to use 
it, or
being as inclusive as possible so that as many registries as possible are using 
it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads about
this extension. It is an important question, that is itself tied to the amount
of energy devoted to each extension, which extension becomes working group 
documents
and which extensions really solve problem of more than one registry and hence
may have the chance to be implemented by a sizeable chunk of current players.

HTH,

-- 
  Patrick Mevzek

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

[regext] REGEXT Interim Meeting 2018OCT16

[Roger D Carney]

Meeting started at 11:03 (UTC-5)

Attendees: Roger Carney, Jody Kolker, James Gould, James Galvin, Gurshabad 
Grover, Rick Wilhelm


Agenda

  1.  Validate draft (comments, concerns, implementations) - New version to be 
posted this week.
  2.  Registry Mapping
 *   Continue the lively discussion that were started in London and 
continued in Montreal
 *   Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

We first started talking about the changes to the Validate Draft:

* Roger gave an update on the current version

* Still need to make change to reference for RFC 7451 from normative to 
informative

* Gould talked about a few items he had posted to the list:

 *   Section 2.2 "Validate Id"
*   I recommend creating 2 numbered paragraphs for the two different 
scenarios and end the first sentence with a colon ":".  You could then change 
the "First if the  is passed" with "1. If the  
element is passed" and "Second scenario would be if the request includes 
additional elements" with "2. If the  element includes additional 
elements".
   *   [Interim] Will look at this
*   Nit - Change ">validate:postalIinfo>" to ""
   *   [Interim] Will update
 *   Section 2.3 "Validate PostalInfo, Voice, Fax, Email, AuthInfo"
*   I would directly refer to the validate elements by element name 
that mirror the associated elements in RFC 5733.  My recommendation is to be as 
explicit as possible here.  You reference section 2.3 for the elements in 
section 3.1.1 "EPP  Command", but you really don't describe the elements 
section 2.3.
   *   [Interim] Will look at this
 *   Section 3.1.1 "EPP  Command"
*   I recommend putting the attribute in double quotes as in '...two 
required attributes: contactType, which describes...' to '...two required 
attributes: "contactType", which describes...' and '...tld, which provides' 
to '"tld", which provides...'.
   *   [Interim] Will update
*   I still don't like the use of the  elements as a 
"flexible mechanism to share data between the client and the server".  It would 
be best to enable the use of the EPP extensions to be passed directly to the 
validate mapping without the need for transforming them to key, value pairs.   
The client and server would need to negotiate, most likely out-of-band, on the 
acceptable set of key, value pairs, or a new IANA registry would need to be 
defined to globally define the set of acceptable validate keys.
   *   [Interim] Gould was suggesting the draft to support the  
so that it can use the extesions of the contact create so that they map more 
specifically instead of mapping these to KV pairs. I made mention that it is 
not a required element, a server may choose not to support. Maybe add text like 
"KV is server dependent and these keys would be communicated out of band"

We moved onto the Registry Mapping discussion

* Gould talked about the GitHub project and all the issues that have 
been raised on list have been recorded into the project. Gould closed six items 
as corner cases. Currently 14 items remaining.

 *   Define Exceeding Maximum Expiration Date 
Policy
*   Discussion
*   Schema Change
*   Maybe we can add the registry:exceedMaxExDate element under the 
registry:domain element after the registry:period element, with the description:
   *   The OPTIONAL action taken by the server when the domain:exDate 
exceeds the maximum expiration date by a fractional period on a renewal command 
like domain:renew or domain:transfer. The possible values for the 
registry:exceedMaxExDate element include:
   *   "fail": The server will fail the renewal command when the 
expiration date exceeds the maximum expiration date by a fraction of a period.. 
An example is if the maximum expiration date is 10 years, and a client renews a 
domain name to 10.5 years, the server will fail the renew.
   *   "clip": The server will clip the fractional period when the 
expiration date exceeds the maximum expiration date by a fraction of a period. 
An example is if the maximum expiration date is 10 years, and the client renews 
a domain to 10.5 years, the server will clip the .5 fractional year so that the 
domain name will expire exactly in 10 years.

?  [Interim] This may need to specific for transfers and renew. Gould will 
update language here on the "fail".

 *   Definition of Regular Expressions for String Format 
Policies
*   Discussion
*   I addressed this in the Login Security Policy Extension 
(draft-gould-regext-login-security-policy) by choosing Perl-compatible Regular 
Expression (PCRE) syntax. I can add the appropriate informational reference to 
PCRE within the Registry Mapping 

Re: [regext] REGEXT Interim Meeting (2018OCT16)

[James Galvin]

I will attend this meeting.  Thanks Roger.

Jim



On 1 Oct 2018, at 12:57, Roger D Carney wrote:


Good Morning,



I would like to invite everyone to an interim meeting Tuesday October 
16th at 16:00 UTC for 60 minutes.




We plan to focus the discussion around two topics:



Agenda

  1.  Validate draft (comments, concerns, implementations) - New 
version to be posted this week.

  2.  Registry Mapping
 *   Continue the lively discussion that were started in London 
and continued in Montreal
 *   Policy Extension Review: how a server implements an 
extension, the SHOULD(s), MAY(s), etc.




We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.




Please reply to the list or directly to myself if you plan on 
attending this meeting.






Thanks

Roger




___
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