Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Patrick Mevzek]

On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote:
> We have been talking about Registry Mapping for over a year now and here 
> is the official first 
> draft >.
> 
> 
> 
> Please take a read and let the discussions flow! 

Some quick remarks before trying to implement it and hence reviewing it more in 
depth later.

First I think it is an important concept (auto-discovery), whatever the 
implementation is. It would be most useful if deployed by multiple registries, 
also outside of gTLDs, so even if not technical some outreach should be done to 
try finding registries willing to participate and/or deploy it later.
So that during desigining no spots are missed.

Also I think this is an extension that needs itself to be extended.
I have seen the other document about the launchphase policies but I think the 
model should be different, so that extension data is still inside the 
 node.
Here is an outline of what I thought, so names are just examples:
among the nodes there would be a  one with a "for" attribute whose 
value would be the XML namespace of the extension concerned by the policies 
that will be described inside this policy node. So infData will be mostly a 
list of  nodes. The core document would define the blocks for RFC 5730 
to 5733 (and maybe also RGP and DNSSEC) and then each other extension would 
define their own block content.

Also, using the XML namespace as identifier may not be always possible: all 
policies regarding transport are in RFC5734 which has no XML namespace per se.
So maybe instead of the XML namespace you could use the RFC number or the 
interne-draft name.

In the long run if all of this work (independ of the specific implementation 
details) I would think at least an update to RFC3735 would be welcome that 
could add:
* IANA registration in the EPP registry is mandatory 
* and description of the policy of the extension described must exist and 
conform to this document standard.


More specifically now, about "2.3.  Schedule" I am *strongly* against using the 
format proposed for at least 2 reasons:
- crontab format is not a standard, and is ambiguous for various points
- it encodes a format as a string which is itself in a formatted structure 
since it is XML. "Hijacking" some free form space when you are in formatted 
structure seems wrong to me and shows that the structure is not correctly 
formatted because if it were you would not have to inject a new format in a 
free text.

Why not use ISO8601 Repeated Time Interval format? We are then still gulty of 
the previous point but at least it is a standard.
Otherwise please amend the XML structure to break the content currently in the 
crontab format.


As for timezones, all EPP standards always used UTC for all timestamps (and 
even if some registries on the field do not respect that), and I think it would 
be best to stick to that, so that removes the "tz" attribute.
 
I find this unfortunate:
:  The zone name that can be at any level

When you parse it, you read it as "a registry name", but then it is a zone.
So while it could probably not be  it should at least be
.

You are speaking about "regex" in various places without referencing how is 
this formatted. There are multiple de facto regex "standards" so care must be 
taken there to reference precisely what kind of regex are manipulated.
Also, for example for passwords, some registries policies are not possible to 
express (only) in regex I think, so there might be a blind spot here.

alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all 
the IDNs ones) should be removed and instead LGRs (RFC7940) should be 
used/referenced: far more complicated but at least you cater for all cases.

For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as 
some registries may impose different constraints to each (including: IPv4 
allowed but not IPv6)

For contacts:
- I think the design around int/loc policy does not capture all cases.
Some registries allow int only; some loc; some int only or int+loc, some loc 
only or int+loc, some int only or loc only or int+loc, etc.
(I am not saying all combinations exist, but there are at least more than one 
of them so we need to be able to handle that)
- for the contact ID some registries let the registrars choose it (per the 
RFC5733 spirit) but some do not and just choose instead of them; it should be 
possible to encode this in the policy; there may also be the need to encode 
that in some cases the prefix of contact ids is not free, but fixed per 
registrar; maybe a need too to define what happens when 2 registrars try to 
create the same contact ID, depending on if they are global to the system or 
local to each registrar (the ROID would be different of course).


Other things that would be useful to include (and could be done "easily" if you 
take my ideas on top to have blocks identified by the underlying XML 

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Wed, Jun 6, 2018, at 15:02, Gould, James wrote:
> JG - I don't view the 8 minimum as a "sacred cow" that would require the 
> next iteration of the extension to increase it. 

It was 6 before and apparently we "need" to upgrade to 8 now.
I am quite sure than in 5 years we would want to increase 8 to 10 and so on, 
this is purely Moore's law.
So to ease future maintenance I am just saying: remove this arbitrary limit in 
the protocol, since it is a policy decision anyway.

> but I don't believe that it makes sense to not 
> at least define the minimum to meet the existing security guidelines.  

For me defining a minimum has no sense if you do not define the space of 
possible passwords (which characers) and even various other constraints you may 
place (like no repeating character, or at least one uppercase, etc.)
For the sake of it, imagine the space of allowed characters are digits.
Do you think the security would be increased in any way going from a length of 
6 to a length of 8 digits?
 
> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 
> and 8265.

Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN 
version which is basically what we have currently) : this allows to decouple 
authentication needs to the underlying application/protocol, which also address 
Pieter remark about other ways to authenticate.

This would of course imply bigger changes and deeper ones, but for extended 
features also.

I note in passing that there was always a way to extend authorization 
mechanisms in EPP, for the domain:auth element.
I have never seen however any extension proposing there anything different.

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting

[Patrick Mevzek]

On Wed, Jun 6, 2018, at 14:21, Gould, James wrote:
> This dependency 
> does require ensuring that the host XML schema is loaded ahead of the 
> domain XML schema when pre-caching the XML schemas.

So it seems having dependencies is only a problem or a difficulty when 
validating the frames per the schemas.

-- 
  Patrick Mevzek

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