Re: [regext] Preparing for Montreal

[Mario Loffredo]

Inviato da iPhone

> Il giorno 25 mag 2018, alle ore 17:25, Roger D Carney  
> ha scritto:
> 
> Good Morning,
>  
> Do we need to discuss our next documents in our regular meeting slot?
>  
> For the regular meeting, I would like to give an update from the interim 
> meeting(s).
>  
> I like the two suggested topics for the working session: Registry Mapping and 
> Poll Messages w/ Unhandled Namespaces
>  
> With all the focus from ICANN on RDAP, I wonder if we should also discuss 
> what is left to make RDAP functional for ICANN (e.g. authentication methods, 
> searching, etc.).
I agree.
>  
> I think maybe an hour for each session. Again I would like to see the working 
> session before the regular meeting so that we can provide updates at the 
> regular meeting.
>  
>  
> Thanks
> Roger

Regards
Mario
>  
>  
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
> Sent: Friday, May 25, 2018 1:25 AM
> To: regext 
> Subject: [regext] Preparing for Montreal
>  
> Hi all,
>  
> It is time for us to start thinking of meeting in Montreal.
> With 6 out of 9 millstones on our list in a shepherd writeup status, the 
> chairs would like to know if there are enough topics left for us to justify a 
> work session in Montreal and get a sense of the length for our regular 
> meeting slot.
> We need to send in a meeting request next week, so our question to you is:
> -Do you have agenda items for Montreal?
> -Do you have items to be discussed in a work session?
>  
> Our judgement is that we have 3 active drafts left on our milestones list for 
> which there is little discussion left, mostly also because the focus has been 
> on the 6 WGLC documents for the past period and we have little resources (in 
> other words: we understand you could do with a re-bootstrapping ;-)).
> There are 2 topics that may justify a work session as far as we are aware:
> -The registry mapping discussion
> -Poll messages with unhanded namespaces
> But since there are no related drafts yet for these discussions that need to 
> be presented in our regular session, we could also decide to use 1 meeting 
> slot where we take the first half hour for our regular session for status 
> updates to our milestones, and the rest of our meeting to these topics if 
> someone is willing to lead them.
>  
> So please let us know if you have any agenda items.
>  
> Jim and Antoin.
>  
> - --
> Antoin Verschuren
>  
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
>  
>  
>  
>  
>  
>  
> ___
> 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 mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Object template extension

[Mario Loffredo]

Inviato da iPhone

> Il giorno 25 mag 2018, alle ore 21:37, Pieter Vandepitte 
>  ha scritto:
> 
> Hi all,
>  
> The registry I work for, developed a custom extension to manage "nameserver" 
> groups and "keygroups". When a registrar links a group to a domain, all 
> member nameservers/keys of that group are automatically linked to that 
> domain.. This way, it is very convenient for DNS operators to update DNS data 
> on their complete domain portfolio with a single group update, without 
> forgetting a domain.
>  
> It is used quite a lot, but I did not find other registries having this kind 
> of functionality (I did not perform an extensive search). I'm quite sure we 
> are not the only ones, so do you know other registries having this?

..cz and I think all the registries using FRED software. You can find the 
extensions in the RDAP response. They are named nsset and keyset.
>  
> Is there any interest from the community to offer such a feature to their 
> registrars and collaborate on a common extension? I think of something more 
> generic in a way that a registrar can create a "template" for any kind of 
> object and apply that template to other objects. This way, besides the 
> benefits for DNS operators, a registrar could also define e.g. a default 
> admin contact for every domain, or even apply custom extensions to every 
> domain…
>  
> Any feedback welcome
>  
> Kind regards,
>  
> Pieter


Regards
Mario
> ___
> 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] Object template extension

[Patrick Mevzek]

Pieter,

On Fri, May 25, 2018, at 21:37, Pieter Vandepitte wrote:
> The registry I work for, developed a custom extension to manage 
> "nameserver" groups and "keygroups". When a registrar links a group to a 
> domain, all member nameservers/keys of that group are automatically 
> linked to that domain. This way, it is very convenient for DNS operators 
> to update DNS data on their complete domain portfolio with a single 
> group update, without forgetting a domain.
>  
> It is used quite a lot, but I did not find other registries having this 
> kind of functionality (I did not perform an extensive search). I'm quite 
> sure we are not the only ones, so do you know other registries having 
> this?

I know two extensions:

- the .BE/.EU one: the last time I have looked at them, it was the same, except 
for the namespace
- the .CZ one, in fact in their Fred open source EPP server (so probably used 
for their others TLDs), see 
https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Nssets.html
and
https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Keysets.html


>From memory, they cater for the same needs, but are basically incompatible, 
>besides the namespace.
Starting with the terminology: "group" on one side, "set" on the other.

I would add 2 remarks:
- for nameservers it seems to me to make more sense when hosts are objects, 
instead of attributes while obviously it works in both case. The world is quite 
divided on this, gTLDs are mostly (only?) in the objects group, while ccTLDs 
are predominantly in the attributes group
- for DNSSEC material, here we hit another problem, the DS vs DNSKEY dichotomy, 
partially reflected in the dsData vs keyData interfaces of secDNS-1.1
All grouping cases only make sense of course with the DNSKEY case, because the 
DS depends on the domain. Again, without any hard facts, I still believe that 
most registries are using the DS case. Some, even with the dsData interface, 
ask also for the underlying keyData, but only to check that the DS was 
correctly computed.

Also, such kind of features have consequences for transfers.

> Is there any interest from the community to offer such a feature to 
> their registrars and collaborate on a common extension? I think of 
> something more generic in a way that a registrar can create a "template" 
> for any kind of object and apply that template to other objects. This 
> way, besides the benefits for DNS operators, a registrar could also 
> define e.g. a default admin contact for every domain, or even apply 
> custom extensions to every domain…

Note that there were various attempts to define features such as templates, 
containers, or bulk operations.

Specifically for bulk operations, since the discussions often circled around 
that the primary argument was that EPP is a provisioning protocol and as such 
is not tailored for bulk operations. Which brings immediately this counter 
argument: ... but you can query for more than one object in a given  
command.

Note that while not completely the same, issues of "bundling"  domain names due 
to IDN variants typically is also loosely related to all of this.

One of the latest iteration around these concepts was this draft:
https://tools.ietf.org/html/draft-gould-regext-dataset-01

HTH,

-- 
  Patrick Mevzek

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

Re: [regext] WGLC: draft-ietf-regext-org-02

[Antoin Verschuren]

Oh, and when reviewing, I found another completely different issue, and that is 
with object ownership.
I see a role can have an optional parentID, but what if my organization is 
reseller for more than one registrar within the same registry, and I want 
multiple reseller roles with a different parentID, which registrar is then 
entitled to change my organization data?

I can also see an issue of object hijacking.
Suppose I’m a reseller for registrar A, but my organization is also 
dns-operator for domains at registrar B.
I would think registrar B would not be allowed to change my organization object 
data that is maintained by registrar A.
I could ask registrar A to add my dns-operator role type so registrar B could 
link my object to domains maintained by him, but registrar A could refuse that.

Or should I have a different organization object at each registrar?
I think that would not make things more orderly, and I could end up with a 
number of organization objects for my 1 organization in the same registry..

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 25 mei 2018, om 22:38 heeft Antoin Verschuren  het volgende 
geschreven:

> Hi James,
> 
> Thank you for explaining. I can understand your reasoning now. It’s the 
> client that authorizes the role an organization can have before it links  a 
> domain in that role, except for the registrar role that is set by the server 
> based on local policy.
> I would only make it more clear in the text that an organization can acquire 
> more than one role, and that the role type doesn’t say anything about an 
> organization itself other than it’s current abilities.
> I suggest changing sections 3.2 and 3.2.1 (most important is the change of 
> would to could):
> 
> 3.2.  Organization Roles
> 
>The organization roles are used to represent the relationship an
>organization could have.  Its corresponding element is .
> 
> 3.2.1.  Role Type
> 
>An organization could support a list of roles.  An organization could have 
> multiple
>roles with a different role type.  See Section 7.3 for a list of role type 
> values.
>Its corresponding element is .
> 
> (sorry for the layout mess up by my email client)
> 
> Oh, and shouldn’t the registry in section 7.3 be called "Role Type Values 
> Registry" in stead of "Role Values Registry" ?
> And if I can make another suggestion, I would certainly add a dns-operator as 
> an initial registry entry in section 7.3.2:
>   Value: dns-operator
> 
>   Description: The entity object instance represents a third-party
>   DNS operator that maintains the name servers and zone data on
>   behalf of a registrant..
> 
>   Registrant Name: IESG
> 
>   Registrant Contact Information: i...@ietf.org
> The justification being that I’ve seen that term used more in wishful 
> presentations than privacyproxy.
> 
> - --
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
> 
> 
> 
> 
> 
> Op 25 mei 2018, om 20:27 heeft Gould, James 
>  het volgende geschreven:
> 
>> Antoin,
>> 
>> My feedback is embedded below.
>> 
>> —
>> 
>> JG
>> 
>> 
>> 
>> James Gould
>> Distinguished Engineer
>> jgo...@verisign.com
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com
>> 
>> From: Antoin Verschuren 
>> Date: Friday, May 25, 2018 at 12:19 PM
>> To: James Gould 
>> Cc: Registration Protocols Extensions 
>> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
>> 
>> Op 25 mei 2018, om 16:26 heeft Gould, James 
>>  het volgende geschreven:
>> 
>> 
>>> So my major question is: Can we still remove the  elements from 
>>> the organization object and only use the  in the domain objects 
>>> ? What would it break? Or could we at least have text that this role 
>>> element can never be set by a random EPP command for an organization but is 
>>> always set by the Registry? (so an info command would show it, but a create 
>>> or update could never set it?) Or is this local policy and do we need to 
>>> give guidance to registries as to why, when and how to set this in a BCP?
>>> 
>>> Linking organizations to objects without a role loses meaning.  Use of the 
>>> role is similar to a contact where a domain defines the contact type (role) 
>>> in the link to the contact.  The difference here that a contact can be used 
>>> with any role (admin, tech, billing), but an organization may be authorized 
>>> by the server to act in various roles, where here is the need to control 
>>> what role linkages can be made to the organization.  The possible set of 
>>> roles and who has the authority to manage the organization roles is up to 
>>> server policy.  I believe the “registrar” role is server managed based on 
>>> the contracts, while the “reseller” and the “privacyproxy” roles would be 
>>> defined by the client.
>> 
>> I think we mean the same thing here James, since I agree, But perhaps my 
>> question wasn’t clear.
>> The role shou

Re: [regext] WGLC: draft-ietf-regext-org-02

[Antoin Verschuren]

Hi James,

Thank you for explaining. I can understand your reasoning now. It’s the client 
that authorizes the role an organization can have before it links  a domain in 
that role, except for the registrar role that is set by the server based on 
local policy.
I would only make it more clear in the text that an organization can acquire 
more than one role, and that the role type doesn’t say anything about an 
organization itself other than it’s current abilities.
I suggest changing sections 3.2 and 3.2.1 (most important is the change of 
would to could):

3.2.  Organization Roles

   The organization roles are used to represent the relationship an
   organization could have.  Its corresponding element is .

3.2.1.  Role Type

   An organization could support a list of roles.  An organization could have 
multiple
   roles with a different role type.  See Section 7.3 for a list of role type 
values.
   Its corresponding element is .

(sorry for the layout mess up by my email client)

Oh, and shouldn’t the registry in section 7.3 be called "Role Type Values 
Registry" in stead of "Role Values Registry" ?
And if I can make another suggestion, I would certainly add a dns-operator as 
an initial registry entry in section 7.3.2:
  Value: dns-operator

  Description: The entity object instance represents a third-party
  DNS operator that maintains the name servers and zone data on
  behalf of a registrant..

  Registrant Name: IESG

  Registrant Contact Information: i...@ietf.org
The justification being that I’ve seen that term used more in wishful 
presentations than privacyproxy.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 25 mei 2018, om 20:27 heeft Gould, James 
 het volgende geschreven:

> Antoin,
> 
> My feedback is embedded below.
> 
> —
> 
> JG
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com
> 
> From: Antoin Verschuren 
> Date: Friday, May 25, 2018 at 12:19 PM
> To: James Gould 
> Cc: Registration Protocols Extensions 
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
> 
> Op 25 mei 2018, om 16:26 heeft Gould, James 
>  het volgende geschreven:
> 
> 
>> So my major question is: Can we still remove the  elements from 
>> the organization object and only use the  in the domain objects ? 
>> What would it break? Or could we at least have text that this role element 
>> can never be set by a random EPP command for an organization but is always 
>> set by the Registry? (so an info command would show it, but a create or 
>> update could never set it?) Or is this local policy and do we need to give 
>> guidance to registries as to why, when and how to set this in a BCP?
>> 
>> Linking organizations to objects without a role loses meaning.  Use of the 
>> role is similar to a contact where a domain defines the contact type (role) 
>> in the link to the contact.  The difference here that a contact can be used 
>> with any role (admin, tech, billing), but an organization may be authorized 
>> by the server to act in various roles, where here is the need to control 
>> what role linkages can be made to the organization.  The possible set of 
>> roles and who has the authority to manage the organization roles is up to 
>> server policy.  I believe the “registrar” role is server managed based on 
>> the contracts, while the “reseller” and the “privacyproxy” roles would be 
>> defined by the client.
> 
> I think we mean the same thing here James, since I agree, But perhaps my 
> question wasn’t clear.
> The role should be defined to the link between organization and domain 
> object, not to the organization object itself.
> When I read section 4.2.1 of draft-ietf-regext-org:
> One or more  elements that contains the role type, role
>   statuses and optional role id of the organization.
> for every organization object.
> 
> Do you mean this element will automagicaly be populated with every possible 
>  the registry supports for every new organization that is added in 
> a role except that "registrar” can only be added by the Registry?
> 
> The organization role type is not automagically populated, but is specified 
> by the entity (client or server) that creates the organization.  The 
> “registrar” role can be set explicitly or implicitly by the Registry based on 
> the registrar objects that already exist.  If a registrar creates a reseller 
> organization, the “reseller” role would be specified at the time of create.  
> In section 4.2.1 “EPP  Command”, there must be one or more  
> elements provided by the client.  If an organization is a “reseller” and also 
> provides the “privacyproxy” service for the Registrar, then both roles can be 
> set at the time of create.  The point is that the organization roles define 
> the capabilities of the organization and the ability to add new links using 
> the the role statuses (e.g., clientLinkPr

[regext] Object template extension

[Pieter Vandepitte]

Hi all,
 
The registry I work for, developed a custom extension to manage "nameserver" 
groups and "keygroups". When a registrar links a group to a domain, all member 
nameservers/keys of that group are automatically linked to that domain. This 
way, it is very convenient for DNS operators to update DNS data on their 
complete domain portfolio with a single group update, without forgetting a 
domain.
 
It is used quite a lot, but I did not find other registries having this kind of 
functionality (I did not perform an extensive search). I'm quite sure we are 
not the only ones, so do you know other registries having this?
 
Is there any interest from the community to offer such a feature to their 
registrars and collaborate on a common extension? I think of something more 
generic in a way that a registrar can create a "template" for any kind of 
object and apply that template to other objects. This way, besides the benefits 
for DNS operators, a registrar could also define e.g. a default admin contact 
for every domain, or even apply custom extensions to every domain…
 
Any feedback welcome
 
Kind regards,
 
Pieter___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WGLC: draft-ietf-regext-org-02

[Gould, James]

Antoin,

My feedback is embedded below.

—

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: Antoin Verschuren 
Date: Friday, May 25, 2018 at 12:19 PM
To: James Gould 
Cc: Registration Protocols Extensions 
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

Op 25 mei 2018, om 16:26 heeft Gould, James 
mailto:jgould=40verisign@dmarc.ietf.org>>
 het volgende geschreven:


So my major question is: Can we still remove the  elements from the 
organization object and only use the  in the domain objects ? What 
would it break? Or could we at least have text that this role element can never 
be set by a random EPP command for an organization but is always set by the 
Registry? (so an info command would show it, but a create or update could never 
set it?) Or is this local policy and do we need to give guidance to registries 
as to why, when and how to set this in a BCP?

Linking organizations to objects without a role loses meaning.  Use of the role 
is similar to a contact where a domain defines the contact type (role) in the 
link to the contact.  The difference here that a contact can be used with any 
role (admin, tech, billing), but an organization may be authorized by the 
server to act in various roles, where here is the need to control what role 
linkages can be made to the organization.  The possible set of roles and who 
has the authority to manage the organization roles is up to server policy.  I 
believe the “registrar” role is server managed based on the contracts, while 
the “reseller” and the “privacyproxy” roles would be defined by the client.

I think we mean the same thing here James, since I agree, But perhaps my 
question wasn’t clear.
The role should be defined to the link between organization and domain object, 
not to the organization object itself.
When I read section 4.2.1 of draft-ietf-regext-org:

One or more  elements that contains the role type, role

  statuses and optional role id of the organization.
for every organization object.

Do you mean this element will automagicaly be populated with every possible 
 the registry supports for every new organization that is added in a 
role except that "registrar” can only be added by the Registry?

The organization role type is not automagically populated, but is specified by 
the entity (client or server) that creates the organization.  The “registrar” 
role can be set explicitly or implicitly by the Registry based on the registrar 
objects that already exist.  If a registrar creates a reseller organization, 
the “reseller” role would be specified at the time of create.  In section 4.2.1 
“EPP  Command”, there must be one or more  elements provided 
by the client.  If an organization is a “reseller” and also provides the 
“privacyproxy” service for the Registrar, then both roles can be set at the 
time of create.  The point is that the organization roles define the 
capabilities of the organization and the ability to add new links using the the 
role statuses (e.g., clientLinkProhibited or serverLinkProhibited).

Or does a client need to populate it with "reseller” when 
it creates this organization object for the first time in a reseller role for 
domain 1 , and then needs to add an additional 
"dns-operator" when the same organization object will be 
dns-operator for domain 2?
And how will it be interpreted when an organization object has multiple 
’s? Where is it used?

A “reseller” link from domain 1 will only be authorized by the server if the 
referenced organization already has the “reseller” role and the organization 
“reseller” role does not have either the “clientLinkProhibited” or 
“serverLinkProhibited” status.  The same holds for the “dns-operator” role, 
where the organization must already have the “dns-operator” role without a 
[client/server]LinkProhibited status to authorize Domain 2 to have the 
“dns-operator” link added.  The organization can have many roles and each 
supported organization role can be associated with zero or more links to other 
objects (domain, host, contact, etc.).  The linkage of an object to the 
organization does not define the capabilities of the organization.  The 
organization’s capabilities are defined by their assigned roles.  New links for 
the role can only be established when the organization supports the role and 
new links are not prohibited for the role.

I would say that the myreseller in the 
domain object in draft-ietf-regext-org-ext would define the role an 
organization performs for a domain object sufficiently.

An organization is not a contact where the link defines it’s function.  
Organizations do have roles in the real-world (“reseller”, “dns-operator”, 
“privacyproxy”, etc.), which is what is modeled here.  You don’t make an 
organization into a “reseller” based on the first link added to it and you 
don’t remove t

Re: [regext] WGLC: draft-ietf-regext-org-02

[Antoin Verschuren]

Op 25 mei 2018, om 16:26 heeft Gould, James 
 het volgende geschreven:

> So my major question is: Can we still remove the  elements from the 
> organization object and only use the  in the domain objects ? What 
> would it break? Or could we at least have text that this role element can 
> never be set by a random EPP command for an organization but is always set by 
> the Registry? (so an info command would show it, but a create or update could 
> never set it?) Or is this local policy and do we need to give guidance to 
> registries as to why, when and how to set this in a BCP?
>  
> Linking organizations to objects without a role loses meaning.  Use of the 
> role is similar to a contact where a domain defines the contact type (role) 
> in the link to the contact.  The difference here that a contact can be used 
> with any role (admin, tech, billing), but an organization may be authorized 
> by the server to act in various roles, where here is the need to control what 
> role linkages can be made to the organization.  The possible set of roles and 
> who has the authority to manage the organization roles is up to server 
> policy.  I believe the “registrar” role is server managed based on the 
> contracts, while the “reseller” and the “privacyproxy” roles would be defined 
> by the client. 

I think we mean the same thing here James, since I agree, But perhaps my 
question wasn’t clear.
The role should be defined to the link between organization and domain object, 
not to the organization object itself.
When I read section 4.2.1 of draft-ietf-regext-org:
One or more  elements that contains the role type, role
  statuses and optional role id of the organization.
for every organization object.

Do you mean this element will automagicaly be populated with every possible 
 the registry supports for every new organization that is added in a 
role except that "registrar” can only be added by the Registry?
Or does a client need to populate it with "reseller” when 
it creates this organization object for the first time in a reseller role for 
domain 1 , and then needs to add an additional 
"dns-operator" when the same organization object will be 
dns-operator for domain 2? 
And how will it be interpreted when an organization object has multiple 
’s? Where is it used?

I would say that the myreseller in the 
domain object in draft-ietf-regext-org-ext would define the role an 
organization performs for a domain object sufficiently.

So what’s the purpose of the  element in the organization object 
then? Only registry authorization to be allowed to perform a specific role?
I think that can be captured in a registry's EPP specification like a registry 
mapping document, but does not need to be limited in protocol specification.
The risk is that this element may be wrongly interpreted when an organization 
has multiple  elements. (Verisign IS a Registrant, always ;-))


>  
>  
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>  
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>  
> Verisign.com 
>  
> On 5/25/18, 9:45 AM, "regext on behalf of Antoin Verschuren" 
>  wrote:
>  
> Apologies for not having stepped into this discussion before.
> Having to reread all the treads and all changes during WGLC now the WGLC 
> has ended I can understand Patrick’s concerns.
> Since I was one of the many voices changing the reseller drafts into the 
> org drafts I will try to explain my concerns I had at the time.
> I felt I was the only voice in the dessert at the time, but now that I 
> see all the changes, I will try to explain again.
> This is my personal voice, so chair hat off.
>
> The reason I didn’t support the reseller drafts was twofold:
>
> 1. I saw the need for some registries to give organizations other than 
> the traditional Registrars and Registrants a role in the registration 
> process, but this was not limited to resellers.
> The discussion started because resellers were complaining that their name 
> didn’t show up in the whois for specific registrations, and Registrars were 
> complaining that Registrants of those registrations would call them in stead 
> of their reseller. Registrants simply forgot who they had signed a contract 
> with, so they looked it up in whois. Registrars wanted to list their reseller 
> in whois.
> Appart from resellers, I could see other roles in the future. Working on 
> Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would be 
> another organization registries might want to give special rights to, for 
> example to change NS records or roll DNSKEY material for domains they were 
> responsible for.
> If we were to give every organization role it’s own extension, that could 
> lead to a forrest of organization types each with their own specification.
>
> 2. Coming from way back when we still had only admin-c, tech-c and 
> billing-c contacts (which btw, were 

Re: [regext] Preparing for Montreal

[Roger D Carney]

Good Morning,



Do we need to discuss our next documents in our regular meeting slot?



For the regular meeting, I would like to give an update from the interim 
meeting(s).



I like the two suggested topics for the working session: Registry Mapping and 
Poll Messages w/ Unhandled Namespaces



With all the focus from ICANN on RDAP, I wonder if we should also discuss what 
is left to make RDAP functional for ICANN (e.g. authentication methods, 
searching, etc.).



I think maybe an hour for each session. Again I would like to see the working 
session before the regular meeting so that we can provide updates at the 
regular meeting.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, May 25, 2018 1:25 AM
To: regext 
Subject: [regext] Preparing for Montreal



Hi all,



It is time for us to start thinking of meeting in Montreal.

With 6 out of 9 millstones on our list in a shepherd writeup status, the chairs 
would like to know if there are enough topics left for us to justify a work 
session in Montreal and get a sense of the length for our regular meeting slot.

We need to send in a meeting request next week, so our question to you is:

-Do you have agenda items for Montreal?

-Do you have items to be discussed in a work session?



Our judgement is that we have 3 active drafts left on our milestones list for 
which there is little discussion left, mostly also because the focus has been 
on the 6 WGLC documents for the past period and we have little resources (in 
other words: we understand you could do with a re-bootstrapping ;-)).

There are 2 topics that may justify a work session as far as we are aware:

-The registry mapping discussion

-Poll messages with unhanded namespaces

But since there are no related drafts yet for these discussions that need to be 
presented in our regular session, we could also decide to use 1 meeting slot 
where we take the first half hour for our regular session for status updates to 
our milestones, and the rest of our meeting to these topics if someone is 
willing to lead them.



So please let us know if you have any agenda items.



Jim and Antoin.



- --

Antoin Verschuren



Tweevoren 6, 5672 SB Nuenen, NL

M: +31 6 37682392













___

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] WGLC: draft-ietf-regext-org-02

[Gould, James]

So my major question is: Can we still remove the  elements from the 
organization object and only use the  in the domain objects ? What 
would it break? Or could we at least have text that this role element can never 
be set by a random EPP command for an organization but is always set by the 
Registry? (so an info command would show it, but a create or update could never 
set it?) Or is this local policy and do we need to give guidance to registries 
as to why, when and how to set this in a BCP?



Linking organizations to objects without a role loses meaning.  Use of the role 
is similar to a contact where a domain defines the contact type (role) in the 
link to the contact.  The difference here that a contact can be used with any 
role (admin, tech, billing), but an organization may be authorized by the 
server to act in various roles, where here is the need to control what role 
linkages can be made to the organization.  The possible set of roles and who 
has the authority to manage the organization roles is up to server policy.  I 
believe the “registrar” role is server managed based on the contracts, while 
the “reseller” and the “privacyproxy” roles would be defined by the client.



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 5/25/18, 9:45 AM, "regext on behalf of Antoin Verschuren" 
 wrote:



Apologies for not having stepped into this discussion before.

Having to reread all the treads and all changes during WGLC now the WGLC 
has ended I can understand Patrick’s concerns.

Since I was one of the many voices changing the reseller drafts into the 
org drafts I will try to explain my concerns I had at the time.

I felt I was the only voice in the dessert at the time, but now that I see 
all the changes, I will try to explain again.

This is my personal voice, so chair hat off.



The reason I didn’t support the reseller drafts was twofold:



1. I saw the need for some registries to give organizations other than the 
traditional Registrars and Registrants a role in the registration process, but 
this was not limited to resellers.

The discussion started because resellers were complaining that their name 
didn’t show up in the whois for specific registrations, and Registrars were 
complaining that Registrants of those registrations would call them in stead of 
their reseller. Registrants simply forgot who they had signed a contract with, 
so they looked it up in whois. Registrars wanted to list their reseller in 
whois.

Appart from resellers, I could see other roles in the future. Working on 
Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would be 
another organization registries might want to give special rights to, for 
example to change NS records or roll DNSKEY material for domains they were 
responsible for.

If we were to give every organization role it’s own extension, that could 
lead to a forrest of organization types each with their own specification.



2. Coming from way back when we still had only admin-c, tech-c and 
billing-c contacts (which btw, were often one and the same person, so 1 
NIC-handle) and no registrars, I rejected the business marketing thought that 
an organization IS, and can only be a one of a choice between Registry, 
Registrar, Registrant, Reseller or DNS-operator. An organization can play a 
role as Registrar for one registration, but could play the role of a 
DNS-operator only for another registration. It’s NOT: Once tagged a reseller, 
always a reseller. For our purpose of registering registrations, the 
contractual business relationship organizations have between each other is of 
no matter. We only need to know the role an organization plays for a specific 
registration.

Trick question for bonus points: who IS a Registry, Registrar and 
Registrant for verisign.nl ?



So we can never "tag” an organization as: This one IS a Registrar, this one 
IS always a reseller.

It might be so that an organization can only perform a role as a Registrar 
for specific registries once he is accredited by ICANN or has signed a 
registrar agreement with a non gTLD, but that bookkeeping should not be part of 
EPP. EPP is a provisioning protocol that only administers registrations of 
Internet identifiers, it is not a CRM system.



So I share Patricks concern during WGLC regarding:

---

> I guess it's the fact

> that roles are defined as properties of the organization and at the same

> time as properties of the link?



Yes, that is one troublesome point I raised months ago.

—



Having said that, I can also understand James reasoning that if any 
organization could perform any role, why not simplify even more and also 
administrate Registrars and Registrants as organizations.

But this leads to the basic bookkeeping challenge of when t

Re: [regext] WGLC: draft-ietf-regext-org-02

[Antoin Verschuren]

Apologies for not having stepped into this discussion before.
Having to reread all the treads and all changes during WGLC now the WGLC has 
ended I can understand Patrick’s concerns.
Since I was one of the many voices changing the reseller drafts into the org 
drafts I will try to explain my concerns I had at the time.
I felt I was the only voice in the dessert at the time, but now that I see all 
the changes, I will try to explain again.
This is my personal voice, so chair hat off.

The reason I didn’t support the reseller drafts was twofold:

1. I saw the need for some registries to give organizations other than the 
traditional Registrars and Registrants a role in the registration process, but 
this was not limited to resellers.
The discussion started because resellers were complaining that their name 
didn’t show up in the whois for specific registrations, and Registrars were 
complaining that Registrants of those registrations would call them in stead of 
their reseller. Registrants simply forgot who they had signed a contract with, 
so they looked it up in whois. Registrars wanted to list their reseller in 
whois.
Appart from resellers, I could see other roles in the future. Working on 
Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would be 
another organization registries might want to give special rights to, for 
example to change NS records or roll DNSKEY material for domains they were 
responsible for.
If we were to give every organization role it’s own extension, that could lead 
to a forrest of organization types each with their own specification.

2. Coming from way back when we still had only admin-c, tech-c and billing-c 
contacts (which btw, were often one and the same person, so 1 NIC-handle) and 
no registrars, I rejected the business marketing thought that an organization 
IS, and can only be a one of a choice between Registry, Registrar, Registrant, 
Reseller or DNS-operator. An organization can play a role as Registrar for one 
registration, but could play the role of a DNS-operator only for another 
registration. It’s NOT: Once tagged a reseller, always a reseller. For our 
purpose of registering registrations, the contractual business relationship 
organizations have between each other is of no matter. We only need to know the 
role an organization plays for a specific registration.
Trick question for bonus points: who IS a Registry, Registrar and Registrant 
for verisign.nl ?

So we can never "tag” an organization as: This one IS a Registrar, this one IS 
always a reseller.
It might be so that an organization can only perform a role as a Registrar for 
specific registries once he is accredited by ICANN or has signed a registrar 
agreement with a non gTLD, but that bookkeeping should not be part of EPP. EPP 
is a provisioning protocol that only administers registrations of Internet 
identifiers, it is not a CRM system.

So I share Patricks concern during WGLC regarding:
---
> I guess it's the fact 
> that roles are defined as properties of the organization and at the same 
> time as properties of the link?

Yes, that is one troublesome point I raised months ago.
—

Having said that, I can also understand James reasoning that if any 
organization could perform any role, why not simplify even more and also 
administrate Registrars and Registrants as organizations.
But this leads to the basic bookkeeping challenge of when to give an 
organization rights to register with the registry system or perform other tasks.
I assume this is the reason why one would like to tag an organization as 
"Registrar” for that specific registry only, because that Registry wants to 
know if that organization has signed a registrar agreement to give registration 
rights in the registry system. And tag an organization as a reseller to give 
him f.e. rights to perform info commands for domains.

So while I understand the tagging of an organization for this purpose, I 
believe it should not be set through EPP. It’s only the Registry itself that 
can set this tag internally in the registry system after all the CRM and 
contract thingies have been verified.

So my major question is: Can we still remove the  elements from the 
organization object and only use the  in the domain objects ? What 
would it break? Or could we at least have text that this role element can never 
be set by a random EPP command for an organization but is always set by the 
Registry? (so an info command would show it, but a create or update could never 
set it?) Or is this local policy and do we need to give guidance to registries 
as to why, when and how to set this in a BCP? 

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 24 mei 2018, om 15:30 heeft Gould, James 
 het volgende geschreven:

> Pieter,
> 
> It is interesting that when the drafts came out for resellers there was a lot 
> of discussion on the list and at the working group meetings, but once there 
> was agreement to cr

Re: [regext] Review of draft-ietf-regext-org-ext-06

[Linlin Zhou]

Dear Pieter,
Please find my feedbacks below. Thanks for review.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-05-24 22:45
To: regext
Subject: [regext] Review of draft-ietf-regext-org-ext-06
 
Hi Linlin

Here is my review of draft-ietf-regext-org-ext-06. Only small details.

===
The abstract is a bit different than all other RFCs. 

I would start with This document describes ... and I would also add the whole 
XML blah blah (Specified in XML, this mapping...)

[Linlin] "This document describes an extension to EPP object mappings, which is 
designed to support assigning an organization to any existing object  (domain, 
host, contact) as well as any future objects."
===
In 2. Conventions, append the following text

The XML namespace prefix "orgext" is
used, but implementations MUST NOT depend on it and instead employ a
proper namespace-aware XML parser and serializer to interpret and
output the XML documents.
 
[Linlin] OK.
 ===
 
3.1.  Organization Identifier
 
Detail, but change  to  ? It is the prefix used in the 
other draft.
 
[Linlin] Yes. This is one typo that I missed. It shoud be .
 ===
 
4.  EPP Command Mapping
   A detailed description of the EPP syntax and semantics can be found
   in the EPP core protocol specification [RFC5730].  The command
   mappings described here are specifically for use in provisioning and
   managing organization information via EPP.
 
This is not completely true. This draft is about assigning/linking 
organizations to other EPP objects, it's not about provisioning/managing 
organizations.
 
[Linlin] "The command mappings described here are specifically for assigning 
organizations to EPP objects."
===
 
4.1.  EPP Query Commands
   EPP provides three commands to retrieve domain information: 
   to determine if a domain object can be provisioned within a
   repository,  to retrieve detailed information associated with a
   domain object, and  to retrieve domain-object transfer
   status information.
 
Opinion: I would not emphasise on domains in the text, and only refer domain 
objects in the examples. I would also not repeat the 3 EPP object mappings at 
various places, as it is already mentioned in the intro that it applies to all 
object mappings. It makes the text less verbose.

So, e.g. for 4.1 I would write
 
   EPP provides three commands to retrieve  EPP object information: 
   to determine if an object is known to the server,  to retrieve
   detailed information associated with an object, and  to
   retrieve object transfer status information.

Same for 4.2

Another example, throughout the document: replace 
   EPP domain mapping [RFC5731],
   host mapping [RFC5732] and contact mapping [RFC5733].
 
with 
EPP object mapping
 
 [Linlin] Thanks. I will change them to something general, not to emphase the 
"domain".
===

   The EPP  command provides a transform operation that allows a
   client to modify the attribute of an object.
 
attributes (plural)
 [Linlin] Yes.

No other remarks,

Kind regards

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