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

[Patrick Mevzek]

On Wed, May 30, 2018, at 22:24, Antoin Verschuren wrote:
> I remember a CENTR meeting where ccTLD’s tried to get consensus over if 
> we could harmonize EPP extensions so registrars would not have to code 
> differently for every TLD.
> This was before EPPEXT existed.
> We all thought this would be a good idea.
> But half the registries concluded that they wanted to stick to their own 
> extensions because they felt local legislation or their local 
> constituencies required them so, and the other half had the standpoint 
> that they would only implement as followers, after extensions would be 
> standardized.

I have thought for a long time about EPP standardization and I came into 
conclusion that if consolidation does not happen it is for reasons outside of 
the technical realm. Hence my belief no technical solutions would change any of 
it.

> This was not only TLD registries that had an opinion, 
> and I remember some hesitation especially by ICANN registrars as well 
> because they didn't want extra work, but third party dns-operators, 
> ICANN related policy makers, RIR’s, registrants and plain IETF protocol 
> guardians also have an equal voice in the IETF process, even though they 
> don’t implement.

While every voice is welcome at the table, I still like and favor the idea of 
"running code". Besides rough consensus which you are all saying we have, so 
let us go forward on this topic and standardize this extension that so many 
actors want or agree to.

-- 
  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]

Op 28 mei 2018, om 22:48 heeft Patrick Mevzek  het volgende 
geschreven:

> In your quote you missed the other part which is basically: all domain names 
> are not under ICANN policies.

I didn’t want to go in that discussion, but I’m on your side on that one.

> So for all other TLDs currently can you let me know which protocol 
> limitations currently forbid registry to add formatted content in their whois 
> or, let us say just decide to implement RDAP to start with? Do you really 
> think there are almost none because of protocol limitations, especially in 
> the EPP channel, or maybe for other reasons?

Perhaps it’s not only protocol limitations, or perhaps limitation the wrong 
word, it’s more the pinpointed ICANN RRR model I think that can only be 
provisioned for now.
I remember a CENTR meeting where ccTLD’s tried to get consensus over if we 
could harmonize EPP extensions so registrars would not have to code differently 
for every TLD.
This was before EPPEXT existed.
We all thought this would be a good idea.
But half the registries concluded that they wanted to stick to their own 
extensions because they felt local legislation or their local constituencies 
required them so, and the other half had the standpoint that they would only 
implement as followers, after extensions would be standardized.

Again Patrick, I share your concern of complexity, and we shouldn’t build 
something nobody uses.
I also shared your concern for double labeling both at the organization and 
link level, but James managed to convince me it’s a choice between two bad’s 
where the responsibility of registrars over records they maintain outscores 
double entries in the database for organizations that do anything for anybody.

The reseller draft was originally requested and supported by cnnic, sidn and 
dns belgium who also had the intend to implement. If not this standard then 
their own extension.
Other registries didn’t immediately acknowledge the need for resellers unless 
mandated by (ICANN) policy, but there was consensus that if we were to 
standardize something to accommodate resellers, it should be reusable for other 
emerging "Internet identifier registration related roles" as well. This was not 
only TLD registries that had an opinion, and I remember some hesitation 
especially by ICANN registrars as well because they didn't want extra work, but 
third party dns-operators, ICANN related policy makers, RIR’s, registrants and 
plain IETF protocol guardians also have an equal voice in the IETF process, 
even though they don’t implement.


- --
Antoin Verschuren

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








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

I asked many times who these registries are, I still fail to see broad 
consensus by registries to implement these extensions (I do not count silence 
as being "I agree" but just as "I do not care" or "I am not following these 
discussions, I do not know what to think about it"). Maybe they are thousands 
of them just anxiously waiting for this work to become an RFC (like it never 
happened in the past with registries implementing even core EPP documents 
before they became RFCs...), or maybe there are just not many of them needing 
all this...



There are many registries that participate in this working group that have 
spoken on the list or at the working group meetings on these extensions, so I’m 
really not sure what it means to have “broad consensus by the registries to 
implement”.



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 5/28/18, 4:41 PM, "regext on behalf of Patrick Mevzek" 
 wrote:







On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:

> Op 27 mei 2018, om 21:23 heeft Patrick Mevzek  het

> volgende geschreven:

>

> > This is covered I think in ICANN world by section 1.4.2 of the whois 
specification:

> >

> > "Additional data elements can be added at the end of the text format 
outlined below.”

>

> Ah yes, let’s take the solution of "we can put everything in one non-

> parseble TXT record like DNS can do too if we fail proper design and

> really want to” ;-)

> Sorry for the sarcasm Patrick, but that one was a too open goal ;-)



I am not sure to see where in the text it says that formatted content is 
forbidden, can you pinpoint it to me?



Also, I fail to see how any EPP extension would have any impact here

(in the sense that: you can change what is displayed in whois irrespective 
to what happens on the EPP channel).



> > In a GDPR world you need more and more to be very specific about the 
data you collect, its use, and how you keep it. While it does not apply exactly 
as is here, I still fail to see why the registry database need to be populated 
with all this data.

>

> You forget to see that this will benefit registries that want to do the

> right thing where they are now limited by protocol.



I asked many times who these registries are, I still fail to see broad 
consensus by registries to implement these extensions (I do not count silence 
as being "I agree" but just as "I do not care" or "I am not following these 
discussions, I do not know what to think about it"). Maybe they are thousands 
of them just anxiously waiting for this work to become an RFC (like it never 
happened in the past with registries implementing even core EPP documents 
before they became RFCs...), or maybe there are just not many of them needing 
all this...



Noone knows but I have my ideas in which case we are.



> It allows innovation.



Innovations do not need RFCs, that can happen before.

This would be a separate topic.



> I’ve seen registries that want to add reseller data in

> whois/RDAP at their registrar’s request, registries that want dns-

> operators to be able to roll their registrant’s DNSSEC keys, they want

> to be transparent as tho which organization has extended RDAP access,

> etc. And the registrars are still in control over who they trust with

> these limited registry credentials, but in the end they will save costly

> customer support and have more extended service if they automate.



Maybe. At least this is not shown by discussions here, which is sad.

Also, I am still not sure the proposed extensions solve all of these 
problems anyway. Especially if you take into account the drawbacks as any 
solution has both benefits and drawbacks, nothing is a pure win.



> We took the challenge of doing more work now, to have quicker innovation

> later. And I see more use cases than just the reseller one.



Maybe. I am not convinced by the data proposed on the table. There may be a 
lot more elsewhere, but here I do not see.



Anyway, this is moot. The extensions will go forward and become an RFC and 
then we will be able to jauge really the interest by registries and how it is 
implemented...



--

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

[Patrick Mevzek]

Antoin,

On Mon, May 28, 2018, at 22:40, Patrick Mevzek wrote:
> 
> 
> On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:
> > Op 27 mei 2018, om 21:23 heeft Patrick Mevzek  het 
> > volgende geschreven:
> > 
> > > This is covered I think in ICANN world by section 1.4.2 of the whois 
> > > specification:
> > > 
> > > "Additional data elements can be added at the end of the text format 
> > > outlined below.”
> > 
> > Ah yes, let’s take the solution of "we can put everything in one non-
> > parseble TXT record like DNS can do too if we fail proper design and 
> > really want to” ;-)
> > Sorry for the sarcasm Patrick, but that one was a too open goal ;-)
> 
> I am not sure to see where in the text it says that formatted content is 
> forbidden, can you pinpoint it to me?
> 
> Also, I fail to see how any EPP extension would have any impact here
> (in the sense that: you can change what is displayed in whois 
> irrespective to what happens on the EPP channel).

In your quote you missed the other part which is basically: all domain names 
are not under ICANN policies.

So for all other TLDs currently can you let me know which protocol limitations 
currently forbid registry to add formatted content in their whois or, let us 
say just decide to implement RDAP to start with? Do you really think there are 
almost none because of protocol limitations, especially in the EPP channel, or 
maybe for other reasons?

-- 
  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]

Op 27 mei 2018, om 21:23 heeft Patrick Mevzek  het volgende 
geschreven:

> This is covered I think in ICANN world by section 1.4.2 of the whois 
> specification:
> 
> "Additional data elements can be added at the end of the text format outlined 
> below.”

Ah yes, let’s take the solution of "we can put everything in one non-parseble 
TXT record like DNS can do too if we fail proper design and really want to” ;-)
Sorry for the sarcasm Patrick, but that one was a too open goal ;-)

> This is all true, probably, but how does it goes from there to "these 
> operators need to exist as object in the registry database and be made under 
> control of the registrars"? This sidestep many other points, like, one 
> dns-operator for example, could be operator for domain names sponsored by 
> registrar A and registrar B. Will both registrar A and B need to create an 
> organization object for this same and only dns-operator organization? What 
> exactly does this benefit to?

That was my question and worry too, and the answer unfortunately is yes, as 
ownership of an object needs to be clear to prevent hijacking or no 
responsibility for data.
It’s a choice between two bad’s I agree, but having an organization in the DB 
more than once under different registrars with different ID’s is less bad than 
having objects nobody maintains or fights over.

> In a GDPR world you need more and more to be very specific about the data you 
> collect, its use, and how you keep it. While it does not apply exactly as is 
> here, I still fail to see why the registry database need to be populated with 
> all this data.

You forget to see that this will benefit registries that want to do the right 
thing where they are now limited by protocol. It allows innovation. I’ve seen 
registries that want to add reseller data in whois/RDAP at their registrar’s 
request, registries that want dns-operators to be able to roll their 
registrant’s DNSSEC keys, they want to be transparent as tho which organization 
has extended RDAP access, etc. And the registrars are still in control over who 
they trust with these limited registry credentials, but in the end they will 
save costly customer support and have more extended service if they automate.

> And while I can understand James argument and design I think we are making 
> things over complex without direct benefit, for what I understood the only 
> use case applicable on the table is "storing reseller data in registry 
> database (and maybe showing it in whois)".
> For such a simple need, I think we are over-designing stuff.

If that were the only use case, I would agree with you.
It may look like overdesigning now if that were the only use case, but if we 
don’t add structure now, it will be hard to go back once unstructured objects 
are already populated.
We took the challenge of doing more work now, to have quicker innovation later. 
And I see more use cases than just the reseller one.

regards,


- --
Antoin Verschuren

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



- --
Antoin Verschuren

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








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

> And while I can understand James argument and design I think we are making 
> things over complex without direct benefit, for what I understood the only 
> use case applicable on the table is "storing reseller data in registry 
> database (and maybe showing it in whois)".
> For such a simple need, I think we are over-designing stuff.

The different design options were discussed at IETF 98, where a targeted 
solution for resellers is certainly simpler than supporting a generic 
organization.  The direction from the working group was to support the more 
generic and complex organization.  I believe the two use cases that have value 
now is the reseller use case and the registrar use case.  The registrar 
information should be available directly available from with EPP instead of 
having to use WHOIS / RDAP.  I see having a generic organization object and 
extension as being a better solution than attempting to create role-specific 
objects and extensions for reseller, registrar, and other organization types 
that come up in the future.  

Jim


From: regext [regext-boun...@ietf.org] on behalf of Patrick Mevzek 
[p...@dotandco.com]
Sent: Sunday, May 27, 2018 3:23 PM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

On Fri, May 25, 2018, at 15:45, Antoin Verschuren wrote:
> 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.

But yet I am not sure to have seen a lot of registries here saying that they 
need this extension, or that they plan to use it...

> 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.

Registrars can today publish reseller data in whois. This does not need to be 
sent to the registry, nor to have a specific EPP extension.

This is covered I think in ICANN world by section 1.4.2 of the whois 
specification:

"Additional data elements can be added at the end of the text format outlined 
below."
So registries/registrars could be free to add reseller data today, even without 
any change to EPP.

And in other worlds, where there is not necessarily a registrar whois, it all 
depends on the registry policy to see what will in whois, and no technical 
change could change this policy, so again I do not see how the EPP extension 
helps here.

> 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.

This is all true, probably, but how does it goes from there to "these operators 
need to exist as object in the registry database and be made under control of 
the registrars"? This sidestep many other points, like, one dns-operator for 
example, could be operator for domain names sponsored by registrar A and 
registrar B. Will both registrar A and B need to create an organization object 
for this same and only dns-operator organization? What exactly does this 
benefit to?

In a GDPR world you need more and more to be very specific about the data you 
collect, its use, and how you keep it. While it does not apply exactly as is 
here, I still fail to see why the registry database need to be populated with 
all this data.

And while I can understand James argument and design I think we are making 
things over complex without direct benefit, for what I understood the only use 
case applicable on the table is "storing reseller data in registry database 
(and maybe showing it in whois)".
For such a simple need, I think we are over-designing stuff.

Of course things would change a lot if many registries would come showing their 
support for this extension as it would help them for their various business 
needs.

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

[Gould, James]

Antoin,

The parentID does not define ownership.  As with other EPP objects, the clID 
attribute defines ownership / sponsorship.  The parentID exists to enable 
creating a hierarchy of organizations under a particular sponsoring client, 
like a registrar that supports a reseller channel of more than one layer.

A reseller cannot be a reseller for more than one registrar with the registry.  
The organization created by a registrar would be sponsored by that registrar 
and would not be able to be associated with another registrar or linked to an 
object sponsored by another registrar.  The protocol does not dictate the 
server policy, but I imagine that any organization linked to organizations 
sponsored by the current registrar would get automatically unlinked upon the 
completion of the registrar transfer.

There should be no possibility of object hijacking if the scope of an 
organization is kept at the level of the creator.  The registry itself could be 
the sponsoring client of an organization, such as the registrar, and could be 
the case for other organizations like the dns-operator.  There is only one 
sponsoring client that defines management control, where I don't see the 
possibility that an organization can be a "reseller" with registrar A and could 
be a "dns-operator" for domains at registrar B.  I don't view the "reseller" 
role for an organization applicable where the sponsoring client is at the 
registry level.  The "reseller" organizations should be scoped to the 
sponsoring "registrar" client.

Yes, there is certainly the possibility that at the registry level a single 
organization in the real-world is represented as multiple organization 
instances created by separate registrars.  If there was an organization that is 
a reseller for more than one registrar, each registrar would create a separate 
organization instance with a unique organization iD for the reseller.

I hope this helps.

Thanks,

Jim


From: regext [regext-boun...@ietf.org] on behalf of Antoin Verschuren 
[i...@antoin.nl]
Sent: Friday, May 25, 2018 5:39 PM
To: Registration Protocols Extensions
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

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 
<i...@antoin.nl<mailto:i...@antoin.nl>> 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 Na

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

[Linlin Zhou]

Dear Antion,
I think in the current model, a reseller may be a reseller of multiple 
registrars, but they would have a unique identifier per registrar. So they 
would managed independently by the registrar.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Antoin Verschuren
Date: 2018-05-26 05:39
To: Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
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 <i...@antoin.nl> 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 
multipleroles 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 

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 
> 

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 

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 

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

[Pieter Vandepitte]

Hi Patrick,

I respect your opinion and my gut feeling says it won't be used for anything 
else than resellers. But I might be wrong (and history tells me the odds are 
agains me :-)). I also respect the opinion of others and it's not up to me to 
assess in depth the needs of other registries, I can only challenge and trust 
other participants to act truthful. More important to me, the model seems 
correct and logical, with the others' point of view and needs in the back of my 
head. 
The only thing that bothers me in general (not only for this extension) is the 
low participation in discussion making it difficult to develop a specification 
that fits all needs. 

I do not agree with you regarding not moving forward. A lot of registries 
-including the one I work for- are reluctant to implement anything other than 
RFCs (how many extensions with status Informational in the EPP extensions 
registry are implemented by more than 1 registry?)
Registrars are not happy with ad hoc extensions and I share their concerns. 
Moving forward is the necessary step to be able to converge to a single 
implementation for modelling resellers (and to enable interoperability)

It is certainly not my intention to try to convince you to approve the draft. I 
will continue my write-up but I will write down your concerns and it's up to 
others to decide whether the Draft can become a Proposed Standard

Kind regards

Pieter


> On 24 May 2018, at 07:44, Patrick Mevzek  wrote:
> 
> On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote:
>> @Patrick, did you have time in mean time to catch up? How would you like 
>> the draft to be changed in order to support it? 
> 
> I unfortunately think that I am not convinced by the use case, and I believe 
> that the document could be an I-D referenced on the IANA EPP Extensions 
> registry without the need to become an RFC. Which other registry wish to use 
> it on their systems? And if there is, then for other things than resellers?
> 
> That does not change anything on the WG consensus on the documents, which 
> should proceed on their own pace.
> 
>> 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.
> 
> -- 
>  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] WGLC: draft-ietf-regext-org-02

[Patrick Mevzek]

On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote:
> @Patrick, did you have time in mean time to catch up? How would you like 
> the draft to be changed in order to support it? 

I unfortunately think that I am not convinced by the use case, and I believe 
that the document could be an I-D referenced on the IANA EPP Extensions 
registry without the need to become an RFC. Which other registry wish to use it 
on their systems? And if there is, then for other things than resellers?

That does not change anything on the WG consensus on the documents, which 
should proceed on their own pace.

> 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.

-- 
  Patrick Mevzek

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

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

[Patrick Mevzek]

On Wed, May 23, 2018, at 14:05, Gould, James wrote:
> I would like to understand the concern around the use of the roles.  
> There are cases where an organization can play multiple roles 
> (registrar, privacy proxy, dns provider, etc.) that helps defined what 
> kind of links can be made to it.

Just an example (I do not wish really to revive the discussion) among others:
Imagine a registrar A for registry B, typically a ccTLD.
Registrar A creates an organization O in this registry B
It happens that O is a dns provider, let us say.
So it is created with this role.

Later O becomes ICANN accredited, for example. This is another role.

What totally escapes me: why shoud this be reflected in any way, through 
registrar A in registry B because O is provisioned there?

In short my main problem, and why I can not support this, is that I do not see 
the use case, besides for one registry that needs it to handle resellers, I 
doubt having seen another registry saying it will use it, so we are just paving 
the way to enable storing more data, where the world goes instead towards 
storing less or more carefully (see the current dramas around GDPR)

Not everythint that can be done should be done. This is the main point I will 
try to address in a separate email since it is a generic issue, not 
specifically related to this proposal.

-- 
  Patrick Mevzek

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

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

[Linlin Zhou]

Dear Patrick,
During the WGLC, the drafts were updated from version 02 to 06 to response the 
comments on the mailing list. We are now waiting for our shepherd to give some 
feedbacks to optimize them. I think it is better to follow the version 06 of 
the org drafts if you have any comments.
As for the role definition, I think the generic organization way decided that 
we need to have a "role". You can trace the reseller drafts that there was no 
"role" element at all. Because we don't need a "role" to distinguish different 
types of organizations. The "Role Values Registry" was also disccused on the 
mailing list and got most people's support.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-05-23 20:05
To: Pieter Vandepitte; Patrick Mevzek
CC: regext@ietf.org
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
I would like to understand the concern around the use of the roles.  There are 
cases where an organization can play multiple roles (registrar, privacy proxy, 
dns provider, etc.) that helps defined what kind of links can be made to it.  
The roles on the links between the objects and the organization is needed to 
qualify the type of relationship that exists between the object and the 
organization.  When the draft only dealt with the reseller, there was a single 
role.  When the working group agreed to define a more generic organization 
object for multiple purposes, the concept of the role was needed to support it. 
  
 
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com <http://verisigninc.com/> 
 
On 5/23/18, 7:36 AM, "regext on behalf of Pieter Vandepitte" 
<regext-boun...@ietf.org on behalf of pieter.vandepi...@dnsbelgium.be> wrote:
 
Chairs,

Do we postpone the submission to IESG or do I continue my write-up?

@Patrick, did you have time in mean time to catch up? How would you like 
the draft to be changed in order to support it? 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?

Kind regards

Pieter

> On 22 May 2018, at 08:57, Pieter Vandepitte 
<pieter.vandepi...@dnsbelgium.be> wrote:
> 
> Hi all,
> 
> Other thoughts? I think it's important as document shepherd to know 
whether we should move on or not.
> 
> Kind regards
> 
> Pieter
> 
>> On 21 May 2018, at 05:19, Patrick Mevzek <p...@dotandco.com> wrote:
>> 
>> On Fri, May 11, 2018, at 15:32, James Galvin wrote:
>>> With that, version 06 of this document has been published and the 
chairs 
>>> are declaring WGLC closed.  The document is now ready for submission to 
>>> IESG for consideration as a Proposed Standard.
>> 
>> Isn't that a little rushed?
>> 
>>> From a quick search I have found about only 2 explicit mention of 
support of this document, from Pieter and Scott (as for myself I can not say I 
explicitely support it because I am still uneasy by the need for it or not 
seeing it and still not understanding some part of it like all the "role" part).
>> 
>> Also the document went into so many iterations during the period that it 
was basicaly impossible to follow
>> (one night I have tried reviewing its newest version by implementing it 
in my client... to find out in the morning that a new version went out so I 
kind of decided to stop giving it my time before it stabilizes in some way); 
some new comments even just popped out on the mailing-list yesterday.
>> 
>> So I feel uneasy process-wise. Based on the amount of iterations during 
WGLC it looks like to me that there is at least still some work needed on it, 
and I am not sure its current version correspond really to the working group 
consensus.
>> 
>> The above applies the same way for the two "organization" documents.
>> 
>> -- 
>> 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

 
___
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

[Pieter Vandepitte]

Hi all,

Other thoughts? I think it's important as document shepherd to know whether we 
should move on or not.

Kind regards

Pieter

> On 21 May 2018, at 05:19, Patrick Mevzek  wrote:
> 
> On Fri, May 11, 2018, at 15:32, James Galvin wrote:
>> With that, version 06 of this document has been published and the chairs 
>> are declaring WGLC closed.  The document is now ready for submission to 
>> IESG for consideration as a Proposed Standard.
> 
> Isn't that a little rushed?
> 
>> From a quick search I have found about only 2 explicit mention of support of 
>> this document, from Pieter and Scott (as for myself I can not say I 
>> explicitely support it because I am still uneasy by the need for it or not 
>> seeing it and still not understanding some part of it like all the "role" 
>> part).
> 
> Also the document went into so many iterations during the period that it was 
> basicaly impossible to follow
> (one night I have tried reviewing its newest version by implementing it in my 
> client... to find out in the morning that a new version went out so I kind of 
> decided to stop giving it my time before it stabilizes in some way); some new 
> comments even just popped out on the mailing-list yesterday.
> 
> So I feel uneasy process-wise. Based on the amount of iterations during WGLC 
> it looks like to me that there is at least still some work needed on it, and 
> I am not sure its current version correspond really to the working group 
> consensus.
> 
> The above applies the same way for the two "organization" documents.
> 
> -- 
>  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] WGLC: draft-ietf-regext-org-02

[Patrick Mevzek]

On Fri, May 11, 2018, at 15:32, James Galvin wrote:
> With that, version 06 of this document has been published and the chairs 
> are declaring WGLC closed.  The document is now ready for submission to 
> IESG for consideration as a Proposed Standard.

Isn't that a little rushed?

>From a quick search I have found about only 2 explicit mention of support of 
>this document, from Pieter and Scott (as for myself I can not say I 
>explicitely support it because I am still uneasy by the need for it or not 
>seeing it and still not understanding some part of it like all the "role" 
>part).

Also the document went into so many iterations during the period that it was 
basicaly impossible to follow
(one night I have tried reviewing its newest version by implementing it in my 
client... to find out in the morning that a new version went out so I kind of 
decided to stop giving it my time before it stabilizes in some way); some new 
comments even just popped out on the mailing-list yesterday.

So I feel uneasy process-wise. Based on the amount of iterations during WGLC it 
looks like to me that there is at least still some work needed on it, and I am 
not sure its current version correspond really to the working group consensus.

The above applies the same way for the two "organization" documents.

-- 
  Patrick Mevzek

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

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

[Linlin Zhou]

Hi James,
Thanks for your detail comments. I will have these issues updated and hope we 
can add some implementation status in version 04.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-04-28 05:52
To: James Galvin; Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
Hi,
 
In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-03, I 
found the following issues:
 
In section 3.2.2. “Role Status” 
Change “The values of role status are defined in section 3.5.” to “The values 
of the role status are defined in section 3.5.”.
In section 3.4. “Organization Status Values” 
Change “The “hold” and “terminated” are server-managed…” to “The “hold” and 
“terminated” status values are server-managed…”.
In section 4.1.2. “EPP  Command” 
Change “One or more  elements that contains the role type, role 
status and optional role id of the organization” to “One or more  
elements that contain the role type, role statuses and optional role id of the 
organization”.
Change “Zero or more  elements of role.  The values of role status 
are defined in section 3.5.” to “One or more  elements that contain 
the role statuses.  The values of the role status are defined in section 3.5”.  
Note, the XML schema will support zero or more role statuses in support of a 
create or update, but there should be at least one role status returned per 
role in the info response.  
In section 4.2 “EPP Transform Commands” 
Change “EPP provides three commands…” to “This document provides three 
commands…”.  
In section 4.2.1 “EPP  Command” 
Change “Zero or more  elements of role.  The values of role status 
are defined in section 3.5.” to “Zero or more  elements that 
contain the role statuses.  The values of the role status are defined in 
section 3.5”.
I would remove setting of the “ok” role status in the “Example  
command”, since the server should set the status to “ok” by default.   
In section 4.2.5. “EPP  Command” 
Change “The  and  elements contain the following child 
element:” to “The OPTIONAL  and  elements contain the 
following child elements:”.
Change “Zero or more  elements of role.  The values of role status 
are defined in section 3.5.” to “Zero or more  elements that 
contain the role statuses.  The values of the role status are defined in 
section 3.5”.
Change “A  element contains the following OPTIONAL child elements.” To 
“An OPTIONAL  element contains the following child elements, where at 
least one child element MUST be present:”.  I would remove the sentence “At 
least one child element MUST be present:”. 
I would explicitly specify that the sub-elements of  are OPTIONAL, as 
in:
  i.  An 
OPTIONAL  element…”.
ii.  Zero to 
two  elements…”.
  iii.  An OPTIONAL 
 element…”.
  iv.  An OPTIONAL 
 element…”
v.  An OPTIONAL 
 element…”
  vi.  An OPTIONAL 
 element…”. 
 
—
 
JG



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

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

Verisign.com 
From: James Gould <jgo...@verisign.com>
Date: Wednesday, April 25, 2018 at 8:29 AM
To: James Galvin <gal...@elistx.com>, Registration Protocols Extensions 
<regext@ietf.org>
Subject: Re: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
 
I'm a co-author on this draft, but I did a re-read and I have the following 
items that need to be addressed.  Some of this is based on the experience of 
implementing draft-ietf-regext-org-02 in the Verisign EPP SDK that includes a 
full XML namespace aware and validating client and server.  
 
1.   Section 3.2.3 “Example of Organization Roles” 
a.   I don’t believe the example warrants creating its own section.  I 
recommend moving the example of “Organization Roles” into section 3.2.2 Role 
Identifier, rename it to “Example of organization role identifier:”.  I also 
recommend removing the “S: “ prefix for the organization role identifier 
example and indenting the  and  elements under the 
 element.  
2.   Section 3.4 “Organization Status Values” 
a.   There is no definition of what statuses can be set or removed by the 
client versus the server.  I believe the setting of the statuses prefixed with 
“client” or “server” can match the description in RFC 5731:

  i.  Status values that can be added or removed by a client are 
prefixed with "client".  Corresponding status values that can be added or 
removed by a server are prefixed with "server".
b.  I believe the sentence from RFC 5731 ‘Status values 

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

[Gould, James]

Hi,

In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-03, I 
found the following issues:


  1.  In section 3.2.2. “Role Status”
 *   Change “The values of role status are defined in section 3.5.” to “The 
values of the role status are defined in section 3.5.”.
  2.  In section 3.4. “Organization Status Values”
 *   Change “The “hold” and “terminated” are server-managed…” to “The 
“hold” and “terminated” status values are server-managed…”.
  3.  In section 4.1.2. “EPP  Command”
 *   Change “One or more  elements that contains the role type, 
role status and optional role id of the organization” to “One or more 
 elements that contain the role type, role statuses and optional role 
id of the organization”.
 *   Change “Zero or more  elements of role.  The values of 
role status are defined in section 3.5.” to “One or more  elements 
that contain the role statuses.  The values of the role status are defined in 
section 3.5”.  Note, the XML schema will support zero or more role statuses in 
support of a create or update, but there should be at least one role status 
returned per role in the info response.
  4.  In section 4.2 “EPP Transform Commands”
 *   Change “EPP provides three commands…” to “This document provides three 
commands…”.
  5.  In section 4.2.1 “EPP  Command”
 *   Change “Zero or more  elements of role.  The values of 
role status are defined in section 3.5.” to “Zero or more  elements 
that contain the role statuses.  The values of the role status are defined in 
section 3.5”.
 *   I would remove setting of the “ok” role status in the “Example 
 command”, since the server should set the status to “ok” by default.
  6.  In section 4.2.5. “EPP  Command”
 *   Change “The  and  elements contain the following 
child element:” to “The OPTIONAL  and  elements contain the 
following child elements:”.
 *   Change “Zero or more  elements of role.  The values of 
role status are defined in section 3.5.” to “Zero or more  elements 
that contain the role statuses.  The values of the role status are defined in 
section 3.5”.
 *   Change “A  element contains the following OPTIONAL child 
elements.” To “An OPTIONAL  element contains the following child 
elements, where at least one child element MUST be present:”.  I would remove 
the sentence “At least one child element MUST be present:”.
 *   I would explicitly specify that the sub-elements of  are 
OPTIONAL, as in:

  i.  An 
OPTIONAL  element…”.

ii.  Zero to 
two  elements…”.

  iii.  An OPTIONAL 
 element…”.

  iv.  An OPTIONAL 
 element…”

v.  An OPTIONAL 
 element…”

  vi.  An OPTIONAL 
 element…”.

—

JG

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

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

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

Verisign.com<http://verisigninc.com/>
From: James Gould <jgo...@verisign.com>
Date: Wednesday, April 25, 2018 at 8:29 AM
To: James Galvin <gal...@elistx.com>, Registration Protocols Extensions 
<regext@ietf.org>
Subject: Re: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02


I'm a co-author on this draft, but I did a re-read and I have the following 
items that need to be addressed.  Some of this is based on the experience of 
implementing draft-ietf-regext-org-02 in the Verisign EPP SDK that includes a 
full XML namespace aware and validating client and server.


1.   Section 3.2.3 “Example of Organization Roles”
a.   I don’t believe the example warrants creating its own section.  I 
recommend moving the example of “Organization Roles” into section 3.2.2 Role 
Identifier, rename it to “Example of organization role identifier:”.  I also 
recommend removing the “S: “ prefix for the organization role identifier 
example and indenting the  and  elements under the 
 element.
2.   Section 3.4 “Organization Status Values”
a.   There is no definition of what statuses can be set or removed by the 
client versus the server.  I believe the setting of the statuses prefixed with 
“client” or “server” can match the description in RFC 5731:


  i.  Status values that can be added or removed by a client are 
prefixed with "client".  Corresponding status values that can be added or 
removed by a server are prefixed with "server".

b.  I believe the sentence from RFC 5731 ‘Status values that do not begin 
with either "client" or "server" are server-managed’ can be modified in 
draft-ietf-regext-org to read ‘The “hold

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

[James Galvin]

This is a reminder that this document is in working group last call.

Please indicate your support for the publication of this document.

If any working group member objects to the publication of this document 
please respond on the list by close of business everywhere, Friday, 27 
April 2018.  If there are no objections the document will be submitted 
to the IESG.


During the last call the chairs are looking for a document shepherd for 
this document.  If you are interested in being the document shepherd 
please let the chairs know.  The document editors cannot be the document 
shepherd.


Jim




On 13 Apr 2018, at 9:21, James Galvin wrote:

The document editors have indicated that the following document is 
ready for submission to the IESG to be considered for publication as a 
Proposed Standard:


Extensible Provisioning Protocol (EPP) Organization Mapping
https://datatracker.ietf.org/doc/draft-ietf-regext-org/

Please indicate your support for the publication of this document.

If any working group member objects to the publication of this 
document please respond on the list by close of business everywhere, 
Friday, 27 April 2018.  If there are no objections the document will 
be submitted to the IESG.


During the last call the chairs are looking for a document shepherd 
for this document.  If you are interested in being the document 
shepherd please let the chairs know.  The document editors cannot be 
the document shepherd.


If you’ve never been a document shepherd before don’t worry.  
It’s a great way to understand the IETF process and your chairs 
would be delighted to help you through it.


Thanks,

Antoin and Jim
WG Co-Chairs


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

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

[Pieter Vandepitte]

Thanks Linlin!

Seems OK for me

> Zero or more OPTIONAL org:status elements


Optional here is not necessary, since it's zero, imo, but maybe sometimes you 
can't be explicit enough i think ;-)

Kind regards

Pieter


> On 16 Apr 2018, at 11:52, Linlin Zhou <zhoulin...@cnnic.cn> wrote:
> 
> Dear Pieter,
> Thanks for your support. I'll update the text according to your comments. 
> Please see some my feedbacks inline.
> 
> Regards,
> Linlin
> zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn>
>  
> From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be>
> Date: 2018-04-13 22:06
> To: James Galvin <mailto:gal...@elistx.com>
> CC: Registration Protocols Extensions <mailto:regext@ietf.org>
> Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
> I don't want to delay the publication, and I support it, but there are still 
> some issues/concerns
> 
> Typos/errors
> 
>> EPP provides two commands to retrieve domain information
> 
> Should be: "EPP provides two commands to retrieve organization information". 
> 
>>This document does not define a mapping
>>for the EPP  command to retrieve domain-object transfer
>>status information..
> 
> change domain-object to organization-object
> [Linlin] These typos will be modified.
>> 
>>EPP provides four commands to transform organization object
>>information:  to create an instance of an organization
>>object,  to delete an instance of an organization object,
>> to manage organization-object sponsorship changes, and
>> to change information associated with an organization
>>object.  This document does not define a mapping for the EPP
>> and  command.
> 
> It should be three commands. (Also remove the part "  to manage 
> organization-object sponsorship changes,"). 
> (I'm even not sure that the draft should not support transfer. )
> 
> [Linlin] Yes. Words will be updated.
> 
> In 4.2.1:
> 
>>o  A  element that contains the operational status of the
>>   organization, as defined in Section 3.4 
>> <https://tools.ietf.org/html/draft-ietf-regext-org-02#section-3.4>.
> 
> 
> I think it's zero, one or more org:status elements. It can be 
> clientUpdateProhibited and clientDeleteProhibited at the same time for 
> instance...
> [Linlin]  I'd like to change the text to "Zero or more OPTIONAL org:status 
> elements".
> 
> Food for thought:
> 
> Postal Info
> 
> (1) Why do we still stick to the original model of contacts as the new model 
> for organization, with postal info is required (and within the postalInfo, 
> name and address is required)? I think, we should be very cautious when 
> making attributes required. If it's required for the protocol, I agree, but 
> this is not the case. It's more a policy thing, which must be described in 
> other documents (like ICANN policy documents). E.g. at .be, we are 
> considering to model resellers, but we don't need the address, only the URL. 
> Moreover, this original contact model can potentially become problematic in 
> the context of GDPR (although i don't see a lot of issues with reseller 
> contact data)
> 
> (2) I would not define a postalInfo type. The sole purpose as far as I can 
> think of, is to make the postal info legible for people that use ascii script 
> in their language (transliteration). If transliteration would be the use 
> case, I would not restrict that to transliterations between ascii and "the 
> rest", but then I would define a "script" or "lang" tag, which defines the 
> script of the postal info, and allow zero to infinite postalInfo elements to 
> allow multiple transliterations (not only to us-ascii).
> ( As a side note: I always struggled with the "int" type. For me, "Int" = 
> "international" = any script / character set allowed, which is the opposite)
> 
> (3) As mentioned in a previous post, I still doubt the need for different 
> contact types within an organization, but let's make abstraction of that... 
> Can't the organization's postalInfo data be modeled as a linked contact? Much 
> simpler
> [Linlin] As I expalined before, our requirements was to have a reseller 
> extension with its own contacts and hierarchy. So we keep the postInfo part 
> of RFC5733 to store the address information. For most of the registries and 
> registrars, this structure is more familiar with them. 
> 
> Organization Roles
> 
> (1) Although I doubt the need for a roleid, I think we should either remove 
> it, or extend it. The role id is the id of the organization in a third party 
> source (e.g. in case 

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

[Pieter Vandepitte]

I don't want to delay the publication, and I support it, but there are still 
some issues/concerns

Typos/errors

> EPP provides two commands to retrieve domain information

Should be: "EPP provides two commands to retrieve organization information". 

>This document does not define a mapping
>for the EPP  command to retrieve domain-object transfer
>status information..

change domain-object to organization-object

> 
>EPP provides four commands to transform organization object
>information:  to create an instance of an organization
>object,  to delete an instance of an organization object,
> to manage organization-object sponsorship changes, and
> to change information associated with an organization
>object.  This document does not define a mapping for the EPP
> and  command.

It should be three commands. (Also remove the part "  to manage 
organization-object sponsorship changes,"). 
(I'm even not sure that the draft should not support transfer. )

In 4.2.1:

>o  A  element that contains the operational status of the
>   organization, as defined in Section 3.4 
> .


I think it's zero, one or more org:status elements. It can be 
clientUpdateProhibited and clientDeleteProhibited at the same time for 
instance...


Food for thought:

Postal Info

(1) Why do we still stick to the original model of contacts as the new model 
for organization, with postal info is required (and within the postalInfo, name 
and address is required)? I think, we should be very cautious when making 
attributes required. If it's required for the protocol, I agree, but this is 
not the case. It's more a policy thing, which must be described in other 
documents (like ICANN policy documents). E.g. at .be, we are considering to 
model resellers, but we don't need the address, only the URL. Moreover, this 
original contact model can potentially become problematic in the context of 
GDPR (although i don't see a lot of issues with reseller contact data)

(2) I would not define a postalInfo type. The sole purpose as far as I can 
think of, is to make the postal info legible for people that use ascii script 
in their language (transliteration). If transliteration would be the use case, 
I would not restrict that to transliterations between ascii and "the rest", but 
then I would define a "script" or "lang" tag, which defines the script of the 
postal info, and allow zero to infinite postalInfo elements to allow multiple 
transliterations (not only to us-ascii).
( As a side note: I always struggled with the "int" type. For me, "Int" = 
"international" = any script / character set allowed, which is the opposite)

(3) As mentioned in a previous post, I still doubt the need for different 
contact types within an organization, but let's make abstraction of that... 
Can't the organization's postalInfo data be modeled as a linked contact? Much 
simpler


Organization Roles

(1) Although I doubt the need for a roleid, I think we should either remove it, 
or extend it. The role id is the id of the organization in a third party source 
(e.g. in case of a Registrar, IANA is a third party source, and id is "the 
IANA-id"). It is IMO possible that an object is known in different sources with 
different "IDs"
So, for completeness, the org:roleid should have an attribute indicating the 
authoritative source of the id, in case of a Registrar IANA id, it could be 
"iana". 

(2) As I understand, organization roles can be used in links. But what if a 
link exists for a specific role, and the organization role is removed 
afterwards from the organization? As I understand from James in a previous 
reply to Patrick, this should match (in fact it's a MUST). This is not 
described as far as I can see. Wouldn't it be a good idea, in order to have a 
unambiguous understanding, to describe that in draft-ietf-regext-org-ext 
(create, update) and in draft-ietf-regext-org (update, delete)? 



Kind regards

Pieter



> On 13 Apr 2018, at 15:21, James Galvin  wrote:
> 
> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Proposed 
> Standard:
> 
> Extensible Provisioning Protocol (EPP) Organization Mapping
> https://datatracker.ietf.org/doc/draft-ietf-regext-org/
> 
> Please indicate your support for the publication of this document.
> 
> If any working group member objects to the publication of this document 
> please respond on the list by close of business everywhere, Friday, 27 April 
> 2018.  If there are no objections the document will be submitted to the IESG.
> 
> During the last call the chairs are looking for a document shepherd for this 
> document.  If you are interested in being the document shepherd please let 
> the chairs know.  The document editors cannot be the document shepherd.
> 
> If you’ve never been a document shepherd before 

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

[Hollenbeck, Scott]

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
> Sent: Friday, April 13, 2018 9:22 AM
> To: Registration Protocols Extensions <regext@ietf.org>
> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-org-02
>
> The document editors have indicated that the following document is ready
> for submission to the IESG to be considered for publication as a Proposed
> Standard:
>
> Extensible Provisioning Protocol (EPP) Organization Mapping
> https://datatracker.ietf.org/doc/draft-ietf-regext-org/
>
> Please indicate your support for the publication of this document.

I support publication of this document in concept, but I just noticed some 
significant omissions that need to be addressed before it can move forward.

There is text missing to describe how the Role Values Registry described in 
Section 7.3 should be created and managed by IANA. The authors might want to 
look at Section 2 of RFC 8126 for a description of the kind of information 
that's needed.

In Section 7.1, text needs to be added to include registration of the schema 
from Section 5. Section 6 of RFC 5731 can be used as an example of the 
instructions for registering both the XML namespace and the XML schema. Note 
that there is no XML included with registration of the namespace.

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