[regext] reseller drafts reviews

[Linlin Zhou]

Dear all,
The reseller drafts were suggested to have more reviews in last IETF meeting.  
All of the issues raised on the mailing list have been solved and updated in 
the latest version. Any more review or comments on these two drafts are 
appreciated. 

Regarding the draft-ietf-regext-reseller,  we may have some choices of keep 
reseller information in my mind,
A. an ID and a name only
B. reuse contact object 
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
The RDAP may only need a name displayed in response but there are still some 
other information we need such as the contact or parent registrar of a 
reseller. So option A may not seem as a good choice. Some registries have 
already use contact to keep reseller information, but after discussion we found 
that reseller and contact are not totaly the same. The reseller is a object 
that could have one or more contacts and it has hierarchical structure. So 
option B is also not take into consideration. Finally we decided to define a 
reseller object to full fill the existing and possible future requirements., 
which is a flexible way for any changes. Thoughts? 

Regards,


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

Re: [regext] reseller drafts reviews

[Linlin Zhou]

Hi Antoin,
Thanks for your suggestion and I have some clarifications of your suggestion.
Actually in the reseller draft, we've thought the issue about registrar and 
reseller objects. The reseller has pretty much the same attributes that would 
be captured for a registrar if a registrar could be provisioned via EPP.  We 
really see the reseller object as more of an account object, where a registrar 
is an account without a parent. So in section 3.4, we've defined the parent 
identifier to show the hierarchy.

In the hierarchy discussion, we've drawn a  simple graph of reseller relations 
as below,
Registry 
|  |
|-Reseller |-Registrar
   | | 
   |-N-Tier Reseller |-Reseller Customer
  |
  |-Reseller Customer
Registrar - Has direct contractual relationship with the registry and direct 
access to the registry without any sub-accounts
Reseller - Has direct contractual relationship with the registry and direct 
access to the registry with sub-accounts.  A reseller is really a Registrar 
with sub-accounts.
N-tier Reseller - Does not have a contractual relationship with the registry or 
direct access to the registry with sub-accounts.  
Reseller Customer - Does not have a contractual relationship with the registry 
or direct access to the registry without any sub-accounts.  
In our opinion, it may be easier for everyone to understand the scope of the 
object mapping, so we leave it as strictly a Reseller Object Mapping. As there 
is no object mapping for registrar, if we want to define a more general object 
including registrar and reseller, we may need a type attribute to differentiate 
them and may have some other adjustments which I am not thinking very clearly.

Regards,


Linlin Zhou
 
From: Antoin Verschuren
Date: 2016-08-15 17:38
To: Linlin Zhou
CC: regext
Subject: Re: [regext] reseller drafts reviews
Hi Linlin,

I must admit I haven’t compared the proposed reseller structure to that of a 
registrar, but what happens when a reseller suddenly wants to become a 
registrar (or a registrar that will become a reseller under a larger 
registrar)? Use cases that I think happen regularly.
Is it just a matter of adding or removing a reseller:parentId?
I’d say option D to reuse the same fields for a reseller as a registrar, but 
with business logic that makes a lot of fields optional that would be mandatory 
for a registrar without a parentId. I mean, a reseller is an entity, just like 
a registrar but with different rights and obligations towards the registry, 
right? Would that work?
What is shown in RDAP is another matter, but at least we don’t need to reinvent 
and maintain a new structure, and we only need to agree on which fields are 
optional for which role, which may even be local policy.
Also thinking ahead of the possibility to administer 3th party dns-operators 
with limited rights agreed upon by the parent registrar, which might encounter 
the same question..
Just a thought.

- -- 
Antoin Verschuren

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






Op 15 aug. 2016, om 09:54 heeft Linlin Zhou  het volgende 
geschreven:

Dear all,
The reseller drafts were suggested to have more reviews in last IETF meeting.  
All of the issues raised on the mailing list have been solved and updated in 
the latest version. Any more review or comments on these two drafts are 
appreciated. 

Regarding the draft-ietf-regext-reseller,  we may have some choices of keep 
reseller information in my mind,
A. an ID and a name only
B. reuse contact object 
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
The RDAP may only need a name displayed in response but there are still some 
other information we need such as the contact or parent registrar of a 
reseller. So option A may not seem as a good choice. Some registries have 
already use contact to keep reseller information, but after discussion we found 
that reseller and contact are not totaly the same. The reseller is a object 
that could have one or more contacts and it has hierarchical structure. So 
option B is also not take into consideration. Finally we decided to define a 
reseller object to full fill the existing and possible future requirements., 
which is a flexible way for any changes. Thoughts? 

Regards,


Linlin Zhou
___
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] reseller drafts reviews

[Linlin Zhou]

Hi James,
Thanks for your explanation.

You just remind me of the first version of draft-ietf-regext-reseller-ext, 
we've put both ID and name in the extension. Then we found that there is no 
mechnism to keep the correctness of ID and name updates. So only the ID was 
kept in the latest version which is reffered to the reseller object identifier.
As for option B, I think we have indicated that reseller and contact are not 
totally the same. It is a object that could have contacts object and has 
hierarchical relations. So we do not want to mix them together.

Regards,


Linlin Zhou
 
From: Gould, James
Date: 2016-08-16 03:23
To: Linlin Zhou
CC: regext
Subject: Re: [regext] reseller drafts reviews
Hi, 

As a co-author of these drafts and the one that pushed for the independent 
reseller object of “C”, I believe that “C” is the best choice with some 
explanation included below.  

The driving reason for the creation of the reseller draft(s) is to enable the 
display of reseller information in RDDS at the registry level.  Let me be clear 
that I believe it is an anti-pattern (RDDS Copy Authoritative Data) to push 
authoritative data down to a party to display as if it were authoritative.  If 
the domain registry industry does support this anti-pattern, we may as well 
make it worth more than supporting RDDS.  Option “A” simply treats the reseller 
information as an attribute of the provisioning objects (domain, host, contact, 
etc.) while option “C” treats the reseller information as objects.  Items like 
ID uniqueness and reseller name changes is much more complex with the attribute 
model of “A”.  I really haven’t thought about option “B” much, but considering 
that a reseller is a separate object from a contact, I don’t believe reusing 
the contact mapping makes sense.  Option “C” supports RDDS and is extensible to 
support other reseller features like security, policy, financial, and reporting 
for registrars at the registry level.  

In summary, option “C” models the real world and makes implementation of the 
RDDS Copy Authoritative Data anti-pattern have some value in supporting 
optional reseller channel features at the registry level in the future.  

—

JG




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

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

VerisignInc.com 

On Aug 15, 2016, at 3:54 AM, Linlin Zhou  wrote:

Dear all,
The reseller drafts were suggested to have more reviews in last IETF meeting.  
All of the issues raised on the mailing list have been solved and updated in 
the latest version. Any more review or comments on these two drafts are 
appreciated. 

Regarding the draft-ietf-regext-reseller,  we may have some choices of keep 
reseller information in my mind,
A. an ID and a name only
B. reuse contact object 
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
The RDAP may only need a name displayed in response but there are still some 
other information we need such as the contact or parent registrar of a 
reseller. So option A may not seem as a good choice. Some registries have 
already use contact to keep reseller information, but after discussion we found 
that reseller and contact are not totaly the same. The reseller is a object 
that could have one or more contacts and it has hierarchical structure. So 
option B is also not take into consideration. Finally we decided to define a 
reseller object to full fill the existing and possible future requirements., 
which is a flexible way for any changes. Thoughts? 

Regards,


Linlin Zhou
___
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] reseller drafts reviews

[Linlin Zhou]

Dear all,
Thanks Rik and James for your feedbacks.
I've listed the elements  and whether it is required in the reseller draft. 
Please send comments if you have other suggestions.
o  required

o  required

o  required

o  optional

o One or two  elements

*   required

* 

+   One, two, or three optional

+  required 

+  optional

+  optional

+  required

o  optional

o  optional

o  optional

o  required if it has

o Zero or more OPTIONAL 

o  required

o  required

o  required

o  required if it has

o  required if it has

o  optional

Regards,


Linlin Zhou
 
From: Rik Ribbers
Date: 2016-08-22 23:11
To: James Gould
CC: Linlin Zhou; regext
Subject: Re: [regext] reseller drafts reviews
Hi James, 

On 22 Aug 2016, at 16:02, Gould, James  wrote:

Rik, 

Your response made me think a little bit more around the problem that is being 
solved.  I see 2 problems that could be solved by formally defining the 
reseller and linking the reseller with objects in the registry:

Displaying the Reseller information in RDDS (RDAP).  Right now it is the 
reseller name that needs to be displayed, but what if more information is 
needed later like E-mail, URL, Address, Contacts, etc.?  

Exactly the reason for creating an object (and going for option C in Linlin’s 
proposal). However if were are going to todo this for resellers specific we are 
going to have to create another EPP extension for every ”new” instance in the 
ecosystem as it evolves. I can image we do this for DNS-operators, but also for 
registrants (where the registry provides some additional services to 
registrants and the current contact mapping is not sufficient). 

Enable registrars to set security, policy, and reporting options for reseller’s 
at the registry level.  I can see many different use cases here that we’ve not 
yet fully discussed.  

Agreed this has not been discussed, and I do see some use cases. Although I 
doubt we would configure these options through EPP. I would provision this 
through some customer portal where the registrar can do this (either through a 
web interface or REST API). 


I don’t want to fall into the “RDDS Copy Authoritative Data” anti-pattern in 
solving problem #1 by having the registrars or even the resellers copying 
authoritative data down to the another party (registry) to display as if it 
were authoritative.  The registry does not need any additional information 
(address, voice, fax, email, url, contacts, disclose) for a reseller in solving 
problem #2, since the identifier, the name, and the relationship to the 
registrar and to the registry objects is important.

To solve both problems without falling into the “RDDS Copy Authoritative Data” 
anti-pattern, the following is needed:

Need to be capable of defining an object in the registry via the EPP Reseller 
Mapping with the minimal attributes required to solve problem #1 and #2.  
Specifically the following information is needed: 
Identifier - Registry unique identifier that could be client specified or 
server generated.  

If the GURID is indeed globally unique this is merely a technical identifier 
(primary key) and it is not even necessary in the EPP xml.

Name - Name of the Registrar that can be more easily referred to.  
GURID (Globally Unique Identifier) - This is similar to the GURID (IANA ID) for 
registrars or could be derived from it to create a globally unique identifier 
for resellers.  
RDAP URL - URL that can be referenced in the Registry RDAP to get the reseller 
information.  Any additional information associated with the Reseller can be 
retrieved by the authoritative source for this information and following the 
local privacy laws and regulations.  Although the reseller name is the only 
attribute that we’ve discussed thus far in RDAP, the technical solution should 
support additional information that can satisfy the local privacy laws and 
regulations effectively. 

Interesting idea, we start mixing EPP and RDAP here…. For the EPP specification 
I would add an URL in the EPP XML and in the server policy I would 
state/specify that this must be an RDAP specific URL. What if there is a ccTLD 
with no RDAP support, one can simply add the website of the reseller. But I 
agree that these fields are the bare minimum.
 
Need to be capable of linking registry objects to the reseller object via the 
EPP Reseller Extension.  The only attribute that is needed is the reseller 
identifier.  If more information is needed, the EPP Reseller Mapping can be 
used to get the GURID and the RDAP URL for subsequent lookups.  We don’t need 
or want any additional attributes in the links.  What would happen if the 
reseller name changed or any other relevant reseller information changed?  I 
don’t believe we would want to require an update to a large set of registry 
objects.  
+1, exactly what I had in mind. 


Thoughts? 

—

JG




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

703-948-3271

Re: [regext] Meeting in Seoul

[Linlin Zhou]

Dear Chair,
I would like to have 5-10 minutes to give an update on reseller reviews 
discussion on the mailing list. Thank you.

Regards,


Linlin Zhou
 
From: Antoin Verschuren
Date: 2016-09-26 22:06
To: regext
Subject: [regext] Meeting in Seoul
Dear WG,
 
It’s this time again that we need to start thinking of our next meeting in 
Seoul.
Jim and I have looked over our chartered milestones, and Jim is going to reach 
out to authors of documents that did not seem to have made progress to ask for 
a status update.
 
In the mean time, we need to schedule for Seoul.
Looking at the list of documents and progress, we intend to ask for a 90 minute 
time slot in Seoul.
 
To get a sense if that’s enough, we ask you if there is anything special you 
would like to discuss in Seoul, including the chartered documents or documents 
to be adopted.
Apart from status updates, there’s encouragement within the IETF to devote part 
of our time to unstructured collaboration, to see if that can progress our work 
faster.
We may put up an agenda item to discuss that in Seoul, but if you already have 
some ideas we would like to hear from you. Think of things like a demo, hacking 
session, compliance testing, or a reviewers meeting request you would like to 
clarify during the meeting.
 
Please let us know before Friday, as that is our deadline for meeting sessions 
requests.
 
regards,
 
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] I-D Action: draft-ietf-regext-reseller-ext-01.txt

[Linlin Zhou]

This is a very minor update, mostly just to keep the document alive to discuss 
on path of reseller object or entity object with multiple roles.

Regards,


Linlin Zhou
 
From: internet-drafts
Date: 2016-12-07 16:30
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions of the IETF.
 
Title   : Reseller Extension for the Extensible Provisioning 
Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-reseller-ext-01.txt
Pages   : 18
Date: 2016-12-07
 
Abstract:
   This mapping, an extension to EPP object mappings like the EPP domain
   name mapping [RFC5731], to support assigning a reseller to any
   existing object (domain, host, contact) as well as any future
   objects.  Specified in Extensible Markup Language (XML), this
   extended mapping is applied to provide additional features required
   for the provisioning of resellers.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-reseller-ext/
 
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-regext-reseller-ext-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-reseller-ext-01
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt

[Linlin Zhou]

Dear Antoin,
Thanks for your review. Please see my feedback below.

Regards,


Linlin Zhou
 
From: Antoin Verschuren
Date: 2017-01-17 23:57
To: Gould, James
CC: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
Op 9 jan. 2017, om 20:05 heeft Gould, James  het volgende 
geschreven:

JG-The existing title “Extensible Provisioning Protocol (EPP) Reseller 
Mapping” follows the model set by the EPP Object RFC’s, as in EPP Domain Name 
Mapping (RFC 5731), EPP Host Mapping (RFC), andEPP Contact Mapping (RFC 
5733) for Object-level Extensions as defined in RFC 3735.  


 
JG-The titles for Command-Response Extensions in RFC 3735 has not been as 
consist.  I believe it would be best to match the title convention of RFC 5910 
for the Reseller Command-Response Extension as in“Reseller Extensions 
Mapping for the Extensible Provisioning Protocol (EPP)”. 
I recommend to use the convention “Protocol Extensions Mapping” for a 
Protocol-level Extension.   

Thank you for comparing, I hadn’t done all the consistency checking yet.
I agree with you that the object extension title is consistent and for the 
command-response extension it is best to follow the RFC 5910 convention as you 
suggest.

[Linlin] The name of "draft-ietf-regext-reseller-ext-01" will be modified to 
"Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)" to 
be consistent with RFC 5910.

Both of the abstracts need to be rewritten as I believe they are mixed up.
 
JG-I believe to help with the mix up, the last sentence of the 
draft-ietf-regext-reseller-ext abstract can be modified to better reflect the 
purpose of the reseller command-response extension.  

Since the document names and titles can be made consistent but not too 
revealing to non-epp-convention-experts, I agree that the abstract could be of 
much help in avoiding confusion.

JG-Agreed that the introductions can be cleaned up and made more consistent.  I 
also agree that the reference to ICANN should be removed.  Your suggested text 
looks like a good starting point. 

Ok.

[Linlin] The abstract and introduction will be revised as suggested to make it 
more clear.

JG-A reseller may be a reseller of multiple registrars, but they would have 
a unique identifier per registrar.  There is a direct relationship between the 
registry and registrar and the reseller and registrar, so although a
reseller may use multiple registrars, they would be managed independently by 
the registrar and therefore would have a unique identifier per registrar.  

Ok, I understand this pragmatic approach. While it is a pity registration 
process wise that a reseller does not have one unique ID per registry, the idea 
behind one ID per registrar is because of the assignment of the ID’s for 
maintenance by different registrars.

My major concern for section 3 however is that it mixes up "server/client” 
(EPP syntax) and "registry/registrar” (ICANN/Domain registration syntax) which 
makes it confusing to read.
We should make a clear choice in what verbs to use. The above sentence 
could also read:

Ok, I understand this pragmatic approach. While it is a pity registration 
process wise that a reseller entity does not have one unique object per server, 
the idea behind one object ID per client is because of the assignment of 
the ID’s for maintenance by individual clients.
 
And then add the syntax definition in [ID.draft-ietf-regext-reseller], and 
words on who assigns the ID according to what rules 
(first-come-first-serve/registry defined/registrarid preceded?)
 
JG-It would be server defined but would be linked to the sponsoring 
registrar (client).  We could look to have the identifier, which needs to be 
server-unique, along with a globally unique identifier (ROID) that  
includes the full set of unique identifiers for a reseller.  

If it is "server defined” as you intend, then there should be some text 
that says that. 
It must be clear to server operators that they need to define their ID 
uniqueness algorithm as part of their local policy. 
The server operator must define this algorithm itself as it is not defined 
in this document.
It must be clear the server defines the algorithm, and not the client.
And then it’s strange that the client needs to assign the ID according to 
the servers algorithm.
I would say that it’s then wise to leave the assignment of the ID to the 
server and not the client like it is done with handles.

The more general question I had is if this ultimate freedom for the server 
to choose an algorithm is wise or necessary or that it adds more complexity to 
the design choices the server operator needs to make.
We can give some examples to server operators on what sort of local 
uniqueness policy server operators could use, like first-come-first-served, 
fixe

Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

[Linlin Zhou]

Thanks for chair's support. We really need more options from WG to decide the 
drafts' direction.
From the perspective of authors, we still think a reseller object is a more 
preferable way to fullfil the current requirements. But a more generic object 
is an optional choice for us to consider. And we need some discussion on the 
generic attributes for the new object.
Any comments or opinions are warmly welcome.

Regards,


Linlin Zhou
 
From: Antoin Verschuren
Date: 2017-02-07 18:18
To: regext
Subject: [regext] Working group action required on 
draft-ietf-regext-reseller-ext-01.txt
Dear working group,

This is a request for action for you! Yes you! Reader of this mail, participant 
in this working group, or provisioning expert you forward this mail to.

Resulting from our last session in Seoul and follow up discussion on the 
mailinglist a few weeks ago, we still need to make a clear decision on advise 
for the authors of the reseller drafts in which direction the working group 
wants these documents to progress. So far, there has not been an overwhelming 
feedback. We realize that not every draft may attract your attention, but for 
this working group to produce any quality documents, it’s vital that drafts are 
reviewed and multiple angle advise is given. 

This is a request to please take some time to review the purpose of the 
reseller drafts. 
Detailed XML review is welcomed, but to answer this one question that the 
authors are desperately waiting on, quantity of opinions and a good generic 
overview of EPP and future registration processes is most important.

To summarize where we left off in Seoul, and the question that we need an anser 
for is the choice between 2 options that we have left to register resellers in 
EPP.
I have renamed these option 1 and 2 (resulting from options C and D during the 
session in Seoul).

Option 1: A dedicated reseller object.
This is the pragmatic approach. We define an object that is only for resellers, 
as that is the only question on the table now.
+ Only define attributes needed for resellers now.
- Hard to reuse or adjust after data is provisioned, and future roles will need 
a newly defined dedicated object as well.

Option 2: A generic organization object that can also be used for resellers.
This is the more future proof approach, where an organization object can be 
used for resellers now, but can be used for provisioning future roles as well 
(think dns-operator, auditor, RDAP access) by tagging the relationship role the 
organization has with other objects.
+ No need to reinvent the wheel in the future, multiple roles can exist, fewer 
objects needed.
-  More work now to define generic attributes and which attributes are 
mandatory or optional for a reseller role to provision. A need to define 
relations to other objects.

It boils down to this simple question:
Do we think every role an organization has needs a separate object in EPP, or 
do we think an organization can have more than one role in the registration 
process and we can identify this role in relation to other objects in EPP.

Please state your choice and motivation as an advise to the authors by 
answering to this thread.
Be aware that other options have already been discussed and were rejected. So 
please don’t make the choice more difficult by inventing an option 3.

Regards,

- -- 
Antoin Verschuren

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






Op 18 jan. 2017, om 06:40 heeft Linlin Zhou  het volgende 
geschreven:

Dear Antoin,
Thanks for your review. Please see my feedback below.

Regards,


Linlin Zhou
 
From: Antoin Verschuren
Date: 2017-01-17 23:57
To: Gould, James
CC: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
Op 9 jan. 2017, om 20:05 heeft Gould, James  het volgende 
geschreven:

JG-The existing title “Extensible Provisioning Protocol (EPP) Reseller 
Mapping” follows the model set by the EPP Object RFC’s, as in EPP Domain Name 
Mapping (RFC 5731), EPP Host Mapping (RFC), andEPP Contact Mapping (RFC 
5733) for Object-level Extensions as defined in RFC 3735.  


 
JG-The titles for Command-Response Extensions in RFC 3735 has not been as 
consist.  I believe it would be best to match the title convention of RFC 5910 
for the Reseller Command-Response Extension as in“Reseller Extensions 
Mapping for the Extensible Provisioning Protocol (EPP)”. 
I recommend to use the convention “Protocol Extensions Mapping” for a 
Protocol-level Extension.   

Thank you for comparing, I hadn’t done all the consistency checking yet.
I agree with you that the object extension title is consistent and for the 
command-response extension it is best to follow the RFC 5910 convention as you 
suggest.

[Linlin] The name of "draft-ietf-regext-reseller-ext-01" will be modified to 
"Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)" to 
be consistent with RFC 5910.

Bo

Re: [regext] Working Session @ IETF 98

[Linlin Zhou]

Thanks James.
I am interested and will participate in the reseller sub group. Hope we can 
have extensions to fulfill most people's requirements.

Regards,


Linlin Zhou
 
From: Gould, James
Date: 2017-03-03 21:36
To: Antoin Verschuren; regext
Subject: Re: [regext] Working Session @ IETF 98
Antoin,
 
I’m willing to help facilitate or participate in the reseller drafts 
(draft-ietf-regext-reseller and draft-ietf-regext-reseller-ext) sub-group; 
although the draft-ietf-regext-epp-fees sub-group is a high priority for me.  
You may be able to split it based on EPP based sub-groups and RDAP based 
sub-groups.  
 
For the draft-ietf-regext-epp-fees sub-group, I particularly would like to 
discuss the policies around the handling of premium domain names.  The specific 
policies that I would like to discuss include:
 
1. Should a create fail if the client does not pass a fee that is greater than 
or equal to the premium domain name fee?
2. Should a premium domain name be returned as unavailable in the check if the 
fee extension is not passed, since the create would most likely fail later in 
the purchase flow?
3. Should we have text in the draft with guidance around these and other 
policies?   
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
VerisignInc.com <http://verisigninc.com/> 
 
On 3/3/17, 5:23 AM, "regext on behalf of Antoin Verschuren" 
 wrote:
 
Dear WG,

Important questions below.
As you may have seen, we have requested 2 meeting slots in Chicago.
The first slot will be an experimental working session.
It will be similar to this experiment: 
https://trac.ietf.org/trac/iesg/wiki/MeetingExperiments

For this experiment to succeed, it will be vital that the participants have 
prepared.
It will not be a session to sit in the back of the room reading email.
This means:

-You must have read and have an opinion or questions about at least one of 
the documents discussed here.
-Prepare your questions or text and choose a subgroup from the listing 
below beforehand.

The setup of this session will be as followed:
-We will have a short introduction with a sum-up of the sub-groups and 
documents that will be discussed.
-We may split up the group in sub-groups, and ask participants to close 
laptops and join a sub-group of their choice.
-We have asked for a room setup where each sub-group will have at least a 
table to sit around.
-We ask each sub-group to appoint a "facilitator” that will lead the 
discussion and summarize the results of the discussion afterwards.
-If there are remote participants for your sub-group, we may ask on-site 
participants to assist in Skype or similar conferencing tools.
-We expect a small presentation by the facilitator with the results of the 
sub-group discusion in the regular session later in the week.
-You will have an opportunity in the regular session to ask questions to 
the whole working group if necessary.

So far we have the following documents for this session:

Facilitator: Document:
Scott draft-hollenbeck-regext-rdap-openid
Scott draft-hollenbeck-regext-rdap-object-tag
Scott draft-fregly-regext-rdap-search-regex
Roger draft-ietf-regext-epp-fees-01

We are considering, but didn’t get confirmation from one of these authors 
yet:

Facilitator: Document:
Jacques? draft-ietf-regext-dnsoperator-to-rrr-protocol-02
Linlin/James? draft-ietf-regext-reseller-ext-01

Please let us know if you want to work on these documents during the 
working session.
Perhaps people other than the authors may have an interest to discuss.

Not all documents will have the same interest or expertise.
Questions we have for the WG now:

-Do you think we should treat the documents in parallel or serial ?

We want to give enough time to each document to discuss and do actual work 
like writing text.
Since Scott is leading 3 document discussions, it will be hard to treat 
them in parallel, but how about the others?

-If you are a remote participant and want to join one of the discussions, 
please identify yourself on the mailinglist so on-site participants that will 
join the same sub-discussion can offer to assist in remote participation when 
we decide to treat them in parallel. It will also allow for the facilitator to 
get a sense of interest and prepare discussions.



The preliminary agenda and call for agenda items for our regular meeting 
session will follow later today.

Regards,

Antoin and Jim.

- --
Antoin Verschuren

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







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

[regext] implementation status of organization extension

[Linlin Zhou]

Dear all,
To support WG's suggestion, the organization extension drafts plan to add a 
section on implementation status. If you have already implemented organization 
extention, know of any existing implementations or planned implementations, 
please send me a mail for us to update the drafts. Any reviews or comments will 
be appreciated. 

Regards,


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

[regext] org extensions for transfer requirement

[Linlin Zhou]

Dear all,
Sorry that I can't attend the Singapore meeting in person, but I've followed 
the discussion remotely. I heard that org extensions could be used for transfer 
requirement in addtion to providing some generic organization information to 
the registry. Could James or Roger give us some more details on this? I think 
we need some discussions to optimize the org extensions and push them forward. 

Regards,


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

Re: [regext] org extensions for transfer requirement

[Linlin Zhou]

Dear James,
Thanks for your detailed explanation. I agree that the org extensions could 
help to get more organization-level information, such as registrar. The 
registry have organization information from registrar which could be posted in 
WHOIS., and on the other side, the registrar could also get org information 
from registry to help the authentication process. What about others thoughts?



Linlin Zhou
 
From: Gould, James
Date: 2017-11-23 03:11
To: Linlin Zhou; regext
Subject: Re: [regext] org extensions for transfer requirement
Linlin,
 
What was discussed was leveraging the organization drafts to provide registrar 
information in support of transfers.  The EPP auth info value that is validated 
by the Registry is currently a single authentication factor in performing a 
transfer, while the second authentication factor performed by the Registrar is 
the Form of Authorization (FOA), 
https://www.icann.org/resources/pages/foa-auth-2004-07-12-en, which is directly 
dependent on WHOIS (Registry and Registrar) information.  As outlined in the 
ICANN Transfer Policy, 
https://www.icann.org/resources/pages/transfer-policy-2015-09-24-en, the 
Gaining Registrar must receive authorization from the Registered Name Holder 
(registrant) or the Administration Contact (admin) as listed in the losing 
registrar’s or applicable registry’s WHOIS service with the FOA. The Losing 
Registrar must also send an FOA to the Registrant.  The following pieces of 
information is needed to retrieve what is needed to populate the FOA for the 
Gaining Registrar and the Losing Registrar:
 
1.  Gaining Registrar
a.   Registrar WHOIS server from Registry WHOIS
b.  Registrant and admin contact email addresses from Thick Registry WHOIS 
or Registrar WHOIS
c.   Registrant and admin name from Thick Registry WHOIS or Registrar WHOIS
d.  Losing Registrar Name from Registry WHOIS
e.   May need the Losing Registrar Web URL for coordination.
2.  Losing Registrar (Registrar of Record)
a.   Registrant and admin contact email addresses from Losing Registrar 
system
b.  Registrant and admin name from Losing Registrar system
c.   Gaining Registrar Name by mapping transfer query response 
 element to name 
  i.  There is 
no standard mechanism known for definition of  (e.g., use of 
Registry Account ID, use of IANA ID)
ii.  There is 
no standard mechanism for looking up the Registrar Name given the  
value.  WHOIS provides registrar lookup by name and not by ID. 
d.  May need the Gaining Registrar Web URL for coordination.
 
Considering that the Registry has the Registrar information, why is the Gaining 
Registrar and Losing Registrar going to WHOIS to obtain the information needed 
to authenticate a transfer?  There are problems with this that the org 
extensions may help:
 
1.  Having to access a separate protocol to obtain information that is 
available in the Registry.  Specifically, the information that can be made 
available via the org extensions in EPP using a standard lookup key (e.g., 
organization identifier ) include:
a.   Registrar WHOIS Server
b.  Registrar Name
c.   Registrar URL and other attributes to help with coordination
2.  Access to the registrant and admin contact name and email addresses.  
How is this information made available today and will that change in the future 
(WHOIS, RDAP, differential access)?  
a.   More may be needed of the trusted channel with the Registry and the 
org extensions to coordinate the transfer policy.
 
As noted previously on the list, we have a propriatary Whois Info EPP Extension 
(https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_whois-info_v01.html)
 that provides the basics of the Registrar WHOIS Server, Registrar Name, and 
the Registrar URL attributes.  The org extensions can be extended to provide 
additional registrar-level attributes in support of the transfer policy. 
 
Thoughts?  
 
—
 
JG



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

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

Verisign.com 
 
From: regext  on behalf of Linlin Zhou 

Date: Monday, November 20, 2017 at 8:13 PM
To: regext 
Subject: [EXTERNAL] [regext] org extensions for transfer requirement
 
Dear all,
Sorry that I can't attend the Singapore meeting in person, but I've followed 
the discussion remotely. I heard that org extensions could be used for transfer 
requirement in addtion to providing some generic organization information to 
the registry. Could James or Roger give us some more details on this? I think 
we need some discussions to optimize the org extensions and push them forward. 
 
Regards,


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

Re: [regext] regarding draft-ietf-regext-org-01 and draft-ietf-regext-org-ext-01

[Linlin Zhou]

Dear all,
The org drafts have been updated with the implementation status section. In 
addition, we also have discussed the transfer requirement at Singapore meeting 
and on the mailing list, which will help providing registrar information needed 
to authenticate a transfer. Any comments or reviews are appreciated. After 
that, we will request for the WG last call.

Regards,


Linlin Zhou
 
From: James Galvin
Date: 2017-12-15 22:26
To: Registration Protocols Extensions
Subject: [regext] regarding draft-ietf-regext-org-01 and 
draft-ietf-regext-org-ext-01
The authors have added the implementation status sections that the 
working group requested.  At this time we need final working group 
review.  The authors are ready to ask for working group last call and in 
order to proceed the Chairs need to see support for these documents on 
the list.
 
Please indicate your support or comments regarding these documents.
 
Antoin and Jim
 
___
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] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext

[Linlin Zhou]

Dear Patrick,
Thanks for your careful review and comments. Please find my feedbacks below. 
Some of the text will be updated in the next version.

Regards,


Linlin Zhou
 
From: Patrick Mevzek
Date: 2017-12-27 14:02
To: regext
Subject: [regext] My review of draft-ietf-regext-org and 
draft-ietf-regext-org-ext
Hello authors,
 
Please find my review of your two drafts.
I do not think they are ready for WG last call yet.
 
=
draft-ietf-regext-org
=
 
* Abstract: "provisioning and management of organization object"
I would says objects in plural is more logical.

[Linlin] Yes, it will be modified to "provisioning and management of 
organization objects".

* 1. Introduction
Same remark about the plural.

[Linlin] Change to "such as registrars, resellers, DNS service operators, or 
privacy proxyies".
 
"There are many domain entities" : maybe drop domain here?
Like: There are many entities 

[Linlin] Ok.
 
Also I have mixed feelings on "These kind of entities have not been formally
   defined in EPP"
This is not true for registrar, for example, it is clearly defined in RFC3375.
 
So you will need to rephrase your paragraph.

[Linlin] How aboult change the text to "These kind of entities have not been 
formally defined as an object in EPP".
 
* 3) I do not understand "can be viewed and modified by the sponsoring client 
or the server."
Why do you specify "or the server." ?
The fact that the registry can view the data seem quite obvious but what
are you trying to infer by speaking about server modifications?
I think it would be far simpler to just remove "or the server."

"This section describes each attribute type in detail."
You can remove "type" I think.
 
[Linlin]  This section tries to be consistent with RFC5733. You can find "An 
EPP contact object has attributes and associated values that can be viewed and 
modified by the sponsoring client or the server. This section describes each 
attribute type in detail." in section 2 of RFC5733.

* 3.1
"Organization identifiers are character strings with a specific
   minimum length, a specified maximum length, and a specified format.
   Organization identifiers use the "clIDType" client identifier syntax
   described in [RFC5730]."
 
The clIDType in RFC5730 specifies a minimum and maximum length but no format,
just that it is a token. So the sentence is kind of wrong.

[Linlin] This part of words also tries to be consistent with RFC5731, RFC5732 
and RFC5733. I guess that token is a formatted string that removes the spaces, 
tabs , line breaks.
 
* 3.2
This does not seem clear enough to me.
I have to wait for further examples down below to better understand this
But did not found enough examples or further explanations,
so all of this is confusing to me.

* 3.2.1
"Its corresponding element is  with an
   "roleStatus" attribute."
=> a instead of an I think

[Linlin] Yes. 

In fact the whole of 3.2 / 3.2.1 / 3.2.2 feels very complicated and not clear 
to me.

[Linlin] I'll try to add an example like this,

S:  
S: registrar 
S: 1362 
S: 

* 3.3 what does this section has to do with the rest of the document?
[Linlin] We intend to explain that an organization would have one or more 
contacts. So this section specifies the contact identifier formats.

* 3.4
"terminated: The organization has been terminated MUST NOT be
  linked."
=> and is missing before MUST NOT?

[Linlin]  I think this should be "The organization which has been terminated 
MUST NOT be linked."
 
* 3.6 "the parent identifier is
   not defined for the top level reseller, namely the registrar of the
   registry."
I am not absolutely sure that registrars would be happy to be depicted as 
just resellers of the registry, and also I am not sure what this sentence
adds to the protocol.

[Linlin] We are trying to say that registrar, N-tier reseller and reseller 
customer are three types of organization in reseller business model. Only 
N-tier reseller and reseller cutomer could have a parent ID.
 
* also in section 3 somewhere you should speak about timestamps
since you have crDate, etc.
See §2.4.  Dates and Times for example in RFC5731.
[Linlin] Ok.
 
* 4.1
"EPP provides two commands" 
It is instead 3 if you add the  case, so you should rephrase that
paragraph.
[Linlin] I'll reconsider the text and udpate in the next version.
 
* 4.1.2
"A  element"
Only one status available here?
If multiple allowed, you have to fix this sentence and the associated XML 
schema.
[Linlin] I think multiple statuses are allowed. A maxOccurs attribute will be 
added in the "status" element.

"   Example  response for "Example Reg

Re: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext

[Linlin Zhou]

Dear Pierter,

Thanks for your comments. Please find my feedback below.

Regards,


Linlin Zhou
 
From: Pieter Vandepitte
Date: 2018-01-05 02:22
To: regext@ietf.org
Subject: Re: [regext] My review of draft-ietf-regext-org and 
draft-ietf-regext-org-ext
Hi all,

In general, I share the same vision as Patrick. For me, the organization role 
thing is still unclear to me. Especially its relation with the orgext:id links 
from other entities to the organization.
I think this needs further explanation in the draft, if necessary with some 
ascii art drawings to explain the model.

Maybe a bit late as I only very recently started following the list, but if I 
would have to come up with an organization model:

Organisations are entities:
linked to 1 or multiple contacts. I would remove the org:postalInfo in favour 
of a list of contacts, which is already in the current model. The org:postaInfo 
is also a contact, so redundant and could be moved to the list of contacts. 
Moreover, it is useful to describe the type of contact, which is not possible 
to explicitly describe with the org:postalInfo element (is it the internal 
contact, tech contact, public contact?)
having zero, one or multiple relations with other organizations. In my opinion 
a role is a property of the relation an organization has with another 
organization. E.g. X could be reseller of Y and at the same time registrar of Z 
(yes, I would even create an object for the current registry Z, which allows to 
exchange registry contact information with the registrar using org:info). So I 
would remove the parentId and the role thing in favour of a new multi-occurence 
"link" element of organization, having a role and an orgid attribute.
On the other hand, other entities like domains, contacts, hosts can also have 0 
or more relations with an organization (which is basically what's in the other 
draft)
[Linlin] 1. We take an organization as a entity that may have some contacts and 
have its own postal information. Contacts have a "type" attribute. The type 
values include "admin", "tech", "billing", "abuse", and "custom".
2. Until now, there seems no explicit need to create a "registry" organization. 
I can undrerstand your thought, but it's hard to say whether this is a proper 
solution. 
3. Yes.

Maybe not related to the review of the draft (but related to the draft itself): 
What is the purpose of this draft? It seems that it aims to build a model for 
all organisations involved in the domain name registration business, which I 
doubt there is a need for... But correct me if I'm wrong :-)
I think there is a need to link more contact information to a registration (and 
to a greater extent any EPP object). Contact information like reseller, proxy 
services, ...
So why not stick to that purpose and simply extend the contactAttrType for 
contact role with values like "reseller", "proxy", ... and link a domain to a 
contact using these new values? 

[Linlin] The org drafts have been discussed for a long period of time. From the 
very beggining, our requirements was to have a reseller extension for the 
existing objects to show the whois information of some resellers. Then we found 
that reseller may have its own contacts and hierarchy. So the reseller-ext and 
a new reseller object drafts were submitted. WG had many voices, reuse 
contacts, reseller object, generic object, etc.. Creating a generic 
organization object was finally selected as the WG direction. So the authors 
modified the whole reseller object to organization object. Making extensions 
for EPP is a mechanism according to RFC3735. Revising the RFC5733 seems not to 
be a very practical way.

Kind regards

Pieter
 

On 27 Dec 2017, at 07:02, Patrick Mevzek  wrote:

Hello authors,

Please find my review of your two drafts.
I do not think they are ready for WG last call yet.

=
draft-ietf-regext-org
=

* Abstract: "provisioning and management of organization object"
I would says objects in plural is more logical.

* 1. Introduction
Same remark about the plural.

"There are many domain entities" : maybe drop domain here?
Like: There are many entities 

Also I have mixed feelings on "These kind of entities have not been formally
  defined in EPP"
This is not true for registrar, for example, it is clearly defined in RFC3375.

So you will need to rephrase your paragraph.

* 3) I do not understand "can be viewed and modified by the sponsoring client 
or the server."
Why do you specify "or the server." ?
The fact that the registry can view the data seem quite obvious but what
are you trying to infer by speaking about server modifications?
I think it would be far simpler to just remove

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

[Linlin Zhou]

Dear all,
The org drafts have been updated to 02 version. We received comments and 
feedbacks on the mailing list. Based on the discussion, some comments are 
accepted and more specific examples have been added in the document. Any other 
commnets are welcome.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-02-28 11:27
To: i-d-annou...@ietf.org
CC: regext
Subject: I-D Action: draft-ietf-regext-org-ext-02.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-ext-02.txt
Pages   : 24
Date: 2018-02-27
 
Abstract:
   This mapping, an extension to EPP object mappings like the EPP domain
   name mapping [RFC5731], to support assigning an organization to any
   existing object (domain, host, contact) as well as any future
   objects.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-ext-02
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-ext-02
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-02
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear Scott,
Thanks for your comments. I've already updated them in the new version and will 
submit it before the end of WGLC.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Hollenbeck, Scott
Date: 2018-04-13 22:41
To: 'gal...@elistx.com'; 'regext@ietf.org'
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Hollenbeck,
> Scott
> Sent: Friday, April 13, 2018 9:48 AM
> To: 'gal...@elistx.com' ; 'regext@ietf.org'
> 
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
>
> > -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 
> > 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.
 
Sorry, missed one: In Section 7.2, the IESG should be named as the registrant 
for a standards track extension.
 
Scott
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

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
 
From: Pieter Vandepitte
Date: 2018-04-13 22:06
To: James Galvin
CC: Registration Protocols Extensions
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.


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 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". 
[Linlin] Until now, the optional is only used for the IANA-id. I am not sure 
what are other sources to get the roleid? 

(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)? 
[Linlin] There are some words in section 4.2.2 "An organization object MUST NOT 
be deleted if it is associated with other known objects.  An associated 
organization MUST NOT be deleted until asso

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

[Linlin Zhou]

Dear James,

Thanks for your comments and suggestions. I will update the words and submit 
the new drafts before the end of WGLC.


Regards,

Linlin



-原始邮件-
发件人:"Gould, James" 
发送时间:2018-04-21 05:54:26 (星期六)
收件人: "James Galvin" , "Registration Protocols Extensions" 

抄送:
主题: Re: [regext] WGLC: draft-ietf-regext-org-ext-02



I'm am a co-author on this draft, but I did a re-read and I have the following 
items that need to be addressed:

 

In section 4.1.2 “EPP  Command”
I recommend changing “based on its server policy” to “based on server policy”. 
I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
Change “One or more  elements…” to “Zero or more  
element…”, since the XML schema supports zero organizations and there is an 
example without zero organizations.
The info command example can be removed since it is not applicable.
In section 4.2.1 “EPP  Command”
The  element supports a list of  elements and not 
just one.  My recommendation is to modify the description of the  
element to be:

   i.  “One or 
more  elements that contain the identifier of the organization.”

I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
I recommend removing the roid attribute from the  element of the 
 examples.  
In section 4.2.5 “EPP  Command”
Modify “…modify the attributes of a domain object” to “…modify the attribute of 
an object”, “In addition to the EPP command elements described in the EPP 
domain object,...” to “In addition to the EPP  command elements, …”, 
and “wants to update the domain object” to “wants to update the object” to be 
object agnostic. 
Modify “The , , and  elements…” to ““The 
, , and  elements…”.
The , , and  elements support a list of 
 elements and not just one.  My recommendation is to modify the 
description of the  element to be:

   i.  “One or 
more  elements that contain the identifier of the organization.”

Shouldn’t the “addRemChgType” in the XML schema remove the minOccurs=”0”, since 
I believe that if the , , or  element is 
provided that it should contain at least one organization?
I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
I would remove the “domain with no organization” example since it looks like a 
duplicate of the “adding multiple organizations” example, and I don’t believe 
it is applicable.

  

—

JG

 

 

 

James Gould

Distinguished Engineer

jgo...@verisign.com

 

703-948-3271

12061 Bluemont Way

Reston, VA 20190

 

Verisign.com 

On 4/20/18, 9:36 AM, "regext on behalf of James Galvin" 
 wrote:

 

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.

   

Thanks,

   

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:

>

> Organization Extension for the Extensible Provisioning Protocol (EPP)

> https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

>

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

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

[Linlin Zhou]

Hi James,
I am updating the draft and I found that the example of "domain with no 
organization" is following,


  

  
example.com
  


  

  

ABC-12345
  
 
 
I'll modify this example.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-04-23 14:13
To: Gould, James
CC: Registration Protocols Extensions; James Galvin
Subject: Re: [regext] WGLC: draft-ietf-regext-org-ext-02
Dear James,
Thanks for your comments and suggestions. I will update the words and submit 
the new drafts before the end of WGLC.
Regards,
Linlin

-原始邮件-
发件人:"Gould, James" 
发送时间:2018-04-21 05:54:26 (星期六)
收件人: "James Galvin" , "Registration Protocols Extensions" 

抄送: 
主题: Re: [regext] WGLC: draft-ietf-regext-org-ext-02

I'm am a co-author on this draft, but I did a re-read and I have the following 
items that need to be addressed:
 
In section 4.1.2 “EPP  Command” 
I recommend changing “based on its server policy” to “based on server policy”.  
I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
Change “One or more  elements…” to “Zero or more  
element…”, since the XML schema supports zero organizations and there is an 
example without zero organizations.
The info command example can be removed since it is not applicable.
In section 4.2.1 “EPP  Command” 
The  element supports a list of  elements and not 
just one.  My recommendation is to modify the description of the  
element to be:
   i.  “One or 
more  elements that contain the identifier of the organization.”
I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
I recommend removing the roid attribute from the  element of the 
 examples.   
In section 4.2.5 “EPP  Command” 
Modify “…modify the attributes of a domain object” to “…modify the attribute of 
an object”, “In addition to the EPP command elements described in the EPP 
domain object,...” to “In addition to the EPP  command elements, …”, 
and “wants to update the domain object” to “wants to update the object” to be 
object agnostic.  
Modify “The , , and  elements…” to ““The 
, , and  elements…”.
The , , and  elements support a list of 
 elements and not just one.  My recommendation is to modify the 
description of the  element to be:
   i.  “One or 
more  elements that contain the identifier of the organization.”
Shouldn’t the “addRemChgType” in the XML schema remove the minOccurs=”0”, since 
I believe that if the , , or  element is 
provided that it should contain at least one organization?
I recommend changing the sentence ‘An attribute “role” associated with 
 is used…’ to ‘The “role” attribute is used to represent the 
relationship that the organization has to the object’.
I would remove the “domain with no organization” example since it looks like a 
duplicate of the “adding multiple organizations” example, and I don’t believe 
it is applicable. 
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com <http://verisigninc.com/> 
On 4/20/18, 9:36 AM, "regext on behalf of James Galvin" 
 wrote:
 
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.

Thanks,

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:
>
> Organization Extension for the Extensible Provisioning Protocol (EPP)
> https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
>
> 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 submitte

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

[Linlin Zhou]

Dear all,
Thanks for your comments. I've already updated the org and org-ext drafts to 
version 03. Any other suggestions or comments are welcome.  

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-04-27 18:02
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-03.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors     : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-03.txt
Pages   : 40
Date: 2018-04-27
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-03
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-03
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-03
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] 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 
Date: Wednesday, April 25, 2018 at 8:29 AM
To: James Galvin , Registration Protocols Extensions 

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

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

[Linlin Zhou]

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

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-04 13:51
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-04.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors     : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-04.txt
Pages   : 41
Date: 2018-05-03
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-04
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-04
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Thanks James.
I will have a quick update today for version 05.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-05-04 22:40
To: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-04.txt
Linlin, 
 
In reviewing the draft-ietf-regext-org-ext changes in 
draft-ietf-regext-org-ext-04, I have the following feedback:
 
The minOccurs=”0” needs to be removed from the addRemChgType type of the XML 
schema to match the description “One or more  element..” in section 
4.2.5 “EPP  Command” and to ensure that there is not an empty 
, , or  element.  The , 
, and  elements are optional, but if provided must have at 
least one  child element.   
Change “One or more  element that contains…” to “One or more 
 elements that contain…” in section 4.2.5 “EPP  Command”. 
I recommend removing the third paragraph of section 8 “Implementation Status”, 
since the sub-sections explicitly define the specific implementation status 
information.  At a minimum, I would like the sentence “Verisign has already 
implemented this extension” to be removed.
I also recommend removing section 8.3, since I don’t believe implementation of 
the Reseller Extension is relevant to the Organization Extension. 
I would remove the Informative Reference to draft-ietf-regext-reseller-ext from 
the draft (e.g., section 11.2).
  
—
 
JG



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

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

Verisign.com 
From: regext  on behalf of Linlin Zhou 

Date: Friday, May 4, 2018 at 2:56 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-04.txt
 
Dear all,
The org drafts have been updated to version 04 to address all the received 
comments during WGLC. And a new section of implemetation status was added.  
We'd like to have the chairs' instruction to the next step for these two drafts.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-04 13:51
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-04.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors     : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-04.txt
Pages   : 41
Date: 2018-05-03
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-04
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-04
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear James,
I think the  response is in the section 4.1.2. So it should be 
The description of the  element in 4.1.2 should be “One or more 
 elements that contain the role statuses” instead of “Zero or more 
 elements that contains the role type”.  I believe the info 
response should always include at least one role status value.

Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-05-04 20:59
To: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-04.txt
Hi,
 
In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-04, I 
have the following feedback:
 
The description of the  element in 4.2.1 should be “One or more 
 elements that contain the role statuses” instead of “Zero or more 
 elements that contains the role type”.  I believe the info 
response should always include at least one role status value.  
The description of the  element in 4.2.5 should be “Zero or more 
 elements that contain the role statuses” instead of “Zero or more 
 elements that contains the role type”.  
In 4.2.5, change “A OPTIONAL  element” to “An OPTIONAL  
element”.
I recommend removing the third paragraph of section 8 “Implementation Status”, 
since the sub-sections explicitly define the specific implementation status 
information.  At a minimum, I would like the sentence “Verisign has already 
implemented this object mapping” to be removed.  There is the misspelling of 
“objecct” in that third paragraph.
I also recommend removing section 8.3, since I don’t believe implementation of 
the Reseller Extension is relevant to the Organization Mapping.  
I would remove the Informative Reference to draft-ietf-regext-reseller from the 
draft (e.g., section 11.2). 
  
—
 
JG



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

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

Verisign.com 
From: regext  on behalf of Linlin Zhou 

Date: Friday, May 4, 2018 at 2:56 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-04.txt
 
Dear all,
The org drafts have been updated to version 04 to address all the received 
comments during WGLC. And a new section of implemetation status was added.  
We'd like to have the chairs' instruction to the next step for these two drafts.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-04 13:51
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-04.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors     : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-04.txt
Pages   : 41
Date: 2018-05-03
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-04
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-04
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear all,
To respond the comments, the org drafts are updated to version 05.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-07 16:35
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-05.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-05.txt
Pages   : 41
Date: 2018-05-07
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-05
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-05
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-05
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear all,
The org drafts have been updated to version 06. Please review.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-09 11:15
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-06.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-06.txt
Pages   : 41
Date: 2018-05-08
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-06
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-06
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Dear all,
The org drafts have responded all the comments on the mailing list. The authors 
would like to request to move them to the next step.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-05-09 23:30
To: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-06.txt
Linlin,
 
All of my review feedback has been incorporated into draft-ietf-regext-org-06 
and draft-ietf-regext-org-ext-06.  
 
Thanks,
  
—
 
JG



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

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

Verisign.com 
From: regext  on behalf of Linlin Zhou 

Date: Wednesday, May 9, 2018 at 1:21 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-06.txt
 
Dear all,
The org drafts have been updated to version 06. Please review.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-05-09 11:15
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-06.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF..
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-06.txt
Pages   : 41
Date: 2018-05-08
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-06
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-06
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Final review of draft-ietf-regext-org-06

[Linlin Zhou]

Dear Pieter,
Please find my feedbacks below on other comments besides James' feedbacks. 
Thanks for your review. I am preparing the update.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-05-20 04:29
To: regext
Subject: [regext] Final review of draft-ietf-regext-org-06
Hi Linlin,

I did a review with a magnifying glass. Some things should really be fixed (or 
rather MUST be fixed), some others are opinionated.

I'm preparing a review of the draft-ietf-regext-org-ext-06 too, but that's for 
tomorrow

===
 
3.1.  Organization Identifier
All EPP organizations are identified by a server-unique identifier.
   Organization identifiers are character strings with a specific
   minimum length, a specified maximum length, and a specified format.
   Organization identifiers use the "clIDType" client identifier syntax
   described in [RFC5730].  Its corresponding element is .
 
I would use "specified" instead of "specific". This is more in line with other 
RFCs (domain and contact). It's also a specific length, format etc… but the 
emphasis is on the fact that it's all in the specs (hence specified).

[Linlin] Changed to "with a specified minimum length".
=== 
 
3.2.  Organization Roles
The organization roles are used to represent the relationship an
   organization would have.  Its corresponding element is .
 
⇒ MUST instead of would

An organization object MUST always have at least one associated role. Roles can 
be set only by the client that
Sponsors an organization object. A client can change the role of an 
organization object using the EPP  command.
 [Linlin] Yes.
===

3.2.1.  Role Type
An organization would support a list of roles.  See Section 7.3 for a
   list of values.  Its corresponding element is .

I think the sentence is wrong. You should talk about role type, not about "list 
of roles"

An organization role MUST have a type. […]

[Linlin] "An organization role MUST have a type which support a list of values. 
 See Section 7.3 for the role type values."
===
 
3.2.2.  Role Status
A role of an organization object would have its own statuses.  Its
   corresponding element is .  The values of the role status
   are defined in Section 3.5.
 
I'm not sure if "would" is the best word to use here.

An organization role MAY have a status. […]
 
[Linlin] OK.
===
 
3.4.  Organization Status Values
 
I think you forgot to specify that 

"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkProhibited" status.
 
Or is this in case you want to block linking while there are still links? If 
so, it's useful to specify this:

A client or server MAY combine linked with either clientLinkProhibited or 
serverLinkProhibited if new links must be prohibited [...]

[Linlin] Yes, "clientLinkProhibited" or "serverLinkProhibited" can combine with 
"linked" if new links must be prohibited. Your suggested sentence will be added.
=== 
 
3.5.  Role Status Values
 
[…]
 
o  ok: This is the normal status value for an role that has no
  pending operations or prohibitions.  This value is set and removed
  by the server as other status values are added or removed.
 
⇒ There are no pending statuses for role statuses, so remove that part
 
Also here, I think you forgot to specify that 

"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkedProhibited" status.
 
[Linlin] Please see the above feedback.
===
..

6. Internationalization Considerations
 
   As an extension of the EPP organization object mapping, the elements
   and element content described in this document MUST inherit the
   internationalization conventions used to represent higher-layer
   domain and core protocol structures present in an XML instance that
   includes this extension.
 
⇒ This RFC is not an extension of itself. I would use the same text as in RFC 
5733, especially regarding usage of date and time and the use of int and loc 
address info:
 
   All date-time values presented via EPP MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar.  The XML Schema allows
   use of time zone identifiers to indicate offsets from the zero
   meridian, but this option MUST NOT be used with EPP.  The extended
   date-time form using upper case "T" and "Z" characters defined in
   [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
   values, as the XML Schema does not support truncated date-time forms
   or lower case "T" and "Z" characters.
Humans, organizations, and other entities often need to represent
   social information in both a commonly understood character set and a
   locally optimized character set.  This specification provides
   features allowing representation of social information in both a
   subset of UTF-8 for broad readability and unrestricted UTF-8 for
   local optimization.

I personally have issues with the above claim that "int" - or US-ASCII - is 
commonly understood, but I can live with that for now ;-)  (

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  
 
On 5/23/18, 7:36 AM, "regext on behalf of Pieter Vandepitte" 
 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 
 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  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] Final review of draft-ietf-regext-org-06

[Linlin Zhou]

Yes , I will merge all the comments into the next version. Thanks for review.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-05-25 02:01
To: Gould, James
CC: regext@ietf.org
Subject: Re: [regext] Final review of draft-ietf-regext-org-06
I'm sorry to not have answered your questions up until now... @Linlin, do you 
take into account the remarks of James too?


On 21 May 2018, at 15:40, Gould, James  wrote:

Pieter,
 
Thanks for doing the detailed review.  I’ll let Linlin comment on the proposed 
wording changes.  I have feedback on some of the items below:
 
 
===
 
3.4.  Organization Status Values
 
I think you forgot to specify that
 
"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkProhibited" status.
 
Or is this in case you want to block linking while there are still links? If 
so, it's useful to specify this:
 
A client or server MAY combine linked with either clientLinkProhibited or 
serverLinkProhibited if new links must be prohibited [...]
 
 
The purpose of the [client/server]LinkProhibited statuses are to prohibit 
additional links without impacting the existing links, so you second proposal 
would be the most appropriate.  

Ok

 
 
=== 
 
3.5.  Role Status Values
 
[…]
 
o  ok: This is the normal status value for an role that has no
  pending operations or prohibitions.  This value is set and removed
  by the server as other status values are added or removed.
 
⇒ There are no pending statuses for role statuses, so remove that part
 
Also here, I think you forgot to specify that
 
"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkedProhibited" status.
 
This is related to the proposal on 3.4 above.  There is no need for the 
sentence “"linked" status MUST NOT be combined with either 
"clientLinkProhibited" or "serverLinkedProhibited" status.” since the 
[client/server]LinkProhibited statuses only prohibit future links.

Ok

 
 
4.1.2.  EPP  Command
 
Should we mention what happens in case the querying client is not the 
sponsoring client, or is too much policy?
 
Yes, I believe that returning the organization object and what organization 
object attributes to return is up to server policy.  Maybe it makes sense to 
add a sentence related to it being up to server policy.  


That would be great

 
[…]
   When an  command has been processed successfully, the EPP
element MUST contain a child  element that
   identifies the organization namespace.  The  element
   contains the following child elements:
[…]
   o  Zero or more  elements that contains the operational
  status of the organization, as defined in Section 3.4.
 
⇒ this conflicts with the XML schema and 3.4, which states:
   An organization object MUST always have at least one associated
   status value.  The default value is "ok".
 
I agree that it should it should be “One or more  elements...” to 
match the XML schema.

Ok

 
 4.2.5. EPP  Command
[...]
Zero or more  elements that contains the role type, role
  statuses and optional role id of the organization
 
In my opinion the draft is still vague about which role sub-element of role is 
used for matching the role to be removed (I guess it is the role type, as it is 
the only required element). I would mention that:
 
E.g. in secDNS it is mentioned very explicit;
 
  The  element is part of the Key Data Interface and
  is used to uniquely define the key data to be removed, by using
  all four elements -- , , , and  -- that are guaranteed to be unique.
  There can be more than one DS record created for each key, so
  removing a key could remove more than one DS record.
 
The role type is what is unique for the organization’s role.  There cannot be 
duplicate role types for an organization.  It would be clearer to specify “A 
 element contains the role type of the organization, as defined in 
Section 3.2.  The role type uniquely identifies the role to update.”.  

It would have helped me if that would have been included. It'd be nice if this 
text is added.

 
Good instructions for how to remove a contact, I would also add these 
instructies to parentId, voice, fax email and url:
An empty  element is supported to allow a type of
  ___ to be removed
 
===
 
Maybe it would be best to adopt the language from IETF-98 “Contact Postal Info 
Elements Discussion”, which included the proposal:
 
The  sub-elements do have replace semantics
Existing sub-element data deleted first and then set with updated data.
 types treated independently
Exclusion of a  type does not implicitely delete it.
 type deleted via empty element
 or 
 
The elements supported by the  and  are the list elements 
, , and .  The individual attributes 
(postalInfo can be considered two separate attributes “int” and “loc”) are 
updated using the .  Maybe the introduction sentence “An OPTIONAL 
 element containing the following element, where at least one child 
element MUST be pres

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

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

Re: [regext] Final review of draft-ietf-regext-org-06

[Linlin Zhou]

Dear Pieter,
I am updating the draft-ietf-regext-org. Some of your suggestions will be 
modified in the 07 version. Some will be keep as it is now. Please see my 
feedbacks below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-05-25 09:23
To: Pieter Vandepitte; jgould
CC: regext
Subject: Re: Re: [regext] Final review of draft-ietf-regext-org-06
Yes , I will merge all the comments into the next version. Thanks for review.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-05-25 02:01
To: Gould, James
CC: regext@ietf.org
Subject: Re: [regext] Final review of draft-ietf-regext-org-06
I'm sorry to not have answered your questions up until now... @Linlin, do you 
take into account the remarks of James too?


On 21 May 2018, at 15:40, Gould, James  wrote:

Pieter,
 
Thanks for doing the detailed review.  I’ll let Linlin comment on the proposed 
wording changes.  I have feedback on some of the items below:
 
 
===
 
3.4.  Organization Status Values
 
I think you forgot to specify that
 
"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkProhibited" status.
 
Or is this in case you want to block linking while there are still links? If 
so, it's useful to specify this:
 
A client or server MAY combine linked with either clientLinkProhibited or 
serverLinkProhibited if new links must be prohibited [...]
 
 
The purpose of the [client/server]LinkProhibited statuses are to prohibit 
additional links without impacting the existing links, so you second proposal 
would be the most appropriate.  

Ok
[Linlin]Your suggested text will be added.
 
 
=== 
 
3.5.  Role Status Values
 
[…]
 
o  ok: This is the normal status value for an role that has no
  pending operations or prohibitions.  This value is set and removed
  by the server as other status values are added or removed.
 
⇒ There are no pending statuses for role statuses, so remove that part
 
Also here, I think you forgot to specify that
 
"linked" status MUST NOT be combined with either "clientLinkProhibited" or 
"serverLinkedProhibited" status.
 
This is related to the proposal on 3.4 above.  There is no need for the 
sentence “"linked" status MUST NOT be combined with either 
"clientLinkProhibited" or "serverLinkedProhibited" status.” since the 
[client/server]LinkProhibited statuses only prohibit future links.

Ok

 
 
4.1.2.  EPP  Command
 
Should we mention what happens in case the querying client is not the 
sponsoring client, or is too much policy?
 
Yes, I believe that returning the organization object and what organization 
object attributes to return is up to server policy.  Maybe it makes sense to 
add a sentence related to it being up to server policy.  


That would be great
[Linlin] Add some text like "It is up to the server policy to decide what 
attributes will be returned of an organization object.".
 
[…]
   When an  command has been processed successfully, the EPP
element MUST contain a child  element that
   identifies the organization namespace.  The  element
   contains the following child elements:
[…]
   o  Zero or more  elements that contains the operational
  status of the organization, as defined in Section 3.4.
 
⇒ this conflicts with the XML schema and 3.4, which states:
   An organization object MUST always have at least one associated
   status value.  The default value is "ok".
 
I agree that it should it should be “One or more  elements...” to 
match the XML schema.

Ok
[Linlin] This was changed.
 
 4.2.5. EPP  Command
[...]
Zero or more  elements that contains the role type, role
  statuses and optional role id of the organization
 
In my opinion the draft is still vague about which role sub-element of role is 
used for matching the role to be removed (I guess it is the role type, as it is 
the only required element). I would mention that:
 
E.g. in secDNS it is mentioned very explicit;
 
  The  element is part of the Key Data Interface and
  is used to uniquely define the key data to be removed, by using
  all four elements -- , , , and  -- that are guaranteed to be unique.
  There can be more than one DS record created for each key, so
  removing a key could remove more than one DS record.
 
The role type is what is unique for the organization’s role.  There cannot be 
duplicate role types for an organization.  It would be clearer to specify “A 
 element contains the role type of the organization, as defined in 
Section 3.2.  The role type uniquely identifies the role to update.”.  

It would have helped me if that would have been included. It'd be nice if this 
text is added.
[Linlin] “A  element contains the role type of the organization, as 
defined in Section 3.2.  The role type uniquely identifies the role to 
update.”will be added to this section.

 
Good instructions for how t

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

[Linlin Zhou]

Hi Pieter,
Thanks for your comments. I'll update it accordingly.



zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-06-15 20:31
To: regext@ietf.org
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-ext-07.txt
Hi Linlin,
 
Thanks for updating the draft. Small issue: in 4.3 you did not specify the 
status of an org object after returning the action pending responses. I would 
add something similar like RFC 5731:
 
   The status of the organization object after returning this response MUST
   include "pendingCreate".  The server operator reviews the request
   offline, and informs the client of the outcome of the review either
   by queuing a service message for retrieval via the  command or
   by using an out-of-band mechanism to inform the client of the
   request.
 
 
Kind regards
 
-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be <http://www.dnsbelgium.be>
 
 
On 15/06/18 02:48, "regext on behalf of internet-dra...@ietf.org" 
 wrote:
 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Registration Protocols Extensions WG of 
the IETF.

Title   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
    Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Xiaodong Lee
  James Gould
Filename: draft-ietf-regext-org-ext-07.txt
Pages   : 24
Date: 2018-06-14

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


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

Re: [regext] AD Review: draft-ietf-regext-org

[Linlin Zhou]

Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-27 09:35
To: regext@ietf.org; draft-ietf-regext-org
Subject: [regext] AD Review: draft-ietf-regext-org
This is my AD review for draft-ietf-regext-org-08.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document.  Please treat them as you would any other last-call
comments.
 
I also have one comment that needs to be addressed prior to IETF last call.
 
Thanks to everyone who worked on this document.
 
---
 
This comment (and only this comment) is blocking, and needs to be addressed
prior to IETF last call.
 
§4.1.1:
 
>  In addition to the standard EPP command elements, the  command
>  MUST contain a  element that identifies the organization
>  namespace.
 
Is the intention here to be more restrictive than normal XML namespace
handling? For example: is it intended to outlaw cases in which the org
namespace is defined in an ancestor element? Given that the rest of XML
processing is in line with normal XML behavior, this exception would 
need some
justification in this document, or a citation to a document that 
provides such
justification.
 
This issue arises in other parts of the document for ,
, , , , ,
, and .
 
 [Linlin] Take the  command as an example. In RFC 5730 section 2.9.2.1, 
it is said that,
In addition to the standard EPP command elements, the  command contains 
the following child elements:

   -  An object-specific  element that identifies the objects
  to be queried.  Multiple objects of the same type MAY be queried
  within a single  command.
The  is specified by a certain object using EPP extension framwork 
which is not in the standard EPP command elements.

And in RFC 5730 section 2.7.2, protocol elements that contain data specific to 
objects are identified using XML namespace notation with a reference to an XML 
schema that defines the namespace. For example, 
 C:
 C:  
 C:
 C:  
 C:

So the newly added organization object has the namespace . 

In RFC 5731, 5732 and 5733, some words such as " In addition to the standard 
EPP command elements, the  command MUST contain a  element 
that identifies the domain namespace.", are explicitly written to say that you 
should have , etc. under a certain command or response. To 
inline with the previous EPP object RFCs, so we use the same text to express 
that we have an organization-specific command element.
===
 
General:
 
Examples of elements that contain user-facing strings ( and 
,
for example) should probably contain "lang" attributes, even when using the
default of English, so as to encourage readers of the examples to implement
localization features.

[Linlin] Yes. We will change them to , .
---
 
§2:
 
Please update the boilerplate to match RFC 8174.

[Linlin] Yes. This section will be updated to match RFC 8174.
 
---
 
§3.2.3:
 
>  A role MAY have a third party assigned identifier such as the IANA ID
>  for registrars.  Its corresponding element is .
 
Shouldn't this element be called "roleID", to match the convention for 
other EPP
identifiers? (e.g., clID, crID, upID)
 [Linlin] OK. We will make it as "roleID".
---
 
§3.4:
 
>  An organization object MUST always have at least one associated
>  status value.  The default value is "ok".
 
What is meant by "default" here? Is this the value to be assumed if the 
element
is omitted? If that’s the case, please say so specifically. If this is 
simply
saying that the most common value is "ok," then rephrase to say that.

[Linlin] It was designed to have the default "ok" value if this element is 
omitted at first. After somen versions, one or more "status" element can be 
associated with the org object. I've read the text in this section again and 
suggested removing this sentence. 
---
 
§3.4:
 
>  o  linked: The organization object has at least one active
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers SHOULD provide services to
> determine existing object associations.
 
Given that this is a normative requirement, you need a normative reference
here to the specification by which such services are provided.
 
[Linlin] I think servers can make  command to change the status value 
of the org object depending on the server policies or business model. Each 
registry may have its own method to do this. Whether it is ok to change it to 
non-norm

Re: [regext] AD Review: draft-ietf-regext-org

[Linlin Zhou]

Hi Adam,
It seems that this paragraph was generated by the xml2rfc tool. I reread this 
section and I think it is better to remove this paragragh. 

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 06:12
To: regext@ietf.org; draft-ietf-regext-org
Subject: Re: AD Review: draft-ietf-regext-org
On 7/26/18 8:35 PM, Adam Roach wrote:
> This is my AD review for draft-ietf-regext-org-08.
 
After sending my original review, I noticed one additional detail that 
should be addressed:
 
"Copyright Notice" section:
 
>  This document may contain material from IETF Documents or IETF
>  Contributions published or made publicly available before November
>  10, 2008.  The person(s) controlling the copyright in some of this
>  material may not have granted the IETF Trust the right to allow
>  modifications of such material outside the IETF Standards Process.
 
This is typically only true of revisions of older documents, which 
necessarily
obsolete published RFCs. So, to double-check: is this the correct 
boilerplate
for this document?
 
/a
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:
 
>  In addition to the EPP command elements
>  described in the EPP object extensions, the command MUST contain an
>   element, and the  element MUST contain a child
>   element that identifies the extension namespace if
>  the client wants to associate data defined in this extension to the
>  object.
 
I presume the same answer will apply to this document as does to
draft-ietf-regext-org-08.
 
Affected elements appear to also include  and 
.
 
[Linlin] Please see my feedback in the reply of org draft. Thanks.
---
 
This is a blocking comment, as it impacts interoperability.
 
§4.2.5:
 
This section defines remove and change elements that use "role" as a key. It
is unclear whether an attempt to remove or change an identifier 
corresponding to
a role that is not present in the object results in an error, or is 
treated as
success.
 
For example, if an "example.com" is currently in the system as a 
reseller, but
is *not* in the system as a privacyproxy, would an update containing the
following elements return a success response or an error response?
 
   C:  
   C:
   C:  
   C:
   C:  
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

[Linlin]I think an error should be returned.
 
The same question needs to be answered for . Additionally: if no
error is returned, then behavior for  needs to clearly spell out
whether attempts to update a role that is not already present in the object
causes that role to be added, or if the object remains unchanged.

[Linlin] Originally, there is a response example for . But the WG 
thought that the example is exactly the same with RFC 5731, so it was removed. 
The exmaple is,

When an  command has been processed successfully, a server MUST respond 
with an EPP response with no  element.

   Example  response:

   S:
   S:
   S:  
   S:
   S:  Command completed successfully
   S:
   S:
   S:  ABC-12345
   S:  54321-XYZ
   S:
   S:  
   S:
 
Similarly, if  is issued for a role that already exists in the
object, does this result in an error, or is the existing role identifier
silently overridden?
 
If the answer to "is this an error" is "yes" for any or all of the
preceding questions: this document needs to clearly spell out what 
happens when
an  element contains multiple  elements, and 
*some* of
them cause an error while *some* of them do not. If this is the case, my 
strong
recommendation is to specify that operations are atomic (that is, they 
either
succeed completely or make no state change whatsoever).
 
Finally, if the  and  elements do not result in 
errors
in the cases described above, then this document should clearly specify how
processing is different between those two elements, or clearly specify that
handling of both elements is identical.
 
[Linlin] So is it ok to add some words like "An EPP error response MUST be 
returned if an  command cannot be processed for any reason." ?
---
 
"Copyright Notice" section:
 
>  This document may contain material from IETF Documents or IETF
>  Contributions published or made publicly available before November
>  10, 2008.  The person(s) controlling the copyright in some of this
>  material may not have granted the IETF Trust the right to allow
>  modifications of such material outside the IETF Standards Process.
 
This is typically only true of revisions of older documents, which 
necessarily
obsolete published RFCs. So, to double-check: is this the correct 
boilerplate
for this document?
 
[Linlin] This paragraph will be removed.
===
 
The remaining comments on this document are minor and editorial.
 
§1:
 
>  In the business model of domain registration, we usually have 3 roles
>  of entities, a registrant, a registrar and a r

Re: [regext] AD Review: draft-ietf-regext-org

[Linlin Zhou]

Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:27
To: Linlin Zhou; regext; draft-ietf-regext-org
Subject: Re: [regext] AD Review: draft-ietf-regext-org
On 7/28/18 3:00 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-27 09:35
To: regext@ietf.org; draft-ietf-regext-org
Subject: [regext] AD Review: draft-ietf-regext-org
This is my AD review for draft-ietf-regext-org-08.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document.  Please treat them as you would any other last-call
comments.
 
I also have one comment that needs to be addressed prior to IETF last call.
 
Thanks to everyone who worked on this document.
 
---
 
This comment (and only this comment) is blocking, and needs to be addressed
prior to IETF last call.
 
§4.1.1:
 
>  In addition to the standard EPP command elements, the  command
>  MUST contain a  element that identifies the organization
>  namespace.
 
Is the intention here to be more restrictive than normal XML namespace
handling? For example: is it intended to outlaw cases in which the org
namespace is defined in an ancestor element? Given that the rest of XML
processing is in line with normal XML behavior, this exception would 
need some
justification in this document, or a citation to a document that 
provides such
justification.
 
This issue arises in other parts of the document for ,
, , , , ,
, and .
 
 [Linlin] Take the  command as an example. In RFC 5730 section 2.9.2.1, 
it is said that,
In addition to the standard EPP command elements, the  command contains 
the following child elements:

   -  An object-specific  element that identifies the objects
  to be queried.  Multiple objects of the same type MAY be queried
  within a single  command.
The  is specified by a certain object using EPP extension framwork 
which is not in the standard EPP command elements.

And in RFC 5730 section 2..7.2, protocol elements that contain data specific to 
objects are identified using XML namespace notation with a reference to an XML 
schema that defines the namespace. For example, 
 C:
 C:  
 C:
 C:  
 C:

So the newly added organization object has the namespace . 

In RFC 5731, 5732 and 5733, some words such as " In addition to the standard 
EPP command elements, the  command MUST contain a  element 
that identifies the domain namespace.", are explicitly written to say that you 
should have , etc. under a certain command or response. To 
inline with the previous EPP object RFCs, so we use the same text to express 
that we have an organization-specific command element.


Sure. The issue I'm seeing here is that, in XML, the following snippets are 
semantically identical:

 C:
 C:  
 C:
 C:  
 C:

 C:
 C:  
 C:
 C:  
 C:

However, the current text appears to allow the first while outlawing the second.

[Linlin] How about "In addition to the standard EPP command elements, the 
 command MUST contain a  element. This element or its 
ancestor element MUST identify the organization namespace." 
The same changes will be applied to other parts of this document  for 
, , , , , 
, , and .
---
 
§5, Page 34:
 
>   
> 
>   
>   minOccurs="0"/>
> 
>   
 
The "reason" element needs to have a "maxOccurs" of greater than one
(presumably "unbounded") to allow for the conveyance of reasons in multiple
languages.

[Linlin] There is no limit for the "maxOccurs".. In RFC 5733, there is only a 
"minOccurs" value. Do we need to define this explicitly?


Yes. The default value for both minOccurs and maxOccurs is "1" -- if you want 
to allow more than one instance of an element, you need to indicate a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to allow 
more than one  element, then its definition is also in error.

[Linlin]  We checked our current running system. The suggested maxOccurs is 5. 
Of course this value can be discussed.
---
 


The remaining responses (which I have removed from this email) all look good to 
me. Thanks!

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

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:
 
>  In addition to the EPP command elements
>  described in the EPP object extensions, the command MUST contain an
>   element, and the  element MUST contain a child
>   element that identifies the extension namespace if
>  the client wants to associate data defined in this extension to the
>  object.
 
I presume the same answer will apply to this document as does to
draft-ietf-regext-org-08.
 
Affected elements appear to also include  and 
.
 
[Linlin] Please see my feedback in the reply of org draft. Thanks.


I assume we'll resolve this the same way in both documents.

[Linlin]  I've updated some words. Please see the feedback of org draft.
---
 
This is a blocking comment, as it impacts interoperability.
 
§4.2.5:
 
This section defines remove and change elements that use "role" as a key. It
is unclear whether an attempt to remove or change an identifier 
corresponding to
a role that is not present in the object results in an error, or is 
treated as
success.
 
For example, if an "example.com" is currently in the system as a 
reseller, but
is *not* in the system as a privacyproxy, would an update containing the
following elements return a success response or an error response?
 
   C:  
   C:
   C:  
   C:
   C:  
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

[Linlin]I think an error should be returned.


Okay -- we need to say which error code to use, then.


 
The same question needs to be answered for .


Is the answer the same for  as for ?


Similarly, if  is issued for a role that already exists in the 
object, does this result in an error, or is the existing role identifier
silently overridden?


This question also needs an answer.


 
If the answer to "is this an error" is "yes" for any or all of the
preceding questions: this document needs to clearly spell out what 
happens when
an  element contains multiple  elements, and 
*some* of
them cause an error while *some* of them do not.


This also still needs to be addressed. For example:

If "example.com" is currently in the system as a reseller, but is *not* in the 
system as a privacyproxy, what would the following command do?
 
   C:  
   C:
   C:  
   C:  
   C:
   C:  


This could do any of the following, and the document needs to be clear which 
one actually happens:

The command succeeds, and the "reseller" ID is removed from "example.com"
The command fails because "privacyproxy" doesn't exist as an ID on 
"example.com." No changes are made.
The command partially succeeds: the "reseller" ID is removed from 
"example.com," but the response is an error message because "privacyproxy" 
could not be returned.
The semantics around #3 are very complicated, since you'll ultimately need to 
indicate which part of the command succeeded and which part failed, so you 
probably want to pick #1 or #2. Given your answer above that removing a 
non-existent orgext-ID from an object is a failure, I think #2 is the most 
consistent. But this needs to be clearly specified.



Finally, if the  and  elements do not result in 
errors
in the cases described above, then this document should clearly specify how
processing is different between those two elements, or clearly specify that
handling of both elements is identical.
 
[Linlin] So is it ok to add some words like "An EPP error respon

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Sorry for some typos, the example should be like this,

  S:
   S:
   S:  
   S:
   S:  Object exists
   S:
   S:
   S:  
   S:res1523
   S:  
   S:
   S:
   S:  ABC-12345
   S:  54321-XYZ
   S:
   S:  
   S:



zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-08-08 13:06
To: Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:
 
>  In addition to the EPP command elements
>  described in the EPP object extensions, the command MUST contain an
>   element, and the  element MUST contain a child
>   element that identifies the extension namespace if
>  the client wants to associate data defined in this extension to the
>  object.
 
I presume the same answer will apply to this document as does to
draft-ietf-regext-org-08.
 
Affected elements appear to also include  and 
.
 
[Linlin] Please see my feedback in the reply of org draft. Thanks.


I assume we'll resolve this the same way in both documents.

[Linlin]  I've updated some words. Please see the feedback of org draft.
---
 
This is a blocking comment, as it impacts interoperability.
 
§4.2.5:
 
This section defines remove and change elements that use "role" as a key. It
is unclear whether an attempt to remove or change an identifier 
corresponding to
a role that is not present in the object results in an error, or is 
treated as
success.
 
For example, if an "example.com" is currently in the system as a 
reseller, but
is *not* in the system as a privacyproxy, would an update containing the
following elements return a success response or an error response?
 
   C:  
   C:
   C:  
   C:
   C:  
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

[Linlin]I think an error should be returned.


Okay -- we need to say which error code to use, then.


 
The same question needs to be answered for .


Is the answer the same for  as for ?


Similarly, if  is issued for a role that already exists in the 
object, does this result in an error, or is the existing role identifier
silently overridden?


This question also needs an answer.


 
If the answer to "is this an error" is "yes" for any or all of the
preceding questions: this document needs to clearly spell out what 
happens when
an  element contains multiple  elements, and 
*some* of
them cause an error while *some* of them do not.


This also still needs to be addressed. For example:

If "example.com" is currently in the system as a reseller, but is *not* in the 
system as a privacyproxy, what would the following command do?
 
   C:  
   C:
   C:  
   C:  
   C:
   C:  


This could do any of the following, and the document needs to be clear which 
one actually happens:

The command succeeds, and the "reseller" ID is removed from "example.com"
The command fails because "privacyproxy" doesn't exist as an ID on 
"example.com." No changes are made.
The command partially succeeds: the "reseller" ID is removed from 
"example.com," but the response is an error message because "privacyproxy" 
could not be returned.
The semantics around #3 are very complicated, since you'll ultimately need to 
indicate which part of the command succeeded and which part failed, so you 
probably want to pick #1 or #2. Given your answer above that removing a 
non-existe

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Dear Adam and WG,
We've received some comments on the appropriate error codes. Since 
draft-ietf-regext-org-ext is a command / response extension of another object 
that is related to a link attribute, 2305 seems like a more proper error code 
for all of them, which means "Object association prohibits operation".  The 
association could refer to an existing association (e.g., attempt to add a link 
that already exists) or a requested association (e.g., attempt to remove a link 
that does not exist). The co-authors have discussed this issue and suggested 
the following changes.

An EPP error response MUST be returned if an  command cannot be 
processed for any reason. 



zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-08-08 13:06
To: Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:
 
>  In addition to the EPP command elements
>  described in the EPP object extensions, the command MUST contain an
>   element, and the  element MUST contain a child
>   element that identifies the extension namespace if
>  the client wants to associate data defined in this extension to the
>  object.
 
I presume the same answer will apply to this document as does to
draft-ietf-regext-org-08.
 
Affected elements appear to also include  and 
.
 
[Linlin] Please see my feedback in the reply of org draft. Thanks.


I assume we'll resolve this the same way in both documents.

[Linlin]  I've updated some words. Please see the feedback of org draft.
---
 
This is a blocking comment, as it impacts interoperability.
 
§4.2.5:
 
This section defines remove and change elements that use "role" as a key. It
is unclear whether an attempt to remove or change an identifier 
corresponding to
a role that is not present in the object results in an error, or is 
treated as
success.
 
For example, if an "example.com" is currently in the system as a 
reseller, but
is *not* in the system as a privacyproxy, would an update containing the
following elements return a success response or an error response?
 
   C:  
   C:
   C:  
   C:
   C:  
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

[Linlin]I think an error should be returned.


Okay -- we need to say which error code to use, then.


 
The same question needs to be answered for .


Is the answer the same for  as for ?


Similarly, if  is issued for a role that already exists in the 
object, does this result in an error, or is the existing role identifier
silently overridden?


This question also needs an answer.


 
If the answer to "is this an error" is "yes" for any or all of the
preceding questions: this document needs to clearly spell out what 
happens when
an  element contains multiple  elements, and 
*some* of
them cause an error while *some* of them do not.


This also still needs to be addressed. For example:

If "example.com" is currently in the system as a reseller, but is *not* in the 
system as a privacyproxy, what would the following command do?
 
   C:  
   C:
   C:  
   C:  
   C:
   C:  


This could do any of the following, and the document needs to be clear which 
one actually happens:

The command succeeds, and the "reseller" ID is removed from "example.com"
The command fails because "privacyproxy" doesn't exist as an ID on 
"example.com." No changes are made.
The com

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Dear Adam and WG,
Sorry, please ignore last unfinished letter.

We've received some comments on the appropriate error codes. Since 
draft-ietf-regext-org-ext is a command / response extension of another object 
that is related to a link attribute, 2305 seems like a more proper error code 
for all of them, which means "Object association prohibits operation". The 
association dould refer to an existing association (e.g., attempt to add alink 
that already exists) or a requested association (e.g. attempt to remove a link 
that does not exist).
We found that in RFC5730 , the document already defined the response format 
with error value elements using  or  for an object. So we 
suggest not defining the specific response format in this command/response 
extension.
The co-authors have discussed this issue and suggested the following changes.

An EPP error response MUST be returned if an  command cannot be 
processed for any reason. 
An attempt to add one organization ID or multiple organization IDs with a 
particular role value when at least one of them already exists does not change 
the object at all. A server SHOULD notify clients that object relationsips exit 
by sending a 2305 error response code.
An attempt to remove an organization ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not exist by sending a 2305 error response code.
An attempt to change an organiztion ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not eixt by sending a 2305 error response code.
Response format with error value elements is defined in section 2.6 of RFC5730.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-08-08 13:06
To: Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within the
document; see, e.g., the following text:
 
>  In addition to the EPP command elements
>  described in the EPP object extensions, the command MUST contain an
>   element, and the  element MUST contain a child
>   element that identifies the extension namespace if
>  the client wants to associate data defined in this extension to the
>  object.
 
I presume the same answer will apply to this document as does to
draft-ietf-regext-org-08.
 
Affected elements appear to also include  and 
.
 
[Linlin] Please see my feedback in the reply of org draft. Thanks.


I assume we'll resolve this the same way in both documents.

[Linlin]  I've updated some words. Please see the feedback of org draft.
---
 
This is a blocking comment, as it impacts interoperability.
 
§4.2.5:
 
This section defines remove and change elements that use "role" as a key. It
is unclear whether an attempt to remove or change an identifier 
corresponding to
a role that is not present in the object results in an error, or is 
treated as
success.
 
For example, if an "example.com" is currently in the system as a 
reseller, but
is *not* in the system as a privacyproxy, would an update containing the
following elements return a success response or an error response?
 
   C:  
   C:
   C:  
   C:
   C:  
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

[Linlin]I think an error should be returned.


Okay -- we need to say which error

Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Linlin Zhou]

Dear Pieter,
Maybe we defined a "role" element for the organizations. I think some of the 
error cases are referenced with "role" but not with the organization IDs in 
 command. So this is something that is different from RFC5731. From my 
understanding of AD's comments, this role may lead to some errors that do not 
happen before. You should have some considerations about these cases.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Pieter Vandepitte
Date: 2018-08-09 15:45
To: Linlin Zhou; Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Hi Linlin,
 
Other RFC’s do not specify the error codes in particular cases (e.g. 5731 does 
not specify what to return if you remove a linked contact does not exist). But… 
on the other hand, I think it can be very useful if all Registries use the same 
error codes for the same use cases. 
It’s just that if you start to specify them, you have to be as complete as 
possible. You can’t randomly pick some cases. There are quite a lot of other 
cases, so where do we stop? E.g. deleting an organization object which is 
already linked, add a link for which the organization does not exist, … to just 
name a few of them. 
 
Isn’t this useful content for some kind of Best Practices document?
 
Kind regards
 
Pieter
 
-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be
 
 
 
 
From: regext  on behalf of Linlin Zhou 

Date: Thursday 9 August 2018 at 05:12
To: Adam Roach , draft-ietf-regext-org-ext 
, regext 
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
 
Dear Adam and WG,
Sorry, please ignore last unfinished letter.
 
We've received some comments on the appropriate error codes. Since 
draft-ietf-regext-org-ext is a command / response extension of another object 
that is related to a link attribute, 2305 seems like a more proper error code 
for all of them, which means "Object association prohibits operation". The 
association dould refer to an existing association (e.g., attempt to add alink 
that already exists) or a requested association (e.g. attempt to remove a link 
that does not exist).
We found that in RFC5730 , the document already defined the response format 
with error value elements using  or  for an object. So we 
suggest not defining the specific response format in this command/response 
extension.
The co-authors have discussed this issue and suggested the following changes.
 
An EPP error response MUST be returned if an  command cannot be 
processed for any reason. 
An attempt to add one organization ID or multiple organization IDs with a 
particular role value when at least one of them already exists does not change 
the object at all. A server SHOULD notify clients that object relationsips exit 
by sending a 2305 error response code.
An attempt to remove an organization ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not exist by sending a 2305 error response code.
An attempt to change an organiztion ID or multiple organization IDs with a 
particular role value when at least one of them does not exist does not change 
the object at all. A server SHOULD notify clients that object relationships 
does not eixt by sending a 2305 error response code.
Response format with error value elements is defined in section 2.6 of RFC5730.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Linlin Zhou
Date: 2018-08-08 13:06
To: Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update 
the draft based on your comments.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; regext@ietf.org
Subject: [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07.  I have a handful of
comments below that I'd like to see addressed prior to asking the IESG to
consider the document. Please treat them as you would any other last-call
comments.
 
There are also two blocking comments that need to be resolved prior to 
IETF last
call.
 
Thanks to everyone who worked on this document.
 
---
 
This is a blocking comment.
 
This document raises the same question as draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace declarations within th

Re: [regext] "epp"-scoped XML namespace in the REGEXT EPP Drafts

[Linlin Zhou]

Hi James,
I am going to include this update in the next version.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-17 02:23
To: regext@ietf.org
Subject: [regext] "epp"-scoped XML namespace in the REGEXT EPP Drafts
Hi,
 
During the IANA expert review of draft-ietf-regext-allocation-token a request 
was made to scope the XML namespaces to include “epp”.   The request was to 
change urn:ietf:params:xml:ns:allocationToken-1.0 to 
urn:ietf:params:xml:ns:epp:allocationToken-1.0.  It was agreed to progress 
draft-ietf-regext-allocation-token with the existing XML namespace, but with 
the expectation that future REGEXT EPP drafts will scope the XML namespace with 
“epp”.  This means considering the following REGEXT working group EPP XML 
namespace and schema changes.  I believe that all new EPP drafts must follow 
the new “epp”-scoped XML namespace pattern, and the existing REGEXT EPP drafts 
should follow the “epp”-scoped XML namespace pattern unless there is an 
undesired impact.  The new pattern is urn:ietf:params:xml:ns:epp:extension-1.0 
for the XML namespace and urn:ietf:params:xml:schema:epp:extension-1.0 for the 
XML schema.   1. draft-ietf-regext-epp-feesa.   
urn:ietf:params:xml:ns:fee-1.0 to urn:ietf:params:xml:ns:epp:fee-1.0b.  
urn:ietf:params:xml:schema:fee-1.0 to urn:ietf:params:xml:schema:epp:fee-1.0c.  
 I don’t believe changing the XML namespace will have a big impact for 
draft-ietf-regext-epp-fees, so my recommendation is to change it in 
draft-ietf-regext-epp-fees-12.2. draft-ietf-regext-change-polla.   
urn:ietf:params:xml:ns:changePoll-1.0 to urn:ietf:params:xml:ns:epp:changePoll 
-1.0b.  urn:ietf:params:xml:schema:changePoll-1.0 to 
urn:ietf:params:xml:schema:epp:changePoll -1.0  
i.   Currently the schema registration 
is incorrectly set to urn:ietf:params:xml:ns:changePoll-1.0.  I will take care 
of this.  c.   I believe this will have a negative impact to existing 
implementations, since urn:ietf:params:xml:ns:changePoll-1.0 is a mature XML 
namespace and its associated with poll messages.  Changing the poll message XML 
namespace will get into the unhandled XML namespace issue.  My recommendation 
is to keep the existing namespace based on the maturity of the namespace, 
unless there is a known conflict.3. draft-ietf-regext-orga.   
urn:ietf:params:xml:ns:org-1.0 to urn:ietf:params:xml:ns:epp:org-1.0b.  
urn:ietf:params:xml:schema:org-1.0 to urn:ietf:params:xml:schema:epp:org-1.0
  i.   
Currently the schema registration is incorrectly set to 
urn:ietf:params:xml:ns:org-1.0c.   I don’t believe change the XML namespace 
will have a big impact for draft-ietf-regext-org, so my recommendation is to 
change it in draft-ietf-regext-org-09.4. draft-ietf-regext-org-exta.   
urn:ietf:params:xml:ns:orgext-1.0 to urn:ietf:params:xml:ns:epp:orgext-1.0b.
  urn:ietf:params:xml:schema:orgext-1.0 to 
urn:ietf:params:xml:schema:epp:orgext-1.0   
   i.   Currently the schema registration is 
missing, so it needs to be added.c.   I don’t believe change the XML 
namespace will have a big impact for draft-ietf-regext-org-ext, so my 
recommendation is to change it in draft-ietf-regext-org-ext-08.5. 
draft-ietf-regext-bundling-registrationa.   urn:ietf:params:xml:ns:b-dn-1.0 
to urn:ietf:params:xml:ns:epp:b-dn-1.0b.  
urn:ietf:params:xml:schema:b-dn-1.0 to 
urn:ietf:params:xml:schema:epp:b-dn-1.0c.   I don’t know the impacts of 
changing the XML namespace for draft-ietf-regext-bundling-registration.6. 
draft-ietf-regext-verificationcodea.   
urn:ietf:params:xml:ns:verificationCode-1.0 to 
urn:ietf:params:xml:ns:epp:verificationCode-1.0 
 i.   The draft is missing the “urn:” 
URI prefix in the registration request.  I will take care of this.b.  
urn:ietf:params:xml:schema:verificationCode-1.0 to 
urn:ietf:params:xml:schema:epp:verificationCode-1.0 
 i.   The draft is missing the 
“urn:” URI prefix and needs to replace “:ns:” with “:schema:”.  I will take 
care of this.c.   Based on Production systems in place leveraging this XML 
namespace, my recommendation is to keep the existing namespace unless there is 
a known conflict.7. draft-ietf-regext-validatea.   
urn:ietf:params:xml:ns:validate-1.0 to urn:ietf:params:xml:ns:epp:validate-1.0  
i.   
The draft is missing the “urn:” URI prefix in the registration request.b.  
urn:ietf:params:xml:schema:validate-1.0 to 
urn:ietf:params:xml:schema:epp:validate-1.0 
   

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

[Linlin Zhou]

Hi,
The org drafts have been submitted to address the comments discussed before. 
Thanks for all your comments and explanations. 
1. comment for changing the name of  to "roID"
We reread RFC5730 and found that  has been already defined, so we did 
not change the name of  to "roID" to keep consistent with RFC5730. 
2. update "epp"-scoped XML namespace
James mentioned this on the mailing list, so we have included this update in 
this version.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-20 10:49
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
    Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-09.txt
Pages   : 45
Date: 2018-08-19
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-09
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-09
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-09
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

James,
Yes, you are right. I  only focused on section 7 and forgot to replace the 
namespace in other parts of the document. I'll correct them. Thank you.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-20 20:19
To: Linlin Zhou; Adam Roach; regext
Subject: Re: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin,
 
For “2. update "epp"-scoped XML namespace”, you need to change the namespace 
“urn:ietf:params:xml:ns:org-1.0” to “urn:ietf:params:xml:ns:epp:org-1.0” in all 
of the examples and the XML schema in section 5.  I recommend doing a global 
replace of  “urn:ietf:params:xml:ns:org-1.0” with 
“urn:ietf:params:xml:ns:epp:org-1.0” in the draft. Thanks,
  
—
 
JG



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

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

Verisign.com 
 
From: regext  on behalf of Linlin Zhou 

Date: Monday, August 20, 2018 at 12:12 AM
To: Adam Roach , regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
Hi,
The org drafts have been submitted to address the comments discussed before. 
Thanks for all your comments and explanations. 
1. comment for changing the name of  to "roID"
We reread RFC5730 and found that  has been already defined, so we did 
not change the name of  to "roID" to keep consistent with RFC5730. 
2. update "epp"-scoped XML namespace
James mentioned this on the mailing list, so we have included this update in 
this version.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-20 10:49
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-09.txt
Pages   : 45
Date: 2018-08-19
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-09
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-09
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-09
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Linlin Zhou]

Hi James,
This was one of the comments suggested by our AD. He asked us to give a 
maxOccurs value for "reason" element. I found the discussions on the mailing 
list, please see below,

---
 
§5, Page 34:
 
>   
> 
>   
>   minOccurs="0"/>
> 
>   
 
The "reason" element needs to have a "maxOccurs" of greater than one
(presumably "unbounded") to allow for the conveyance of reasons in multiple
languages.

[Linlin] There is no limit for the "maxOccurs".. In RFC 5733, there is only a 
"minOccurs" value. Do we need to define this explicitly?

Yes. The default value for both minOccurs and maxOccurs is "1" -- if you want 
to allow more than one instance of an element, you need to indicate a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to allow 
more than one  element, then its definition is also in error.


So I checked our system and give a suggested value for "5". We should keep it 
or remove it, need your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-20 20:31
To: Linlin Zhou; Adam Roach; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin,
 
In looking at the diff between draft-ietf-regext-org-08 and 
draft-ietf-regext-org-09, I noticed that maxOccurs=”5” was added to the XML 
schema checkType reason element.  Was this intentional, since this means that 
the check reason would be morphed from an optional element into an optional 
list of up to 5 reasons?  My recommendation is to remove the newly added 
maxOccurs=”5” from the checkType to ensure that the reason is consistent with 
the other EPP mappings by being an optional single element.  
  
—
 
JG



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

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

Verisign.com 
 
From: regext  on behalf of Linlin Zhou 

Date: Monday, August 20, 2018 at 12:12 AM
To: Adam Roach , regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
Hi,
The org drafts have been submitted to address the comments discussed before. 
Thanks for all your comments and explanations. 
1. comment for changing the name of  to "roID"
We reread RFC5730 and found that  has been already defined, so we did 
not change the name of  to "roID" to keep consistent with RFC5730. 
2. update "epp"-scoped XML namespace
James mentioned this on the mailing list, so we have included this update in 
this version.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-20 10:49
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-09.txt
Pages   : 45
Date: 2018-08-19
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-09
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-09
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-09
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-ietf-regext-org-ext-08.txt

[Linlin Zhou]

Hi James,
Originaly, the text was "at least one and only one" , this is a little 
confusing. I reconsider this section and agree with you that this is not to 
have just only one , , or  element. I'll 
change the text to "At least one".

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-20 20:43
To: internet-dra...@ietf.org; Linlin Zhou; Junkai Wei; Jiankang Yao; Ning Kong
Subject: Re: New Version Notification for draft-ietf-regext-org-ext-08.txt
Linlin,
 
In reviewing draft-ietf-regext-org-ext-08, for the update it now states 
"Exactly one , , or  element MUST be 
provided".  Is this what is really desired, where a client can only add a set 
of roles, remove a set of roles, or change a set of roles, but cannot add, 
remove, and change the roles in a single command?  If that were the case, then 
the XML schema "updateType" would need to be changed from a  to a 
 and the minOccurs="0" attribute would need to be removed from the 
"add", "rem", and "chg" elements.  My recommendation is to leave the XML schema 
as is, which will allow the client to submit an add, remove, and change in a 
single command, and to change the "Exactly one" to "At least one", since we 
don't want an update extension with no changes.  
 
Thanks,
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com <http://verisigninc.com/> 
 
On 8/19/18, 11:03 PM, "internet-dra...@ietf.org"  
wrote:
 

A new version of I-D, draft-ietf-regext-org-ext-08.txt
has been successfully submitted by Linlin Zhou and posted to the
IETF repository.

Name: draft-ietf-regext-org-ext
Revision: 08
Title: Organization Extension for the Extensible Provisioning Protocol (EPP)
Document date: 2018-08-20
Group: regext
Pages: 25
URL:
https://www.ietf.org/internet-drafts/draft-ietf-regext-org-ext-08.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
Htmlized:   https://tools.ietf.org/html/draft-ietf-regext-org-ext-08
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-ext
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-08

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


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

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

[Linlin Zhou]

Dear AD,
If we keep it consistent with other EPP RFCs and remove the maxOcuurs value, 
what's your opinion?

Regards
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-21 11:17
To: Linlin Zhou
CC: Adam Roach; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin, 

The max occurs should be one which is the default value.  We do not want to 
change the reason from an optional individual element into a optional list of 
up to 5 reasons.  This would be inconsistent with the other EPP RFCs.

Jim

Sent from my iPhone

On Aug 20, 2018, at 10:28 PM, Linlin Zhou  wrote:

Hi James,
This was one of the comments suggested by our AD. He asked us to give a 
maxOccurs value for "reason" element. I found the discussions on the mailing 
list, please see below,

---
 
§5, Page 34:
 
>   
> 
>   
>   minOccurs="0"/>
> 
>   
 
The "reason" element needs to have a "maxOccurs" of greater than one
(presumably "unbounded") to allow for the conveyance of reasons in multiple
languages.

[Linlin] There is no limit for the "maxOccurs".. In RFC 5733, there is only a 
"minOccurs" value. Do we need to define this explicitly?

Yes. The default value for both minOccurs and maxOccurs is "1" -- if you want 
to allow more than one instance of an element, you need to indicate a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to allow 
more than one  element, then its definition is also in error.


So I checked our system and give a suggested value for "5". We should keep it 
or remove it, need your comments.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-20 20:31
To: Linlin Zhou; Adam Roach; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin,
 
In looking at the diff between draft-ietf-regext-org-08 and 
draft-ietf-regext-org-09, I noticed that maxOccurs=”5” was added to the XML 
schema checkType reason element.  Was this intentional, since this means that 
the check reason would be morphed from an optional element into an optional 
list of up to 5 reasons?  My recommendation is to remove the newly added 
maxOccurs=”5” from the checkType to ensure that the reason is consistent with 
the other EPP mappings by being an optional single element.  
  
—
 
JG



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

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

http://Verisign.com 
 
From: regext  on behalf of Linlin Zhou 

Date: Monday, August 20, 2018 at 12:12 AM
To: Adam Roach , regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
Hi,
The org drafts have been submitted to address the comments discussed before. 
Thanks for all your comments and explanations. 
1. comment for changing the name of  to "roID"
We reread RFC5730 and found that  has been already defined, so we did 
not change the name of  to "roID" to keep consistent with RFC5730. 
2. update "epp"-scoped XML namespace
James mentioned this on the mailing list, so we have included this update in 
this version.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-20 10:49
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-09.txt
Pages   : 45
Date: 2018-08-19
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-09
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-09
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-09
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at http://tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://http://ftp.ietf.org/i

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

[Linlin Zhou]

Thanks for all the comments and explanations. I'll update the drafts as soon as 
possible.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-08-22 03:14
To: Gould, James; Linlin Zhou
CC: regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
James --

Thanks for the clarification, and I apologize for the extra noise caused by my 
confusion here.

/a

On 8/21/18 2:00 PM, Gould, James wrote:
Adam, 
 
The language used in EPP is negotiated in the EPP Greeting and EPP Login of RFC 
5730.  The server includes the list of supported languages in the EPP Greeting, 
and the client selects the language to use for the session in the EPP Login.  
All text responses returned by the server are provided using the single 
language that was negotiated.   The  element includes the 
human-readable reason in the negotiated language using the “lang” attribute, 
which has the default value of “en” (English).  
  
—
 
JG



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

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

Verisign.com 
 
From: Adam Roach 
Date: Tuesday, August 21, 2018 at 2:07 PM
To: Linlin Zhou , James Gould 
Cc: regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
If that's what the working group intends, then it's okay to move forward with 
the document. It's rather unlike the localization approached I'm used to 
seeing, in which multiple copies of a message are available, each in its own 
language, which is why I commented on it.
 
/a
 
On 8/20/18 10:46 PM, Linlin Zhou wrote:
Dear AD,
If we keep it consistent with other EPP RFCs and remove the maxOcuurs value, 
what's your opinion?
 
Regards
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-21 11:17
To: Linlin Zhou
CC: Adam Roach; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin, 
 
The max occurs should be one which is the default value.  We do not want to 
change the reason from an optional individual element into a optional list of 
up to 5 reasons.  This would be inconsistent with the other EPP RFCs.
 
Jim
Sent from my iPhone

On Aug 20, 2018, at 10:28 PM, Linlin Zhou  wrote:
Hi James,
This was one of the comments suggested by our AD. He asked us to give a 
maxOccurs value for "reason" element. I found the discussions on the mailing 
list, please see below,
 
---
 
§5, Page 34:
 
>   
> 
>   
>   minOccurs="0"/>
> 
>   
 
The "reason" element needs to have a "maxOccurs" of greater than one
(presumably "unbounded") to allow for the conveyance of reasons in multiple
languages.
 
[Linlin] There is no limit for the "maxOccurs".. In RFC 5733, there is only a 
"minOccurs" value. Do we need to define this explicitly?

Yes. The default value for both minOccurs and maxOccurs is "1" -- if you want 
to allow more than one instance of an element, you need to indicate a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to allow 
more than one  element, then its definition is also in error.
 
 
So I checked our system and give a suggested value for "5". We should keep it 
or remove it, need your comments.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-08-20 20:31
To: Linlin Zhou; Adam Roach; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
Linlin,
 
In looking at the diff between draft-ietf-regext-org-08 and 
draft-ietf-regext-org-09, I noticed that maxOccurs=”5” was added to the XML 
schema checkType reason element.  Was this intentional, since this means that 
the check reason would be morphed from an optional element into an optional 
list of up to 5 reasons?  My recommendation is to remove the newly added 
maxOccurs=”5” from the checkType to ensure that the reason is consistent with 
the other EPP mappings by being an optional single element.  
  
—
 
JG



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

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

http://Verisign.com 
 
From: regext  on behalf of Linlin Zhou 

Date: Monday, August 20, 2018 at 12:12 AM
To: Adam Roach , regext 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-org-09.txt
 
Hi,
The org drafts have been submitted to address the comments discussed before. 
Thanks for all your comments and explanations. 
1. comment for changing the name of  to "roID"
We reread RFC5730 and found that  has been already defined, so we did 
not change the name of  to "roID" to keep consistent with RFC5730. 
2. update "epp"-scoped XML namespace
James mentioned this on the mailing list, so we have included this update in 
this version.
 
Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-20 10:49
To: i-d-annou...@ietf.org
C

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

[Linlin Zhou]

Dear all,
The new version of org and org-ext have been submitted. Please review. Thank 
you.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: internet-drafts
Date: 2018-08-24 09:29
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-10.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-10.txt
Pages   : 45
Date: 2018-08-23
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-10
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-10
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-10
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Genart last call review of draft-ietf-regext-org-10

[Linlin Zhou]

Dear Stewart,
Thanks for your review. Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 
From: Stewart Bryant
Date: 2018-10-09 00:52
To: gen-...@ietf.org
CC: draft-ietf-regext-org.all; ietf; regext
Subject: [regext] Genart last call review of draft-ietf-regext-org-10
Reviewer: Stewart Bryant
Review result: Ready with Issues
 
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.
 
For more information, please see the FAQ at
 
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
 
Document: draft-ietf-regext-org-10
Reviewer: Stewart Bryant
Review Date: 2018-10-08
IETF LC End Date: 2018-10-08
IESG Telechat date: Not scheduled for a telechat
 
Summary:
 
This is a well written document, and ready for publication.
 
Major issues: None
 
Minor issues:
The RFC 2718 normative reference is a bit strange to one that does not normally
work in this area. RFC 2718 has been obsoleted, and this is covered by it being
called out in the IETF LC. However RFC 2718 is called out because the text
requires a reference to UTF-16, and there is apparently no reference to it
other than the obsolete RFC 2718 text. This makes me wonder why this document
requires support of the format.
[Linlin] Sorry. It should be RFC2781 and will be moved to "Informative 
References".
 
Perhaps a comment on this might be useful to other puzzled readers.
 
In Section  3.6 the text says: "Loops SHOULD be prohibited."
[Linlin] Will be modified as "MUST".
 
I am surprised this is not a MUST, since SHOULD means that clients need to make
the test whenever they used the repository and were worried about this, whereas
MUST would mean that the server makes the test once.
 
Nits/editorial comments:
 
Nits points out an issue with the RFC2119 boiler plate and also a line too
long, but these will be fixed by the RFC Editor as a matter of course.
[Linlin] I found there are two lines are two long. They will be put into two 
lines, like,

S: Command completed successfully; 
S:   action pending
 
 
___
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] Opsdir last call review of draft-ietf-regext-org-11

[Linlin Zhou]

Dear Jürgen,
Thanks for your review. I have my feedbacks below starting with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Jürgen Schönwälder
Date: 2018-10-19 16:26
To: ops-...@ietf.org
CC: draft-ietf-regext-org.all; ietf; regext
Subject: Opsdir last call review of draft-ietf-regext-org-11
Reviewer: Jürgen Schönwälder
Review result: Has Nits
 
Thanks for a concise and well written document. I have not run tools
to validate the XSD and the XML artefacts but the definitions all look
reasonable.
 
Comment:
 
- What does the following mean in the definition of e164StringType?
 

 
  It is indeed the intention to use "x"? What is the reason for having
  e164Type, why not use e164StringType?

[Linlin] Yes, becasuse some "voice" may have telephone extensions. So an 
optional "x" attribute is provided to note telephone extension information. The 
detailed format of this element is described in Section 2.5 of RFC5733. We have 
this reference in the document.
 
Nits:
 
- What are "Organization transform commands"? This phrase appears
  several times in 3.4 an it seems this refers to what section 4.2
  describes later on. Well, if you read the document sequentially,
  things are a bit confusing. Perhaps define upfront what transform
  commands are? It might also be that EPP people are used to
  "transform commands" and this just shows my lack of familiarity with
  EPP.
[Linlin] This document is an object mapping extension of RFC5730 described in 
section 1 of this document. Since RFC5730 has already defined "Object Transform 
Commands" in section 2.9.3. So we don't repeat the definitions here.
 
- s/ement/element/
[Linlin] Thank you for your careful review. "The  ement..." in 
section 4.1.1. It will be revised.
 
- s/Zero of more  element/Zero of more  elements/
[Linlin] In section 4.2.1. It will be revised.
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [OPS-DIR] Opsdir last call review of draft-ietf-regext-org-11

[Linlin Zhou]

Yes, "Zero or more  elements", thank you.



Linlin Zhou
 
From: MORTON, ALFRED C (AL)
Date: 2018-10-20 22:34
To: Jürgen Schönwälder; ops-...@ietf.org
CC: draft-ietf-regext-org@ietf.org; i...@ietf.org; regext@ietf.org
Subject: RE: [OPS-DIR] Opsdir last call review of draft-ietf-regext-org-11
 
 
> -Original Message-
> From: OPS-DIR [mailto:ops-dir-boun...@ietf.org] On Behalf Of Jürgen
> Schönwälder
> Sent: Friday, October 19, 2018 4:27 AM
> To: ops-...@ietf.org
> Cc: draft-ietf-regext-org@ietf.org; i...@ietf.org; regext@ietf.org
> Subject: [OPS-DIR] Opsdir last call review of draft-ietf-regext-org-11
> 
> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
> 
...
> 
> - s/Zero of more  element/Zero of more  elements/
> 
[acm] thinks you meant:
- s/Zero of more  element/Zero or more  elements/
 ^
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Genart telechat review of draft-ietf-regext-org-11

[Linlin Zhou]

Thanks for your review.

Regards,
Linlin


Linlin Zhou
 
From: Stewart Bryant
Date: 2018-10-23 19:36
To: gen-...@ietf.org
CC: draft-ietf-regext-org.all; ietf; regext
Subject: [regext] Genart telechat review of draft-ietf-regext-org-11
Reviewer: Stewart Bryant
Review result: Ready
 
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
 
For more information, please see the FAQ at
 
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
 
Document: draft-ietf-regext-org-11
Reviewer: Stewart Bryant
Review Date: 2018-10-23
IETF LC End Date: 2018-10-08
IESG Telechat date: 2018-10-25
 
Summary: This is a well written document, and ready for publication.
 
Major issues: None
 
Minor issues: None
 
Nits/editorial comments: There is an RFC 2119 warning, which I don't
understand, but which the RFC Editor would normally resolve.
 
 
___
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] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
Thanks for your review. Please find my feedbacks below with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-24 01:38
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-11: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
 
 
--
COMMENT:
--
 
Some of the element descriptions (e.g., ) appear to be
duplicated in several places and are also rather long in prose form.  Is
there value in attempting to consolidate the structural definition to a
single place in the document and just refer to that structure from the
places where it can appear?
[Linlin] This document borrowed the text structure from RFC5731, RFC5732 and 
RFC5733 of EPP. I think the intension of having some duplicated descriptions is 
for users' easy reading. When seeing the examples, they do not have to scroll 
up and down to find the elements definitions. Some descriptions are a little 
different, although  elements appear to be duplicated. Such as, 
"One or more  elements" in  response and  "Zero or more 
 elements" in  command. Of course putting all the elements 
definitions in a section is a concise way for the document structure.
 
 
Section 1
 
   There are many entities, such as registrars, resellers, DNS service
   operators, or privacy proxies involved in the domain registration
   business.  These kind of entities have not been formally defined as
   an object in EPP which will be specified as "organization" in this
   document.
 
nit: run-on sentence.  I suggest:
   These kind of entities have not been formally defined as having
   an object in EPP. This document provides a way to specify them as
   "organization" entities.
[Linlin] OK.
 
Section 2
 
   The XML namespace prefix "org" 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.
 
I suggest mentioning more explicitly that "org" is used in the examples as
shorthand for the full namespace "urn:ietf:params:xml:ns:epp:org-1.0";
draft-ietf-regext-allocation-token would be a fine example to look at.
[Linlin] Yes. "The XML namespace prefix "org" is used for the namespace 
"urn:ietf:params:xml:ns:epp:org-1.0".
 
Section 3.4
 
   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".  The "hold" and
   "terminated" status values are server-managed when the organization
   has no parent identifier [Section 3.6] and otherwise MAY be client-
   managed based on server policy.
 
The list/descriptions that follows shows several that don't start with
"client"/"server", including some not mentioned here.  Are we supposed to
assume that these "unprefixed" values are also server-managed?
[Linlin] Yes, other status values that do not begin with either "client" or 
"server" are server-managed. I'll add this setence to clarify.
 
   o  ok: This is the normal status value for an object that has no
  pending operations or prohibitions.  This value is set and removed
  by the server as other status values are added or removed.
 
I guess this is intended to be parsed as "(pending operations) or
(prohibitions)", but could also be parsed as "pending (operations or
prohibitions)".  Perhaps "operations pending or active prohibitions" is
less prone to misreading.
[Linlin] OK.
 
In general, the sort of "all combinations are permitted, except for these
restrictions" approach taken here can lead to some non-sensical
combinations, if insufficient care is taken by the document authors.  I did
not attempt to validate all possible combinations, but do note that (e.g.)
we make statements about "linked" in combination with "ok" and
"client/serverLinkProhibited", but not about "linked" in combination with
"terminated" or several other status values.  The first of those cases
serves as a limit

Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Ben,
Thanks for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-24 05:46
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Ben Campbell has entered the following ballot position for
draft-ietf-regext-org-11: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
 
 
--
COMMENT:
--
 
Hi, thanks for this work. I have some comments, both substantive and editorial:
 
*** Substantive Comments ***
 
§4.1.2: "- A 
element contains the following child elements:
+ One, two, or three OPTIONAL  elements that
contain the organization’s street address."
 
I take that to mean it must contain at least one. If so, I don't think OPTIONAL
is appropriate; if the elements are optional, they can be left out. simply
saying it contains "1, 2, or 3" would be more appropriate.
[Linlin] Yes, good point. I'll remove "optional".
 
§9: The org element can contain contact information, possibly including
personally identifiable information of individuals. Doesn’t this have privacy
implications that should be discussed here or in a privacy considerations
section?
[Linlin] This document is an object extension of EPP that follows all the 
security requirements for EPP. We do not hope to add any more secure 
considerations in this document. So this element can be "zero" if you do not 
like to provide.
 
*** Editorial Comments ***
 
- General:
 
I'm a little confused by the split in material between draft-ietf-regext-org
and draft-ietf-regext-org-ext, especially how the command mapping and related
info seems to span both documents. It seems a bit reader-unfriendly. But it's
late enough in the process that it's probably not worth changing.
[Linlin] I can have some explanations for the two documents. 
draft-ietf-regext-org is a new EPP organization object with some role values. 
draft-ietf-regext-org-ext has defined an extension in exsiting EPP objects such 
as domain in RFC5731, host in RFC5732 and contact in RFC5733. These objects can 
link with an orgnization ID created in draft-ietf-regext-org.
 
§1, paragraph 1: Please expand EPP on first use in the body. (You do expand it
on the 2nd use in the next paragraph :-) )
[Linlin] Yes, thank you.
 
§2, 3rd paragraph:  I know we are not consistent about this, but I find the
word “conforming” to be a red flag. Standards track RFCs should be about
interoperability, not conformance. I suggest striking all after “presented”.
[Linlin] OK.
 
§3.2.1: Plural disagreement between “roles and “type” in the second sentence.
[Linlin] Yes. "An organization could have multiple roles with different role 
types. 
 
§3.3: Plural disagreements between "contacts" and "identifier"
[Linlin] Yes. "All EPP contacts are identified by server-unique identifiers."
 
§3.4, 5th paragraph from end: "Organization MUST have only one of these
statuses set"
Please avoid constructions of the form "MUST...only". They can be ambiguous.
Please consider something to the effect of "MUST NOT have more than one" or
"MUST have exactly one". (Same for the "MAY...only" in the next paragraph.)
[Linlin] OK. Thank you for your suggestions.
 
§4 and subsections: - The text is inconsistent in the use of OPTIONAL for
optional elements. Many are labeled as optional, but some with descriptions
along the lines of "zero or more" are not labeled OPTIONAL when they clearly
are. I don't have a strong opinion which way to go, but please be consistent.
[Linlin] I'll double check the text.
 
§4.1.1:
- "When a  command has been processed successfully, the EPP
 element MUST contain a child  element"
That MUST seems more like a statement of fact. (This pattern occurs several
times.) - "an OPTIONAL "lang" attribute MAY be present" OPTIONAL and MAY are
redundant.
[Linlin] These "MUST" sentences are trying to be compliant with the EPP RFCs 
and other EPP extensions.
"an OPTIONAL "lang" attribute may be present".
 
- Command mappings in general: The text is inconsistent in the use of OPTIONAL
for optional elements. Many are labeled as optional, but some with descriptions
along the lines of "z

Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Ben,
Maybe I did not make this item clarified. I'd like to have some more 
explanations. You are right that the EPP organization object may have a 
 element, but this is not a required information. There may be some 
possibilities as follows,
1. If the organizations do not want to provide this information to protect the 
privacy, the  could be empty.
2. If the organizations have no issues on the privacy, they can input the 
contact identifier created according to RFC5733.
a. In RFC5733, required info including contact id, contact name, city, 
country code, email and authentication info.
b. Optional info including contact organization, street, state or province, 
postal code, voice, fax and disclose elements choices.
"Authorization information is REQUIRED to create a contact object. ..Both 
client and server MUST ensure that authorization information is stored and 
exchanged with high-grade encryption 
mechanisms to provide privacy services." was specified in RFC5733.

The organization object may have personally identifiable information, such as 
. This information is not a required element in this document 
which can be provided on a voluntary basis. If it is provided, both client and 
server MUST ensure that authorization information is stored and exchanged with 
high-grade encryption mechanisms to provide privacy services, whichi is 
specified in RFC5733.

Regards,
Linlin


Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-25 01:32
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Thanks for your response. It all looks good, except for one item below:

Thanks!

Ben.

On Oct 24, 2018, at 5:05 AM, Linlin Zhou  wrote:


[...]

 
§9: The org element can contain contact information, possibly including
personally identifiable information of individuals. Doesn’t this have privacy
implications that should be discussed here or in a privacy considerations
section?
[Linlin] This document is an object extension of EPP that follows all the 
security requirements for EPP. We do not hope to add any more secure 
considerations in this document. So this element can be "zero" if you do not 
like to provide.
 

I don’t understand how your answer addresses my question. As far as I can tell, 
this document creates a new object that can contain personally identifiable 
information (PII). Is that incorrect?

Is there text in EPP that already talks about PII that can be cited?


[...]

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
Thanks for your review. Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-24 03:13
To: The IESG
CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-ext-09: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
 
 
--
DISCUSS:
--
 
I have two points that I would like to discuss.  It is more likely than not
that at least one of them merely reflects my confusion and is a non-issue,
but I would like to get these at least clarified.
 
First, the examples throughout the document use organization identifiers
like "myreseller" or "myproxy".  This seems to me to be highly confusing,
since these IDs are supposed to be server-unique values per organization,
and are highly unlikely to be "my" reseller/proxy/etc. for all the entries
in the registry.  If I understand things correctly, the example IDs should
instead be company-name-like values or "random" numbers or similar (or
combination thereof).
[Linlin]  Thank you for pointing out this. To be more consistent with the 
draft-ietf-regext-org draft, I suggest using the IDs defined in the "org" 
draft, like "reseller1523" , "registrar1362" or "proxy2935".

Second, I am unsure of the semantics relating to role types, especially as
they interact with the  command.  Various aspects of the examples
seem to imply that it is only permitted to have at most one organization
mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
particular, the  element seems to be using the  role
attribute to determine which  is being changed (with the new
value being provided in the element body), and the  element is
providing  with only the role attribute and no body to identify
a specific organization to remove.  If this reading of the document is
correct, then I would expect the limitation to be called out more clearly,
especially as it would seem to prevent a domain owner from (e.g.) using
multiple DNS service operators.
[Linlin] In the normal business model, for example a domain should have one 
reseller, one registrar etc.  How about adding some text like "One  
element is suggested for each role type." in the element description.
 
 
--
COMMENT:
--
 
Section 1
 
   In the business model of domain registration, we usually have 3 roles
   of entities: a registrant, a registrar and a registry.  There may be
   other roles of entities involved in the domain registration process
   which are not formally defined, such as resellers, DNS service
   operators, privacy proxies, etc.
 
nit: Perhaps I am misreading, but are we not going to formally define these
entities in the next paragraph (in which case "yet" might be worth adding)?
[Linlin] Yes. "...which are not formally defined yet..."
 
   An organization mapping object defined in [ID.draft-ietf-regext-org]
   SHOULD be created first.  The organization information specified in
   this document MUST reference the existing organization identifier.
 
What does "first" refer to?  "prior to the use of that object"?
[Linlin] Yes. The organizations object should be created prior to using the 
organization ID for the extension. Maybe I can change the words to be more 
clear, "Organization object identifiers MUST be known to the server before the 
organization object can be associated with the EPP object."
 
Section 2
 
   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.
 
[This could probably be written more clearly; see my comment on the
companion document]
 [Linlin] I'll update it to use the full namespace.

Section 9
 
IIRC the authorization model for EPP does not allow arbitrary clients to
retrieve information about arbitrary (unrelated) domains.  If that's not
the case, there would be privacy considerations with respect to exposing
the linkages of the organization mappings (and 

Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-ext-09: (with COMMENT)

[Linlin Zhou]

Dear Ben,
Thank you for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-24 06:00
To: The IESG
CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
Subject: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-ext-09: 
(with COMMENT)
Ben Campbell has entered the following ballot position for
draft-ietf-regext-org-ext-09: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
 
 
--
COMMENT:
--
 
Thanks for the work on this. I have a few comments:
 
*** Substantive Comments ***
 
§1: "An organization mapping object defined in [ID.draft-ietf-regext-org]
SHOULD be created first."
 
First before what?
[Linlin] I noticed that Benjamin had the same comment. So I suggest changing 
some words here, "Organization object identifiers MUST be known to the server 
before the organization object can be associated with the EPP object.".
 
*** Editorial Comments ***
 
- General:
I'm a little confused by the split in material between draft-ietf-regext-org
and draft-ietf-regext-org-ext, especially how the command mapping and related
info seems to span both documents. It seems a bit reader-unfriendly. But it's
late enough in the process that it's probably not worth changing.
[Linlin] Please see my feedback in the "org" draft.
 
- Abstract: Please expand EPP on first mention both in the abstract and in the
body.
[Linlin] Yes.
 
§2, 3rd paragraph:  I know we are not consistent about this, but I find the
word “conforming” to be a red flag. Standards track RFCs should be about
interoperability, not conformance. I suggest striking all after “presented”.
[Linlin] OK.
 
 
___
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] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Alexey,
Thanks for your review. I have listed the reference in the following text. The 
references will be applied to other part in the document. Please see my 
feedbacks inline with [Linlin].
 
Regards,
Linlin


Linlin Zhou
 
From: Alexey Melnikov
Date: 2018-10-24 20:42
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Alexey Melnikov's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Alexey Melnikov has entered the following ballot position for
draft-ietf-regext-org-11: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
 
 
--
COMMENT:
--
 
This is a well written document, but I am concerned about missing references
for various syntactic elements that you use. Having proper references will save
developers time and will improve interoperability. The same issue in at least 3
places in the document, I am mentioning the first one below.
 
In 4.1.1:
 
   o  An OPTIONAL  element that may be provided when an
  object cannot be provisioned.  If present, this element contains
  server-specific text to help explain why the object cannot be
  provisioned.  This text MUST be represented in the response
  language previously negotiated with the client; an OPTIONAL "lang"
 
Please either point to the Language tag RFC 5646/BCP 47 or point to another RFC
which defines the "lang" attribute.
[Linlin] ...an OPTIONAL "lang" attribute as defined in [RFC 5646] MAY be 
present... 
 
  attribute MAY be present to identify the language if the
  negotiated value is something other than the default value of
  "en"(English).
 
4.1.2.  EPP  Command
 
   o  Zero to two  elements that contain postal-address
  information.  Two elements are provided so that address
  information can be provided in both internationalized and
  localized forms; a "type" attribute is used to identify the two
  forms.  If an internationalized form (type="int") is provided,
  element content MUST be represented in a subset of Unicode in the
  range U+0020 - U+007E.  If a localized form (type="loc") is
  provided, element content MAY be represented in unrestricted UTF-
  8.  The  element contains the following child
  elements:
 
[snip]
 
 +  An  element that contains the organization's country
code.
 
Please add the correct reference for country codes. I believe you want to
reference D country codes from ISO 3166. (There are also alpha-3 country
codes.)
 
Alternative you can just reference a section from RFC 5733.
[Linlin]  An  element that contains the alpha-2 organization's country 
code. The detailed format of this element is described in section 2.4.3 of RFC 
5733.
 
   o  An OPTIONAL  element that contains the organization's
  email address.
 
Please point to specific format for email addresses (there is RFC 5321 format
and RFC 5322 format. They are not identical.) Alternative you can just
reference a section from RFC 5733.
[Linlin] An OPTIONAL  element that contains the organization's 
email address. The detailed format of this element is described in section 2.6 
of RFC 5733.
 
   o  An OPTIONAL  element that contains the URL to the website
  of the organization. 
 
Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to
restrict this to https: or http:
[Linlin] An OPTIONAL  element that contains the URL to the website of 
the organization. The detailed format of this element is described in RFC 3986.
 
One possible way of addressing all of the above is to add a few sentences with
references to the "Conventions Used in This Document" section.
 
 
___
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] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Eric,
Thanks for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin


Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-25 02:05
To: The IESG
CC: regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with 
DISCUSS and COMMENT)
Eric Rescorla has entered the following ballot position for
draft-ietf-regext-org-11: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
 
 
--
DISCUSS:
--
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
 
 
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>  o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>   
>  o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are 
set, these two statuses can coexist in the system. "clientUpdateProhibited" is 
set by the client and "serverUpdateProhibited" is set by the server.
 
 
S 4.1.2.
>  C:res1523
>  C:  
>  C:
>  C:ABC-12345
>  C:  
>  C:
 
So I can only  one org?
[Linlin] Yes,  command supports one org id.
 
 
S 4.1.2.
>   
>  o  One or more  elements that contain the operational
> status of the organization, as defined in Section 3.4.
>   
>  o  An OPTIONAL  element that contains the identifier of
> the parent object, as defined in Section 3.6.
 
It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up 
to the server policy to decide 
what optional attributes will be returned of an organization object." or just 
remove it?
 
 
--
COMMENT:
--
 
S 3.2.1.
>  object.  A client can change the role of an organization object using
>  the EPP  command.
>   
>   3.2.1.  Role Type
>   
>  An organization role MUST have a type which supports a list of
 
Editorial: I found this confusing. I think you want to say "MUST have
a type field. This may have any of the values listed in "
 
It's not the type that supports the list.
 [Linlin] Yes, thank you for your text.
 
 
 
S 3.4.
> rejected.
>   
>  o  linked: The organization object has at least one active
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers should provide services to
> determine existing object associations.
 
I'm not following this text. It is set by the server?
[Linlin] Yes, it is set by the server. Benjamin's comment will be adopted. 
Adding a sentence to clarify. "Other status values that do not begin with 
either "client" or "server" are server-managed".
 
 
S 3.4.
> has been processed for the object, but the action has not been
> completed by the server.  Server operators can delay action
> completion for a variety of reasons, such as to allow for human
> review or third-party action.  A transform command that is
> processed, but whose requested action is pending, is noted with
> response code 1001.
 
Who can set this?
 [Linlin] The server can set the error code to 1001 and send the response to 
the client.
 
S 3.5.
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers SHOULD provide services to
> determine existing object associations.
>   
>  o  clientLinkProhibited, serverLinkProhibited: Requests to add new
> links to the role MUST be rejected.
 
see above question about access control
[Linlin] If both the clientXXXProhibited

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
Please see my feedbacks below. I've removed the clarified items.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-25 02:34
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-11: (with COMMENT)

> --
> COMMENT:
> --
>  
> Some of the element descriptions (e.g., ) appear to be
> duplicated in several places and are also rather long in prose form.  Is
> there value in attempting to consolidate the structural definition to a
> single place in the document and just refer to that structure from the
> places where it can appear?
> [Linlin] This document borrowed the text structure from RFC5731, RFC5732 and 
> RFC5733 of EPP. I think the intension of having some duplicated descriptions 
> is for users' easy reading. When seeing the examples, they do not have to 
> scroll up and down to find the elements definitions. Some descriptions are a 
> little different, although  elements appear to be duplicated. 
> Such as, "One or more  elements" in  response and  "Zero or 
> more  elements" in  command. Of course putting all the 
> elements definitions in a section is a concise way for the document structure.
 
It sounds like it is not worth making this change for this document, then.
Thanks for the background explanation!
[Linlin] On one hand, the duplicated elements are needed to address the server 
policy differences to make it easier for implementors. And on the other hand, 
it is consistent with the other EPP RFCs (RFC 5731 - 5733).

>  
> Section 4.1.2
>  
> The  restrictions seem somewhat contrived/artificially
> restricted; for example, there are postal addresses in the US with no
> associated city.  Whether an organization would want to use such an address
> as its contact location is another question, but I don't have a clear model
> of what sort of constraints are intended to be applied by this element.
> [Linlin] Sorry that I am not familiar with the US address. If no city is 
> available, how about municipal or county information?
 
The type of place I'm thinking of would usually be referred to as
"unincorporated DeKalb County" or occasionally "unincorporated Chicago"
with some associated municipal or city information.  (As something of a
side note, I currently reside in Saint Louis city, which is not part of any
county; there is a distinct Saint Louis County that covers the surrounding
areas.  Addresses can be hard; just like (personal) names!)
[Linlin] Thanks for your information. Learnt a lot.
 
> This  element have the same structure with the  
> defined in RFC5733. This is an existing XML schema in the running EPP system. 
> Domain registries and registrars have already implemented it. Acturally this 
> is an optional info here. You can have no , one  or 
> two  elements.
 
I definitely do not want to suggest diverging the definition of
 from RFC5733, so please treat this entire conversation as a
side note with no actions to take.
[Linlin] Ok. Thank you.
 
> Section 4.2.2
>  
> Is there value in an example of the 2305-error response?
> [Linlin] I think the example of 2305 error would like follows,
> S: 
> S: 
> S:  
> S:  
> S: Object association prohibits operation 
> S:  
> S:  
> S: ABC-12345 
> S: 54321-XYZ 
> S:  
> S:  
> S:
>  
> This example is much the similar with the existing one except for the "code" 
> and "msg".
 
This is true, which suggests that there is not much value in having the
additional example.  Thank you for showing me what it would look like,
though.
[Linlin] OK.
 
> Section 4.2.5
>  
> The elements in / vs.  seem to be disjoint sets;
> what factors went into deciding to split them this way?
> [Linlin] From my understanding, / are used for the 
> one-multiple relations. And  is used for the one-one replacement.
>  
> Section 4.3
>  
>  The status of the corresponding object MUST clearly reflect
>processing of the pending action.  [...]
>  
> It's not entirely clear how this sentence is to be interpreted.  From
> context, I assume that the intent is that  queries and similar must
> report that the appropriate pendingFoo status values, but a literal reading
> would seem to have this sentence be a requirement that the server change
> what it reports for the object status, once the action is actually taken.
> (Which is also something desired, but arguably already required by other
> text.)
>  [Linlin] The "transform command" is mentioned in the previous text. So the 
> s

Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Ben,
Thanks for your suggestions. I think I can add this paragraph in the section of 
security consideration.

The organization object may have personally identifiable information, such as 
. This information is not a required element in this document 
which can be provided on a voluntary basis. If it is provided, both client and 
server MUST ensure that authorization information is stored and exchanged with 
high-grade encryption mechanisms to provide privacy services, which is 
specified in RFC5733. The security considerations described in[RFC5730] or 
those caused by the protocol layers used by EPP will apply to this 
specification as well.

Regards,
Linlin


Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-25 10:08
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)


On Oct 24, 2018, at 8:50 PM, Linlin Zhou  wrote:

Dear Ben,
Maybe I did not make this item clarified. I'd like to have some more 
explanations. You are right that the EPP organization object may have a 
 element, but this is not a required information. There may be some 
possibilities as follows,
1. If the organizations do not want to provide this information to protect the 
privacy, the  could be empty.
2. If the organizations have no issues on the privacy, they can input the 
contact identifier created according to RFC5733.
a. In RFC5733, required info including contact id, contact name, city, 
country code, email and authentication info.
b. Optional info including contact organization, street, state or province, 
postal code, voice, fax and disclose elements choices.
"Authorization information is REQUIRED to create a contact object. ..Both 
client and server MUST ensure that authorization information is stored and 
exchanged with high-grade encryption 
mechanisms to provide privacy services." was specified in RFC5733.

The organization object may have personally identifiable information, such as 
. This information is not a required element in this document 
which can be provided on a voluntary basis. If it is provided, both client and 
server MUST ensure that authorization information is stored and exchanged with 
high-grade encryption mechanisms to provide privacy services, whichi is 
specified in RFC5733.

Hi,

Your last paragraph above is the sort of thing I had in mind. It would be 
helpful to include it in the draft. I

Thanks!

Ben.


Regards,
Linlin


Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-25 01:32
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: 
(with COMMENT)
Thanks for your response. It all looks good, except for one item below:

Thanks!

Ben.

On Oct 24, 2018, at 5:05 AM, Linlin Zhou  wrote:


[...]

 
§9: The org element can contain contact information, possibly including
personally identifiable information of individuals. Doesn’t this have privacy
implications that should be discussed here or in a privacy considerations
section?
[Linlin] This document is an object extension of EPP that follows all the 
security requirements for EPP. We do not hope to add any more secure 
considerations in this document. So this element can be "zero" if you do not 
like to provide.
 

I don’t understand how your answer addresses my question. As far as I can tell, 
this document creates a new object that can contain personally identifiable 
information (PII). Is that incorrect?

Is there text in EPP that already talks about PII that can be cited?


[...]

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

Re: [regext] Spencer Dawkins' No Objection on draft-ietf-regext-org-ext-09: (with COMMENT)

[Linlin Zhou]

Dear Spencer,
Thanks for your review. Please see my feedbacks inline.

Regards,
Linlin


Linlin Zhou
 
From: Spencer Dawkins
Date: 2018-10-25 10:25
To: The IESG
CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
Subject: [regext] Spencer Dawkins' No Objection on 
draft-ietf-regext-org-ext-09: (with COMMENT)
Spencer Dawkins has entered the following ballot position for
draft-ietf-regext-org-ext-09: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
 
 
--
COMMENT:
--
 
If "huh?" was a ballot position, I would have used it. I'm actually too
confused to ballot Discuss :-)
 
I see several subsections of the form
 
   This extension does not add any elements to the EPP  command
   or  response described in the EPP object mapping.
 
I see other subsections in the same section that say what the extension DOES,
not just what the extension does not do.
 
Is there anything that can be included in these sections to tell the reader
more about what the effect of using the extension actually is?
[Linlin] This is a relatively simple Command-Response Extension defined in 
section 2.7.3 in RFC 5730. The implementors can add some self-defined elements 
in the  part, such as,
extension in the EPP command

C: 
C:  
C:  
C:  
C:  
C:  
C:  
C:  
C:  
C:  
C:

extension in the EPP response,
S: 
S:  
S: Command completed successfully 
S:  
S:  
S:  
S:  
S:  
S: ABC-12345 
S: 54321-XYZ 
S:  
S:


This document extends the exsting EPP object mappings including the 
organization id and role type information. In section 4.1.1, the extension will 
not modify the  command and response, just keep it as it is defined in 
RFC5731-RFC5733.  In section 4.1.2, the extension has no change on  
command, but extends the  response. So the document says "This extension 
does not add any elements to the EPP  command described in the EPP object 
mapping. However, additional elements are defined for the  response in 
the EPP object mapping." There is some explanations in the first paragraph of 
each  EPP commands section, to tell implementors if this command or response is 
extended. If it is extended, you can find extension elements in the following 
text.
 
 
___
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] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Eric,
Please see my feedbacks inline. I've removed the clarified items.

Regards,
Linlin


Linlin Zhou
  
--
DISCUSS:
--
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
 
 
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>  o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>   
>  o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are 
set, these two statuses can coexist in the system. "clientUpdateProhibited" is 
set by the client and "serverUpdateProhibited" is set by the server.

That's not what I mean. What I mean is "what is the access control rule that 
the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model 
used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define 
the command-level access control rules, where each supported transform command 
(update and delete) includes a corresponding client-settable ("client") and 
server-settable ("server") that prohibits execution of the command by the 
client. The client is allowed make an update only to remove the 
"clientUpdateProhibited" status when the "clientUpdateProhibited" status is 
set. Client-specific access control rules (e.g., sponsoring client versus 
non-sponsoring client) is not defined by the statuses, but is up to server 
policy.
 

 
S 4.1.2.
>   
>  o  One or more  elements that contain the operational
> status of the organization, as defined in Section 3.4.
>   
>  o  An OPTIONAL  element that contains the identifier of
> the parent object, as defined in Section 3.6.
 
It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up 
to the server policy to decide 
what optional attributes will be returned of an organization object." or just 
remove it?

I don't know, because I don't understand the semantics you are aiming for. Are 
the other attributes optional.
[Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence 
"It is up to the server policy to decide what attributes will be returned of an 
organization object."


--
COMMENT:
--
  
 
 
S 3.4.
> has been processed for the object, but the action has not been
> completed by the server.  Server operators can delay action
> completion for a variety of reasons, such as to allow for human
> review or third-party action.  A transform command that is
> processed, but whose requested action is pending, is noted with
> response code 1001.
 
Who can set this?
 [Linlin] The server can set the error code to 1001 and send the response to 
the client.

Sorry, context got lost. Who can set "pendingCreate"?
[Linlin] PendingCreate or PendingXXX statuses are set by servers.

 
S 3.5.
> association with another object.  The "linked" status is not
> explicitly set by the client.  Servers SHOULD provide services to
> determine existing object associations.
>   
>  o  clientLinkProhibited, serverLinkProhibited: Requests to add new
> links to the role MUST be rejected.
 
see above question about access control
[Linlin] If both the clientXXXProhibited and serverXXXProhibited are set, this 
situation is permitted.

Sorry, this is still not clear to me. 
 
[Linlin] Please see the above response.

 
S 4.2.1.
> status of the organization, as defined in Section 3.4.
>   
>  o  An OPTIONAL  element that contains the identifier of
> the parent object, as defined in Section 3.6.
>   
>  o  Zero to two  elements that contain postal-address
 
These rules looks duplicative of . Is there a way to collapse
them?

[Linlin] The attributes need to be defined differently for the create and the 
info response, since the info response needs to be more flexible with what is 
returned based on server policy decisions. Yes, they are the same elements, but 
whether 

Re: [regext] IANA Considerations for draft-ietf-regext-org and draft-ietf-regext-org-ext

[Linlin Zhou]

Thank you Scott. I checked the RFC7451, the registration should be updated like 
this,

Name of Extension: Extensible Provisioning Protocol (EPP) Organization Mapping 
Document Status: Standards Track
Reference: RFC
Registrant Name and Email Address: IESG, i...@ietf.org 
TLDs: Any 
IPR Disclosure: None 
Status: Active 
Notes: None

Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-10-25 23:00
To: 'regext@ietf.org'
CC: 'i...@ietf.org'
Subject: [regext] IANA Considerations for draft-ietf-regext-org and 
draft-ietf-regext-org-ext
Minor comments here that I just noticed while looking at a different document...
 
The registration template for the EPP extensions registry is described in 
Sections 2.2.1 and 2.2.2 of RFC 7451. Both draft-ietf-regext-org and 
draft-ietf-regext-org-ext are missing the "Reference" information. It should be 
added, like this (or similar):
 
Reference: RFC  (please replace "" with the RFC number for this 
document after a number is assigned by the RFC Editor)
 
Scott
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
I've included my feedbacks inline and removed the clarified items.

Regards,
Linlin


Linlin Zhou

> --
> DISCUSS:
> --
 
> Second, I am unsure of the semantics relating to role types, especially as
> they interact with the  command.  Various aspects of the examples
> seem to imply that it is only permitted to have at most one organization
> mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
> particular, the  element seems to be using the  role
> attribute to determine which  is being changed (with the new
> value being provided in the element body), and the  element is
> providing  with only the role attribute and no body to identify
> a specific organization to remove.  If this reading of the document is
> correct, then I would expect the limitation to be called out more clearly,
> especially as it would seem to prevent a domain owner from (e.g.) using
> multiple DNS service operators.
> [Linlin] In the normal business model, for example a domain should have one 
> reseller, one registrar etc.  How about adding some text like "One 
>  element is suggested for each role type." in the element 
> description.
 
I don't think that addresses my core concern (though it is probably worth
doing in its own right).
 
In particular, if it is allowed by the protocol/registry to have more than
one  element of a given role type, then several of the protocol
exchanges this document defines within  are not fully defined in an
interoperable fashion.  For example, what if I receive a
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-org extensibility comments

[Linlin Zhou]

Dear Martin,
Thank you for your review. Please see my feedbacks inline.

Regards,
Linlin


Linlin Zhou
 
From: Martin Thomson
Date: 2018-10-26 05:09
To: regext
Subject: [regext] draft-ietf-regext-org extensibility comments
Hi,
 
I was asked to review draft-ietf-regext-org for the XML namespace and
schema registries.  Everything looks fine, except that I think we got
crossed wires somewhere in the back and forth.
 
The comment I made was that certain types use xs:enumeration with a
set of values.  Here I refer to epp-org:statusType,
epp-org:roleStatusType, and epp-org:contactAttrType.
 
The question was whether these types were intended to be extended, or
whether the working group was confident that the list was exhaustive.
Based on the content of the lists, it doesn't appear possible that the
lists could be exhaustive, but maybe there are constraints in this
domain that ensure this is the case.
 
The current structure of the schema would prevent these from ever
being extended [1].  The comment was then a question: does the working
group believe that the set of values for these
[Linlin] The above mentioned types have already been existed in other EPP RFCs 
except for some unique values specified for EPP organization object. As far as 
I know, no registrar or registry has the requirement to extend these existing 
type values for the domain business model. Only when proposal for providing a 
"grace period" for DNS came out, the Redemption Grace Period (RGP) status 
values were extended in RFC3915 which defined a new element in the EPP 
extension. Please correct me if I am wrong.
 
When I asked, the response was about epp-org:roleType/type. That
confused me.  That element is defined as xs:token and has a registry
associated with it, so it's clear that this is extensible.  I'm asking
about these enumerated types.
[Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in this 
xml-registry are four initial values exsting in the domain regitrar-registry 
model. If there are new roles coming out in the future, we hope they can follow 
the IANA change control process and be registered in the existing registry 
described in section 3 of RFC8126. The new roles should be known and accepted 
by most people.
WG discussed about this registry and had some consensus on it. Please refer to 
https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. 
 
And a bonus question, which I would not have commented on as the
designated expert, but since I'm writing, I'll ask for my own
gratification: Why define yet another addressing format?  Just in the
IETF we have a ton of those already.  RFC 5139 (of which I'm an
author, for my sins), RFC 6351 (XML vCard), just to start with.
[Linlin] The address format in this document tries to be consistent with EPP 
RFCs which is defined in RFC5733. And RFC5733 was updated from RFC3733. I guess 
RFC3733 was written in 2004 and there may be no relatively proper addressing 
format to reuse then. So the author defined a format for EPP. Of course this is 
just my guess:)
 
--Martin
 
 
[1] I guess you could say that the schema isn't normative, and it's
just illustrative.  But that is contrary to common practice and would
require a LOT more text for the document to make any sense, because
you would end up relying much more on the text having a normative
description of elements.  So I'm assuming here that implementations
will be allowed to reject inputs that fail schema validation.
 
___
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] IANA Considerations for draft-ietf-regext-org and draft-ietf-regext-org-ext

[Linlin Zhou]

Hi Scott,
Thank you for your information. I'll remember to add the text in the brackets.

Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-10-29 19:11
To: 'zhoulin...@cnnic.cn'; 'regext@ietf.org'
CC: 'i...@ietf.org'
Subject: Re: [regext] IANA Considerations for draft-ietf-regext-org and 
draft-ietf-regext-org-ext
Linlin, you might want to keep some text in the document so that the RFC Editor 
knows to change “” to the assigned RFC number and IANA knows to use that 
number.
 
Scott
 
From: Linlin Zhou  
Sent: Monday, October 29, 2018 4:33 AM
To: Hollenbeck, Scott ; regext 
Cc: iesg 
Subject: [EXTERNAL] Re: [regext] IANA Considerations for draft-ietf-regext-org 
and draft-ietf-regext-org-ext
 
Thank you Scott. I checked the RFC7451, the registration should be updated like 
this,
 
Name of Extension: Extensible Provisioning Protocol (EPP) Organization Mapping 
Document Status: Standards Track
Reference: RFC
Registrant Name and Email Address: IESG, i...@ietf.org 
TLDs: Any 
IPR Disclosure: None 
Status: Active 
Notes: None
 
Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-10-25 23:00
To: 'regext@ietf.org'
CC: 'i...@ietf.org'
Subject: [regext] IANA Considerations for draft-ietf-regext-org and 
draft-ietf-regext-org-ext
Minor comments here that I just noticed while looking at a different document...
 
The registration template for the EPP extensions registry is described in 
Sections 2.2.1 and 2.2.2 of RFC 7451. Both draft-ietf-regext-org and 
draft-ietf-regext-org-ext are missing the "Reference" information. It should be 
added, like this (or similar):
 
Reference: RFC  (please replace "" with the RFC number for this 
document after a number is assigned by the RFC Editor)
 
Scott
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-org extensibility comments

[Linlin Zhou]

Thank you all.

Regards,
Linlin


Linlin Zhou
 
From: Martin Thomson
Date: 2018-10-31 06:46
To: Adam Roach
CC: zhoulinlin; regext
Subject: Re: [regext] draft-ietf-regext-org extensibility comments
Already done.
On Wed, Oct 31, 2018 at 5:11 AM Adam Roach  wrote:
>
> Thanks, Martin. Can you follow up with IANA to let them know that your
> concerns have been satisfied?
>
> /a
>
> On 10/30/18 4:54 AM, Martin Thomson wrote:
> > Thanks Linlin, that helps.  If these are following existing patterns,
> > that works for me.
> > On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou  wrote:
> >> Dear Martin,
> >> Thank you for your review. Please see my feedbacks inline.
> >>
> >> Regards,
> >> Linlin
> >> 
> >> Linlin Zhou
> >>
> >>
> >> From: Martin Thomson
> >> Date: 2018-10-26 05:09
> >> To: regext
> >> Subject: [regext] draft-ietf-regext-org extensibility comments
> >> Hi,
> >>
> >> I was asked to review draft-ietf-regext-org for the XML namespace and
> >> schema registries.  Everything looks fine, except that I think we got
> >> crossed wires somewhere in the back and forth.
> >>
> >> The comment I made was that certain types use xs:enumeration with a
> >> set of values.  Here I refer to epp-org:statusType,
> >> epp-org:roleStatusType, and epp-org:contactAttrType.
> >>
> >> The question was whether these types were intended to be extended, or
> >> whether the working group was confident that the list was exhaustive.
> >> Based on the content of the lists, it doesn't appear possible that the
> >> lists could be exhaustive, but maybe there are constraints in this
> >> domain that ensure this is the case.
> >>
> >> The current structure of the schema would prevent these from ever
> >> being extended [1].  The comment was then a question: does the working
> >> group believe that the set of values for these
> >> [Linlin] The above mentioned types have already been existed in other EPP 
> >> RFCs except for some unique values specified for EPP organization object. 
> >> As far as I know, no registrar or registry has the requirement to extend 
> >> these existing type values for the domain business model. Only when 
> >> proposal for providing a "grace period" for DNS came out, the Redemption 
> >> Grace Period (RGP) status values were extended in RFC3915 which defined a 
> >> new element in the EPP extension. Please correct me if I am wrong.
> >>
> >> When I asked, the response was about epp-org:roleType/type. That
> >> confused me.  That element is defined as xs:token and has a registry
> >> associated with it, so it's clear that this is extensible.  I'm asking
> >> about these enumerated types.
> >> [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in 
> >> this xml-registry are four initial values exsting in the domain 
> >> regitrar-registry model. If there are new roles coming out in the future, 
> >> we hope they can follow the IANA change control process and be registered 
> >> in the existing registry described in section 3 of RFC8126. The new roles 
> >> should be known and accepted by most people.
> >> WG discussed about this registry and had some consensus on it. Please 
> >> refer to 
> >> https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs.
> >>
> >> And a bonus question, which I would not have commented on as the
> >> designated expert, but since I'm writing, I'll ask for my own
> >> gratification: Why define yet another addressing format?  Just in the
> >> IETF we have a ton of those already.  RFC 5139 (of which I'm an
> >> author, for my sins), RFC 6351 (XML vCard), just to start with.
> >> [Linlin] The address format in this document tries to be consistent with 
> >> EPP RFCs which is defined in RFC5733. And RFC5733 was updated from 
> >> RFC3733. I guess RFC3733 was written in 2004 and there may be no 
> >> relatively proper addressing format to reuse then. So the author defined a 
> >> format for EPP. Of course this is just my guess:)
> >>
> >> --Martin
> >>
> >>
> >> [1] I guess you could say that the schema isn't normative, and it's
> >> just illustrative.  But that is contrary to common practice and would
> >> require a LOT more text for the document to make any sense, because
> >> you would end up relying much more on the text having a normative
> >> description of elements.  So I'm assuming here that implementations
> >> will be allowed to reject inputs that fail schema validation.
> >>
> >> ___
> >> 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] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Eric,
Please see my feedbaks below.

Regards,
Linlin


Linlin Zhou
--
DISCUSS:
--
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
 
 
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>  o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>   
>  o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are 
set, these two statuses can coexist in the system. "clientUpdateProhibited" is 
set by the client and "serverUpdateProhibited" is set by the server.

That's not what I mean. What I mean is "what is the access control rule that 
the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model 
used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define 
the command-level access control rules, where each supported transform command 
(update and delete) includes a corresponding client-settable ("client") and 
server-settable ("server") that prohibits execution of the command by the 
client. The client is allowed make an update only to remove the 
"clientUpdateProhibited" status when the "clientUpdateProhibited" status is 
set. Client-specific access control rules (e.g., sponsoring client versus 
non-sponsoring client) is not defined by the statuses, but is up to server 
policy.

I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? 
[Linlin] Our proposal is to add the lead-in bolded text to match the existing 
EPP RFC's to the Organization mapping. There has been no issues with the 
interpretation of the statuses with the EPP RFCs, so it's best to match them as 
closely as possible. In section 3.4,

An organization object MUST always have at least one associated status 
value. Status values can be set only by the client that sponsors an 
organization object and by the server on which the object resides. A 
client can change the status of an organization object using the EPP 
 command. Each status value MAY be accompanied by a string 
of human-readable text that describes the rationale for the status 
applied to the object. 

A client MUST NOT alter status values set by the server. A server 
MAY alter or override status values set by a client, subject to local 
server policies. The status of an object MAY change as a result of 
either a client-initiated transform command or an action performed by 
a server operator.

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". The "hold" and 
"terminated" status values are server-managed when the organization 
has no parent identifier [Section 3.6] and otherwise MAY be client- 
managed based on server policy. Status values that 
do not begin with either "client" or "server" are server-managed.

Take "clientUpdateProhibited" for example. 
If status value "clientUpdateProhibited" is set by a client 
then  command is not allowed to perform by a client 
If status value "clientUpdateProhibited" is removed by a client or a server 
then no limitation of performing EPP commands 

 

 
S 4.1.2.
>   
>  o  One or more  elements that contain the operational
> status of the organization, as defined in Section 3.4.
>   
>  o  An OPTIONAL  element that contains the identifier of
> the parent object, as defined in Section 3.6.
 
It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL
[Linlin] If this sentence makes confusion. How about changing it to "It is up 
to the server policy to decide 
what optional attributes will be returned of an organization object." or just 
remove it?

I don't know, because I don't understand the semantics you are aiming for. Are 
the other attributes optional.
[Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence 
"It is up to the server policy to decide what attributes will be returned of an 
organization object."

Does that mean the other attributes are mandatory? If so, you need to

Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set 
"clientLinkProhibited" but can not alter "ok". "ok" and "clientLinkProhibited" 
can coexist.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 11:23
To: Linlin Zhou
CC: Eric Rescorla; regext-chairs; Pieter Vandepitte; iesg; regext; 
draft-ietf-regext-org
Subject: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)
Trimming to just one potentially problematic suggestion...
 
On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:
> 
> Linlin Zhou
> --
> DISCUSS:
> --
[...]
> [Linlin] Our proposal is to add the lead-in bolded text to match the existing 
> EPP RFC's to the Organization mapping. There has been no issues with the 
> interpretation of the statuses with the EPP RFCs, so it's best to match them 
> as closely as possible. In section 3.4,
 
[bold does not work super-well in text/plain mail, but
https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show
it]
 
> An organization object MUST always have at least one associated status 
> value. Status values can be set only by the client that sponsors an 
> organization object and by the server on which the object resides. A 
> client can change the status of an organization object using the EPP 
>  command. Each status value MAY be accompanied by a string 
> of human-readable text that describes the rationale for the status 
> applied to the object. 
> 
> A client MUST NOT alter status values set by the server. A server 
 
This seems overly zealous to the point of being harmful.  For example, if a
server sets the status to "ok", a client cannot replace it by
clientLinkProhibited?
 
-Benjamin
 
> MAY alter or override status values set by a client, subject to local 
> server policies. The status of an object MAY change as a result of 
> either a client-initiated transform command or an action performed by 
> a server operator.
> 
> 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". The "hold" and 
> "terminated" status values are server-managed when the organization 
> has no parent identifier [Section 3.6] and otherwise MAY be client- 
> managed based on server policy. Status values that 
> do not begin with either "client" or "server" are server-managed.
> 
> Take "clientUpdateProhibited" for example. 
> If status value "clientUpdateProhibited" is set by a client 
> then  command is not allowed to perform by a client 
> If status value "clientUpdateProhibited" is removed by a client or a server 
> then no limitation of performing EPP commands 
> 
>  
> 
>  
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 

> > --
> > COMMENT:
> > --
> > Section 4.3
> > 
> >The status of the organization object after returning this response
> >MUST include "pendingCreate".  The server operator reviews the
> >request offline, and informs the client of the outcome of the review
> >either by queuing a service message for retrieval via the 
> >command or by using an out-of-band mechanism to inform the client of
> >the request.
> >  
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> >  [Linlin] This mechanism is supported in section 2.9.2.3 of RFC5730. 
> > So this is a easy and convinient way to inform the clients.
>  
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y".  The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can 
> have two choices to inform the result by  of EPP command or by 
> out-of-band actions. The following  response is an example using  
> mechanism. Of course you can also send an email to to contact of the 
> organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
> 
 
Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:
 
   Once
   the action has been completed, the client MUST be notified using a
   service message that the action has been completed and that the
   status of the object has changed.  Other notification methods MAY be
   used in addition to the required service message.
 
The text here in Section 4.3 says:
 
   The status of the organization object after returning this response
   MUST include "pendingCreate".  The server operator reviews the
   request offline, and informs the client of the outcome of the review
   either by queuing a service message for retrieval via the 
   command or by using an out-of-band mechanism to inform the client of
   the request.
 
which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.
 
My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead".  An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.

[Linlin] I can understand your concerns now. I think I had better propose a 
thread and ask the author or other EPP experts for confirmation. Once I get the 
feedback, I'll have a response. Thank you.
 

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
Thanks for your input. We believe that relationship between an object and an 
organization should be 1-to-1, one organization ID with just one role. 
1-to-many is an exception for the organization extension. Indeed that is our 
concern, "the multiple examples may be overkill". Many thanks.
 
Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 09:05
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: Re: [regext] Benjamin Kaduk's Discuss on 
draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
On Tue, Oct 30, 2018 at 10:16:05AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> I've included my feedbacks inline and removed the clarified items.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
> 
> > --
> > DISCUSS:
> > --
>  
> > Second, I am unsure of the semantics relating to role types, especially as
> > they interact with the  command.  Various aspects of the examples
> > seem to imply that it is only permitted to have at most one organization
> > mapping of a given role type (i.e., one reseller, one proxy, etc.).  In
> > particular, the  element seems to be using the  role
> > attribute to determine which  is being changed (with the new
> > value being provided in the element body), and the  element is
> > providing  with only the role attribute and no body to identify
> > a specific organization to remove.  If this reading of the document is
> > correct, then I would expect the limitation to be called out more clearly,
> > especially as it would seem to prevent a domain owner from (e.g.) using
> > multiple DNS service operators.
> > [Linlin] In the normal business model, for example a domain should have one 
> > reseller, one registrar etc.  How about adding some text like "One 
> >  element is suggested for each role type." in the element 
> > description.
>  
> I don't think that addresses my core concern (though it is probably worth
> doing in its own right).
>  
> In particular, if it is allowed by the protocol/registry to have more than
> one  element of a given role type, then several of the protocol
> exchanges this document defines within  are not fully defined in an
> interoperable fashion.  For example, what if I receive a
>  association prohibits operation".
 
That seems reasonable to me, given that we expect this situation to be
uncommon, and a combination of  and  should allow
the desired changes to be made more precisely.
 
> Maybe some words like "An attempt to change an organization ID with a 
> particular role value, when multiple IDs exist with the same role value, does 
> not change the object at all. A server SHOULD notify clients that object 
> relationships need to be checked by sending a 2305 error response code. "
> 
> 
 
I would suggest a little more lead-in text, maybe like:
 
It is expected to generally be the case that any given object will have at
most one associated organization ID for any given role value, though the
registry semantics do permit two or more associated organizations for a
given role.  In such cases, certain  and 
elements may not uniquely specify an operation to perform (e.g., which of
two organizations to replace via , or which of two
organizations to remove via an  with empty body).  An attempt
to change an organization ID with a particular role value, when multiple
IDs exist with the same role value, does not change the object at all. A
server SHOULD notify clients that object relationships need to be checked
by sending a 2305 error response code.
 
Feel free to edit as you see fit; my only concern is that the expected
behavior is specified, not how it is written.  (In particular, given how
uncommon this situation is expected to be, the multiple examples may be
overkill.)
 
-Benjamin
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Sorry for correction. The client can set "clientLinkProhibited" but can not 
alter "ok". "ok" should be removed by the server.



Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 11:37
To: Benjamin Kaduk
CC: Eric Rescorla; draft-ietf-regext-org; regext-chairs; Pieter Vandepitte; 
iesg; regext
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)
Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set 
"clientLinkProhibited" but can not alter "ok". 

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 11:23
To: Linlin Zhou
CC: Eric Rescorla; regext-chairs; Pieter Vandepitte; iesg; regext; 
draft-ietf-regext-org
Subject: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)
Trimming to just one potentially problematic suggestion...
 
On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:
> 
> Linlin Zhou
> --
> DISCUSS:
> --
[...]
> [Linlin] Our proposal is to add the lead-in bolded text to match the existing 
> EPP RFC's to the Organization mapping. There has been no issues with the 
> interpretation of the statuses with the EPP RFCs, so it's best to match them 
> as closely as possible. In section 3.4,
 
[bold does not work super-well in text/plain mail, but
https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show
it]
 
> An organization object MUST always have at least one associated status 
> value. Status values can be set only by the client that sponsors an 
> organization object and by the server on which the object resides. A 
> client can change the status of an organization object using the EPP 
>  command. Each status value MAY be accompanied by a string 
> of human-readable text that describes the rationale for the status 
> applied to the object. 
> 
> A client MUST NOT alter status values set by the server. A server 
 
This seems overly zealous to the point of being harmful.  For example, if a
server sets the status to "ok", a client cannot replace it by
clientLinkProhibited?
 
-Benjamin
 
> MAY alter or override status values set by a client, subject to local 
> server policies. The status of an object MAY change as a result of 
> either a client-initiated transform command or an action performed by 
> a server operator.
> 
> 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". The "hold" and 
> "terminated" status values are server-managed when the organization 
> has no parent identifier [Section 3.6] and otherwise MAY be client- 
> managed based on server policy. Status values that 
> do not begin with either "client" or "server" are server-managed.
> 
> Take "clientUpdateProhibited" for example. 
> If status value "clientUpdateProhibited" is set by a client 
> then  command is not allowed to perform by a client 
> If status value "clientUpdateProhibited" is removed by a client or a server 
> then no limitation of performing EPP commands 
> 
>  
> 
>  
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
I re-read the two paragraphs again and again. And I think I have the thought in 
mind that "service message" may be the key words to make you confused. 
In section 4.2, "the client MUST be notified using a service message", this 
"service message" has a relatively broad meaning, that it means the in-band or 
out-or-band service message. And "MUST" means you must send the message whether 
online or offline to the client.
If the above understanding is proper, In section 4.3 "either by queuing a 
service message for retrieval via the  command...", this "service 
message" is not specified for  excusively. 
Of course, I'll try to confirm with other EPP experts in parallel.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 13:45
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 

> > --
> > COMMENT:
> > --
> > Section 4.3
> > 
> >The status of the organization object after returning this response
> >MUST include "pendingCreate".  The server operator reviews the
> >request offline, and informs the client of the outcome of the review
> >either by queuing a service message for retrieval via the 
> >command or by using an out-of-band mechanism to inform the client of
> >the request.
> >  
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> >  [Linlin] This mechanism is supported in section 2.9.2.3 of RFC5730. 
> > So this is a easy and convinient way to inform the clients.
>  
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y".  The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can 
> have two choices to inform the result by  of EPP command or by 
> out-of-band actions. The following  response is an example using  
> mechanism. Of course you can also send an email to to contact of the 
> organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
> 
 
Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:
 
   Once
   the action has been completed, the client MUST be notified using a
   service message that the action has been completed and that the
   status of the object has changed.  Other notification methods MAY be
   used in addition to the required service message.
 
The text here in Section 4.3 says:
 
   The status of the organization object after returning this response
   MUST include "pendingCreate".  The server operator reviews the
   request offline, and informs the client of the outcome of the review
   either by queuing a service message for retrieval via the 
   command or by using an out-of-band mechanism to inform the client of
   the request.
 
which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.
 
My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead".  An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.

[Linlin] I can understand your concerns now. I think I had better propose a 
thread and ask the author or other EPP experts for confirmation. Once I get the 
feedback, I'll have a response. Thank you.
 

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
I found that following sections may be the proper place to restrict the 1-to-1 
mapping. I think we can have restrictions in section 3.1 only or in 
3.1&4.2.1&4.2.5. I've not decided which one is better and hope to have others' 
suggestions.

1. In section 3.1 Organization Identifier, add sentences at the end of this 
paragraph.
A "role" attribute is used to represent the relationship that the organization 
has to the EPP object. Any given object MUST have at most one associated 
organization ID for any given role value.

2. In section 4.2.1,
One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values.

3. In section 4.2.5
One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values. 

If we have the restrictions, the 1-to-multiple mapping cases are not necessary 
to be specified in this document.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 20:43
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
Dear Linlin,
 
On Wed, Oct 31, 2018 at 02:19:45PM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> Thanks for your input. We believe that relationship between an object and an 
> organization should be 1-to-1, one organization ID with just one role. 
> 1-to-many is an exception for the organization extension. Indeed that is our 
> concern, "the multiple examples may be overkill". Many thanks.
 
I won't object to requiring the 1-to-1 mapping, as the impact of the
restriction seems minor.  I am not entirely sure where the best place to
add some text that clarifies this restriction would be; perhaps in Section
4.2.1 where we describe the  elements in ?  (I assume
that the formal syntax does not provide for a maxOccurs that applies
per-type.)  It may also be worth a (non-normative) reminder in the 
description that the semantics of  are well-defined because
there is only one entry per role value, but I'm not sure about that.
 
Thanks,
 
Benjamin
 
___
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] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Eric,
Sorry for my misunderstanding. Followings are some pseudocode examples for 
status value changes. But in the real domain business model, there may be other 
requirement limitations, running code may be different.  Please note that I 
just listed some major situations, not all of them.

1. organization create

add "pendingCreate"

2. organization update

if ("serverUpdateProhibited" or "pendingDelete" or "pendingUpdate" existed) 
cannot update
else 
go 

if ("pendingCreate" existed) 
can update but no "pendingUpdate" 
else 
update and add "pendingUpdate"

if ("clientUpdateProhibited" existed) 
cannot update
else 
go 

if (recv 'remove clientUpdateProhibited' && other status update commands) 
cannot update

3. organization delete

if ("clientDeleteProhibited" or "serverDeleteProhibited" or "pendingUpdate" or 
"pendingDelete" existed)//no pendingCreate 
cannot delete 
cannot add "pendingDelete" 

if ("pendingCreate" existed) 
remove "pendingCreate" 
add "pendingDelete" 

4. other status actions

if (organization is linked with an EPP object && "clientLinkedProhibited" or 
"serverLinkedProhibited" not exist) 
add "linked" 

if (organization status is null || only "linked" existed) 
add "ok" 
else 
remove "ok"

Regards,
Linlin


Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-31 11:23
To: zhoulinlin
CC: regext-chairs; pieter.vandepitte; IESG; regext; draft-ietf-regext-org
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)


On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou  wrote:
Dear Eric,
Please see my feedbaks below.

Regards,
Linlin


Linlin Zhou
--
DISCUSS:
--
 
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624
 
 
This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.
 
DETAIL
S 3.4.
>   
>  o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
> the object (other than to remove this status) MUST be rejected.
>   
>  o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
> the object MUST be rejected.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are 
set, these two statuses can coexist in the system. "clientUpdateProhibited" is 
set by the client and "serverUpdateProhibited" is set by the server.

That's not what I mean. What I mean is "what is the access control rule that 
the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model 
used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define 
the command-level access control rules, where each supported transform command 
(update and delete) includes a corresponding client-settable ("client") and 
server-settable ("server") that prohibits execution of the command by the 
client. The client is allowed make an update only to remove the 
"clientUpdateProhibited" status when the "clientUpdateProhibited" status is 
set. Client-specific access control rules (e.g., sponsoring client versus 
non-sponsoring client) is not defined by the statuses, but is up to server 
policy.

I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? 
[Linlin] Our proposal is to add the lead-in bolded text to match the existing 
EPP RFC's to the Organization mapping. There has been no issues with the 
interpretation of the statuses with the EPP RFCs, so it's best to match them as 
closely as possible. In section 3.4,

An organization object MUST always have at least one associated status 
value. Status values can be set only by the client that sponsors an 
organization object and by the server on which the object resides. A 
client can change the status of an organization object using the EPP 
 command. Each status value MAY be accompanied by a string 
of human-readable text that describes the rationale for the status 
applied to the object. 

A client MUST NOT alter status values set by the server. A server 
MAY alter or override status values set by a client, subject to local 
server policies. The status of an object MAY change as a result of 
either a client-initiated transform command or an action performed by 
a server operator.

Status values that can be added or removed by a client 

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Hi James,
Thanks for your further suggestions. I'll include them in the updated version.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-11-02 20:25
To: ka...@mit.edu; zhoulin...@cnnic.cn
CC: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be; i...@ietf.org; 
regext@ietf.org; draft-ietf-regext-org-...@ietf.org
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
I believe that we need to ensure that the 1-on-1 organization role mapping is 
consistently defined in the draft.  The definition of the "role" attribute, the 
possible value can be referenced in section 7.3, and the relationship between 
the organization id and the role should certainly be defined in section 3.1.  
The definition in 3.1 can be referenced in the create (4.2.1) and info (4.1.2), 
as in "One or more  elements that contain the identifier of the 
organization, as defined in [section 3.1]."  The update (4.2.5) is a little bit 
more complex to provide clarity on the behavior of the , 
 and the .  The following bullet could be removed from 
the update (4.2.5):
 
One or more  elements that contain the identifier of
the organization.  The "role" attribute is used to represent the
relationship that the organization has to the object.  See
Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
 
The reference to the  child elements and the expected behavior can 
be embedded under the definition of the , , and 
 elements, such as:
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that add non-existent organization roles 
to the object.  The  element MUST have a non-empty organization 
identifier value.  The server SHOULD validate that the  element role 
does not exist.  
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that remove organization roles from the 
object.  The  element MAY have an empty organization identifier 
value.  The server SHOULD validate the existence of the  element 
role and the organization identifier if provided.  
 
   o  An OPTIONAL  element that one or more  elements, 
as defined in [section 3.1], that change organization role identifiers for the 
object.  The existing organization identifier value will be replaced for the 
defined role.  The server SHOULD validate the existence of the  
element role. 
  
—
JG
 
 
 
James Gould
Distinguished Engineer
jgo...@verisign.com
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190
 
Verisign.com <http://verisigninc.com/> 
 
On 11/1/18, 6:29 PM, "regext on behalf of Benjamin Kaduk" 
 wrote:
 
    On Thu, Nov 01, 2018 at 11:28:10AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> I found that following sections may be the proper place to restrict the 
1-to-1 mapping. I think we can have restrictions in section 3.1 only or in 
3.1&4.2.1&4.2.5. I've not decided which one is better and hope to have others' 
suggestions.

I'd be happy to hear others' suggestions as well.  I don't have a strong
preference, but if forced to choose would put text in all three places.
(That is, others should feel free to choose "just section 3.1" and not
force me to choose, if they want.)

Thanks for putting together the proposals,

Benjamin

> 1. In section 3.1 Organization Identifier, add sentences at the end of 
this paragraph.
> A "role" attribute is used to represent the relationship that the 
organization has to the EPP object. Any given object MUST have at most one 
associated organization ID for any given role value.
> 
> 2. In section 4.2.1,
> One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values.
> 
> 3. In section 4.2.5
> One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values. 
> 
> If we have the restrictions, the 1-to-multiple mapping cases are not 
necessary to be specified in this document.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Benjamin Kaduk
> Date: 2018-10-31 20:43
> To: Linlin Zhou
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; 
draft-ietf-regext-org-ext
    > Subject: Re: [regext] Benjamin Kaduk'

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
I have confirmed with others about this wording. Your understanding is right 
that "service message" means using the  mechanism. So I suggest changing 
the text in section 4.3 like,
The server operator reviews the request offline, and MUST inform the client of 
the outcome of the review either by queuing a service message for retrieval via 
the  command and MAY use an out-of-band mechanism to inform the client of 
the outcome.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-11-01 10:57
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
I re-read the two paragraphs again and again. And I think I have the thought in 
mind that "service message" may be the key words to make you confused. 
In section 4.2, "the client MUST be notified using a service message", this 
"service message" has a relatively broad meaning, that it means the in-band or 
out-or-band service message. And "MUST" means you must send the message whether 
online or offline to the client.
If the above understanding is proper, In section 4.3 "either by queuing a 
service message for retrieval via the  command...", this "service 
message" is not specified for  excusively. 
Of course, I'll try to confirm with other EPP experts in parallel.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 13:45
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 

> > --
> > COMMENT:
> > --
> > Section 4.3
> > 
> >The status of the organization object after returning this response
> >MUST include "pendingCreate".  The server operator reviews the
> >request offline, and informs the client of the outcome of the review
> >either by queuing a service message for retrieval via the 
> >command or by using an out-of-band mechanism to inform the client of
> >the request.
> >  
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> >  [Linlin] This mechanism is supported in section 2.9.2.3 of RFC5730. 
> > So this is a easy and convinient way to inform the clients.
>  
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y".  The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can 
> have two choices to inform the result by  of EPP command or by 
> out-of-band actions. The following  response is an example using  
> mechanism. Of course you can also send an email to to contact of the 
> organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
> 
 
Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:
 
   Once
   the action has been completed, the client MUST be notified using a
   service message that the action has been completed and that the
   status of the object has changed.  Other notification methods MAY be
   used in addition to the required service message..
 
The text here in Section 4.3 says:
 
   The status of the organization object after returning this response
   MUST include "pendingCreate".  The server operator reviews the
   request offline, and informs the client of the outcome of the review
   either by queuing a service message for retrieval via the 
   command or by using an out-of-band mechanism to inform the client of
   the request.
 
which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.
 
My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead".  An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.

[Linlin] I can understand your concerns now. I think I had better propose a 
thread and ask the author or other EPP experts for confirmation. Once I get the 
feedback, I'll have a response. Thank you.
 

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Dear Benjamin,
James provided his suggestions and I'd like to include them in the updated 
text. I think this is the last issue we have and please see if these changes 
workable for you.

1. In section 3.1 Organization Identifier, add sentences at the end of this 
paragraph. 
A "role" attribute is used to represent the relationship that the organization 
has to the EPP object. Any given object MUST have at most one associated 
organization ID for any given role value. 

2. In section 4.1.2,
Zero or more  elements are allowed that contain the identifier of 
the organization, as defined in [section 3.1]. The "role" attribute is used to 
represent the relationship that the organization has to the object. See Section 
7.3 in [ID.draft-ietf-regext-org] for a list of values.

3. In section 4.2.1, 
One or more  elements that contain the identifier of the 
organization, as defined in [section 3.1]. The "role" attribute is used to 
represent the relationship that the organization has to the object. See Section 
7.3 in [ID.draft-ietf-regext-org] for a list of values. 

4. In section 4.2.5,
 o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that add non-existent organization roles 
to the object. The  element MUST have a non-empty organization 
identifier value.  The server SHOULD validate that the  element role 
does not exist. 
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that remove organization roles from the 
object. The  element MAY have an empty organization identifier 
value.  The server SHOULD validate the existence of the  element 
role and the organization identifier if provided. 
 
   o  An OPTIONAL  element that one or more  elements, 
as defined in [section 3.1], that change organization role identifiers for the 
object. The existing organization identifier value will be replaced for the 
defined role.  The server SHOULD validate the existence of the  
element role. 

At least one ,  or  element MUST be 
provided. The ,  and  elements contain the 
following child element:

o One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. Any given object MUST have at most one 
associated organization ID for any given role value. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-11-06 09:18
To: jgould; ka...@mit.edu
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
Hi James,
Thanks for your further suggestions. I'll include them in the updated version.

Regards,
Linlin


zhoulin...@cnnic.cn
 
From: Gould, James
Date: 2018-11-02 20:25
To: ka...@mit.edu; zhoulin...@cnnic.cn
CC: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be; i...@ietf.org; 
regext@ietf.org; draft-ietf-regext-org-...@ietf.org
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
I believe that we need to ensure that the 1-on-1 organization role mapping is 
consistently defined in the draft.  The definition of the "role" attribute, the 
possible value can be referenced in section 7.3, and the relationship between 
the organization id and the role should certainly be defined in section 3.1.  
The definition in 3.1 can be referenced in the create (4.2.1) and info (4.1.2), 
as in "One or more  elements that contain the identifier of the 
organization, as defined in [section 3.1]."  The update (4.2.5) is a little bit 
more complex to provide clarity on the behavior of the , 
 and the .  The following bullet could be removed from 
the update (4.2.5):
 
One or more  elements that contain the identifier of
the organization.  The "role" attribute is used to represent the
relationship that the organization has to the object.  See
Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
 
The reference to the  child elements and the expected behavior can 
be embedded under the definition of the , , and 
 elements, such as:
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that add non-existent organization roles 
to the object.  The  element MUST have a non-empty organization 
identifier value.  The server SHOULD validate that the  element role 
does not exist.  
 
   o  An OPTIONAL  element that contains one or more  
elements, as defined in [section 3.1], that remove organization roles from the 
object.  The  element MAY have an empty organization identifier 
value.  The server SHOULD validate the existence of the  element 
role and the organization identifier if provided.  
 
   o  An OPTIONAL  element that one or more  elements, 
as

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Linlin Zhou]

Hin Benjamin,
Thanks for your text. It looks good.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-11-13 03:40
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-11: (with COMMENT)
Hi Linlin,
 
On Mon, Nov 12, 2018 at 09:11:59AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> I have confirmed with others about this wording. Your understanding is right 
> that "service message" means using the  mechanism. So I suggest 
> changing the text in section 4.3 like,
> The server operator reviews the request offline, and MUST inform the client 
> of the outcome of the review either by queuing a service message for 
> retrieval via the  command and MAY use an out-of-band mechanism to 
> inform the client of the outcome.
 
Thanks for checking with the other experts; it's good to get this nailed
down!
 
I would suggest not using RFC 2119 normative language for the MUST, since
that would be duplicating a normative requirement from Section 4.2, and we
usually try to only have normative requirements listed once (to avoid the
risk of two being in conflict with each other).  So maybe:
 
  The server operator reviews the request offline, and informs the client of
  the outcome of the review by queuing a service message for retrieval via
  the  command; it MAY additionally  use an out-of-band mechanism to
  inform the client of the outcome.
 
 
-Benjamin
 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Linlin Zhou
> Date: 2018-11-01 10:57
> To: Benjamin Kaduk
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
> Subject: Re: [regext] Benjamin Kaduk's No Objection on 
> draft-ietf-regext-org-11: (with COMMENT)
> Dear Benjamin,
> I re-read the two paragraphs again and again. And I think I have the thought 
> in mind that "service message" may be the key words to make you confused. 
> In section 4.2, "the client MUST be notified using a service message", this 
> "service message" has a relatively broad meaning, that it means the in-band 
> or out-or-band service message. And "MUST" means you must send the message 
> whether online or offline to the client.
> If the above understanding is proper, In section 4.3 "either by queuing a 
> service message for retrieval via the  command...", this "service 
> message" is not specified for  excusively. 
> Of course, I'll try to confirm with other EPP experts in parallel.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Linlin Zhou
> Date: 2018-10-31 13:45
> To: Benjamin Kaduk
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
> Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on 
> draft-ietf-regext-org-11: (with COMMENT)
> Dear Benjamin,
> Please see my feedbacks below.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> 
> > > --
> > > COMMENT:
> > > --
> > > Section 4.3
> > > 
> > >The status of the organization object after returning this response
> > >MUST include "pendingCreate".  The server operator reviews the
> > >request offline, and informs the client of the outcome of the review
> > >either by queuing a service message for retrieval via the 
> > >command or by using an out-of-band mechanism to inform the client of
> > >the request.
> > >  
> > > I don't think the "either" is appropriate; the earlier text *requires* the
> > > service message, and allows for additional optional notification
> > > mechanisms.
> > >  [Linlin] This mechanism is supported in section 2.9.2.3 of 
> > > RFC5730. So this is a easy and convinient way to inform the clients.
> >  
> > I'm saying that the choice for the server is not "do X or do Y", it's: "do
> > X, then either do Y or don't do Y".  The word "either" here implies that it
> > is sometimes acceptable to not do X (where X is the queuing of the service
> > message).
> > [Linlin] In my understanding, I think the text means do X or do Y. You can 
> > have two choices to inform the result by  of EPP command or by 
> > out-of-band actions. The following  response is an example using 
> >  mechanism. Of course you can also send an email to to contact of the 
> > organization.
> > The text is consistent with EPP RFCs. Maybe we can ask the author to 
> > co

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Hi Benjamin,
Sorry that I forgot your email is text/plain.
Since we'v e already define "one or more  elements" in each 
,  and  element. So the following text 
seems a little duplicated and will be removed. I add the text strikethrough and 
you may not find that.

The ,  and  elements contain the following 
child element:
 o One or more  elements that contain the identifier of the 
organization. The "role" attribute is used to represent the relationship that 
the organization has to the object. See Section 7.3 in 
[ID.draft-ietf-regext-org] for a list of values.

This bullet will be removed from section 4.2.5. (May last email add one more 
sentence "Any given object MUST have at most one associated organization ID for 
any given role value" by mistake and this should not exist). How about changing 
like this?

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-11-13 03:48
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
Hi Linlin,
 
On Mon, Nov 12, 2018 at 11:15:24AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> James provided his suggestions and I'd like to include them in the updated 
> text. I think this is the last issue we have and please see if these changes 
> workable for you.
 
I think this looks good, thank you!  Just one minor thing (in the same vein
as my comment just now on the companion document)...
 
> 1. In section 3.1 Organization Identifier, add sentences at the end of this 
> paragraph. 
> A "role" attribute is used to represent the relationship that the 
> organization has to the EPP object. Any given object MUST have at most one 
> associated organization ID for any given role value. 
> 
> 2. In section 4.1.2,
> Zero or more  elements are allowed that contain the identifier of 
> the organization, as defined in [section 3.1]. The "role" attribute is used 
> to represent the relationship that the organization has to the object. See 
> Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
> 
> 3. In section 4.2.1, 
> One or more  elements that contain the identifier of the 
> organization, as defined in [section 3.1]. The "role" attribute is used to 
> represent the relationship that the organization has to the object. See 
> Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 
> 
> 4. In section 4.2.5,
>  o  An OPTIONAL  element that contains one or more  
> elements, as defined in [section 3.1], that add non-existent organization 
> roles to the object. The  element MUST have a non-empty 
> organization identifier value.  The server SHOULD validate that the 
>  element role does not exist. 
>  
>o  An OPTIONAL  element that contains one or more  
> elements, as defined in [section 3.1], that remove organization roles from 
> the object. The  element MAY have an empty organization identifier 
> value.  The server SHOULD validate the existence of the  element 
> role and the organization identifier if provided. 
>  
>o  An OPTIONAL  element that one or more  elements, 
> as defined in [section 3.1], that change organization role identifiers for 
> the object. The existing organization identifier value will be replaced for 
> the defined role.  The server SHOULD validate the existence of the 
>  element role. 
> 
> At least one ,  or  element MUST be 
> provided. The ,  and  elements contain 
> the following child element:
> 
> o One or more  elements that contain the identifier of the 
> organization. The "role" attribute is used to represent the relationship that 
> the organization has to the object. Any given object MUST have at most one 
> associated organization ID for any given role value. See Section 7.3 in 
> [ID.draft-ietf-regext-org] for a list of values.
 
... this MUST duplicates the requirement from Section 3.1; it could instead
be "Any given object has at most one [...]", optionally with a reference up
to Section 3.1.
 
-Benjamin
 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Linlin Zhou
> Date: 2018-11-06 09:18
> To: jgould; ka...@mit.edu
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
> Subject: Re: [regext] Benjamin Kaduk's Discuss on 
> draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
> Hi James,
> Thanks for your further suggestions. I'll include them in the updated version.
> 
> Regards,
> Linlin
> 
> 
> zhoulin...@cnnic.cn
>  
> From: Gould, James
> Date: 2018-11-02 20:25
> To: ka...@mit.edu; zhoulin...@cnnic.cn
> CC: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be; i...@ietf.org; 
> regex

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

[Linlin Zhou]

Hi Benjamin,
I think the last issue was clarified as well. I will settle down to update the 
drafts to address all the comments. Thanks for your review and comments.

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-11-13 23:06
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: 
(with DISCUSS and COMMENT)
Hi Linlin,
 
I likewise forgot to look at the list archives for the HTML version.
The proposed changes (from
https://www.ietf.org/mail-archive/web/regext/current/msg01984.html) look
good to me.
 
Thanks,
 
Benjamin
 
On Tue, Nov 13, 2018 at 09:28:34AM +0800, Linlin Zhou wrote:
> Hi Benjamin,
> Sorry that I forgot your email is text/plain.
> Since we'v e already define "one or more  elements" in each 
> ,  and  element. So the following text 
> seems a little duplicated and will be removed. I add the text strikethrough 
> and you may not find that.
> 
> The ,  and  elements contain the 
> following child element:
>  o One or more  elements that contain the identifier of the 
> organization. The "role" attribute is used to represent the relationship that 
> the organization has to the object. See Section 7.3 in 
> [ID.draft-ietf-regext-org] for a list of values.
> 
> This bullet will be removed from section 4.2.5. (May last email add one more 
> sentence "Any given object MUST have at most one associated organization ID 
> for any given role value" by mistake and this should not exist). How about 
> changing like this?
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Benjamin Kaduk
> Date: 2018-11-13 03:48
> To: Linlin Zhou
> CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
> Subject: Re: [regext] Benjamin Kaduk's Discuss on 
> draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
> Hi Linlin,
>  
> On Mon, Nov 12, 2018 at 11:15:24AM +0800, Linlin Zhou wrote:
> > Dear Benjamin,
> > James provided his suggestions and I'd like to include them in the updated 
> > text. I think this is the last issue we have and please see if these 
> > changes workable for you.
>  
> I think this looks good, thank you!  Just one minor thing (in the same vein
> as my comment just now on the companion document)...
>  
> > 1. In section 3.1 Organization Identifier, add sentences at the end of this 
> > paragraph. 
> > A "role" attribute is used to represent the relationship that the 
> > organization has to the EPP object. Any given object MUST have at most one 
> > associated organization ID for any given role value. 
> > 
> > 2. In section 4.1.2,
> > Zero or more  elements are allowed that contain the identifier 
> > of the organization, as defined in [section 3.1]. The "role" attribute is 
> > used to represent the relationship that the organization has to the object. 
> > See Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.
> > 
> > 3. In section 4.2.1, 
> > One or more  elements that contain the identifier of the 
> > organization, as defined in [section 3.1]. The "role" attribute is used to 
> > represent the relationship that the organization has to the object. See 
> > Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 
> > 
> > 4. In section 4.2.5,
> >  o  An OPTIONAL  element that contains one or more  
> > elements, as defined in [section 3.1], that add non-existent organization 
> > roles to the object. The  element MUST have a non-empty 
> > organization identifier value.  The server SHOULD validate that the 
> >  element role does not exist. 
> >  
> >o  An OPTIONAL  element that contains one or more 
> >  elements, as defined in [section 3.1], that remove organization 
> > roles from the object. The  element MAY have an empty 
> > organization identifier value.  The server SHOULD validate the existence of 
> > the  element role and the organization identifier if provided. 
> >  
> >o  An OPTIONAL  element that one or more  
> > elements, as defined in [section 3.1], that change organization role 
> > identifiers for the object. The existing organization identifier value will 
> > be replaced for the defined role.  The server SHOULD validate the existence 
> > of the  element role. 
> > 
> > At least one ,  or  element MUST be 
> > provided. The ,  and  elements contain 
> > the following child element:
> > 
> > o One or more  elements that contain the identifier of the 
> > organization. The "role" attribute is used to repr

[regext] Fw: I-D Action: draft-ietf-regext-org-12.txt

[Linlin Zhou]

Dear all,
The new version of org and org-ext have been posted to address the comments. 
Please review. Thanks.

Regards,
Linlin


Linlin Zhou
 
From: internet-drafts
Date: 2018-11-30 10:23
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-12.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Extensible Provisioning Protocol (EPP) Organization 
Mapping
Authors : Linlin Zhou
  Ning Kong
  Guiqing Zhou
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-12.txt
Pages   : 47
Date: 2018-11-29
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of organization objects
   stored in a shared central repository.  Specified in Extensible
   Markup Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of organizations.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-12
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-12
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-12
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fw: I-D Action: draft-ietf-regext-org-ext-10.txt

[Linlin Zhou]

Dear all,
The new version of org and org-ext have been posted to address the comments. 
Please review. Thanks.

Regards,
Linlin


Linlin Zhou
 
From: internet-drafts
Date: 2018-11-30 10:29
To: i-d-annou...@ietf.org
CC: regext
Subject: [regext] I-D Action: draft-ietf-regext-org-ext-10.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.
 
Title   : Organization Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Linlin Zhou
  Ning Kong
  Junkai Wei
  Jiankang Yao
  James Gould
Filename: draft-ietf-regext-org-ext-10.txt
Pages   : 25
Date: 2018-11-29
 
Abstract:
   This document describes an extension to Extensible Provisioning
   Protocol (EPP) object mappings, which is designed to support
   assigning an organization to any existing object (domain, host,
   contact) as well as any future objects.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-org-ext-10
https://datatracker.ietf.org/doc/html/draft-ietf-regext-org-ext-10
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-org-ext-10
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)

[Linlin Zhou]

Dear Scott,
Thanks for your comments. Please review if the following changes are workable 
for you.

In the business model of domain registration, we usually have three roles of 
entities: a registrant, a registrar and a registry, as defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. There may be other roles of entities 
involved in the domain registration process, such as resellers, DNS operators 
in section 9 of [draft-ietf-dnsop-terminology-bis], privacy proxies, etc.

A domain reseller is an individual or a company that acts as an agent for 
accredited registrars. DNS operator is defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. A privacy proxy is an entity used for 
domain registrations to protect the private information of the individuals and 
organizations. These kind of entities are defined as "organizations" with 
different role types in this document.

Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-11-30 20:15
To: 'ka...@mit.edu'; 'i...@ietf.org'
CC: 'regext-cha...@ietf.org'; 'pieter.vandepi...@dnsbelgium.be'; 
'regext@ietf.org'; 'draft-ietf-regext-org-...@ietf.org'
Subject: RE: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-ext-10: (with COMMENT)
> -Original Message-
> From: regext  On Behalf Of Benjamin Kaduk
> Sent: Thursday, November 29, 2018 10:07 PM
> To: The IESG 
> Cc: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be;
> regext@ietf.org; draft-ietf-regext-org-...@ietf.org
> Subject: [EXTERNAL] [regext] Benjamin Kaduk's No Objection on draft-ietf-
> regext-org-ext-10: (with COMMENT)
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-org-ext-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for addressing my Discuss points!
>
> [Original Comment section preserved below]
>
> Section 1
>
>In the business model of domain registration, we usually have 3 roles
>of entities: a registrant, a registrar and a registry.  There may be
>other roles of entities involved in the domain registration process
>which are not formally defined, such as resellers, DNS service
>operators, privacy proxies, etc.
>
> nit: Perhaps I am misreading, but are we not going to formally define
> these entities in the next paragraph (in which case "yet" might be worth
> adding)?
 
If definitions are needed, it may make sense to cite those described in 
draft-ietf-dnsop-terminology-bis. The Datatracker says it's in the RFC Editor's 
AUTH48 state, so it should be available as an RFC in a matter of days.
 
Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-ext-10: (with COMMENT)

[Linlin Zhou]

Dear Benjamin,
As some definitions are specified in the draft-ietf-dnsop-terminology-bis, I 
suggest removing "which are not formally defined" and making following changes 
in the first section. Does that work for you?

In the business model of domain registration, we usually have three roles of 
entities: a registrant, a registrar and a registry, as defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. There may be other roles of entities 
involved in the domain registration process, such as resellers, DNS operators 
in section 9 of [draft-ietf-dnsop-terminology-bis], privacy proxies, etc. 

A domain reseller is an individual or a company that acts as an agent for 
accredited registrars. DNS operator is defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. A privacy proxy is an entity used for 
domain registrations to protect the private information of the individuals and 
organizations. These kind of entities are defined as "organizations" with 
different role types in this document.

Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-12-03 21:12
To: 'zhoulin...@cnnic.cn'; 'ka...@mit.edu'; 'i...@ietf.org'
CC: 'regext-cha...@ietf.org'; 'pieter.vandepi...@dnsbelgium.be'; 
'regext@ietf.org'; 'draft-ietf-regext-org-...@ietf.org'
Subject: Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-ext-10: (with COMMENT)
Works for me if it addresses Ben’s comment.
 
Scott
 
From: regext  On Behalf Of Linlin Zhou
Sent: Monday, December 03, 2018 3:42 AM
To: Hollenbeck, Scott ; Benjamin Kaduk 
; iesg 
Cc: regext-chairs ; Pieter Vandepitte 
; regext ; 
draft-ietf-regext-org-ext 
Subject: [EXTERNAL] Re: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-ext-10: (with COMMENT)
 
Dear Scott,
Thanks for your comments. Please review if the following changes are workable 
for you.


In the business model of domain registration, we usually have three roles of 
entities: a registrant, a registrar and a registry, as defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. There may be other roles of entities 
involved in the domain registration process, such as resellers, DNS operators 
in section 9 of [draft-ietf-dnsop-terminology-bis], privacy proxies, etc.


A domain reseller is an individual or a company that acts as an agent for 
accredited registrars. DNS operator is defined in section 9 of 
[draft-ietf-dnsop-terminology-bis]. A privacy proxy is an entity used for 
domain registrations to protect the private information of the individuals and 
organizations. These kind of entities are defined as "organizations" with 
different role types in this document.
 
Regards,
Linlin


Linlin Zhou
 
From: Hollenbeck, Scott
Date: 2018-11-30 20:15
To: 'ka...@mit.edu'; 'i...@ietf.org'
CC: 'regext-cha...@ietf.org'; 'pieter.vandepi...@dnsbelgium.be'; 
'regext@ietf.org'; 'draft-ietf-regext-org-...@ietf.org'
Subject: RE: [regext] Benjamin Kaduk's No Objection on 
draft-ietf-regext-org-ext-10: (with COMMENT)
> -Original Message-
> From: regext  On Behalf Of Benjamin Kaduk
> Sent: Thursday, November 29, 2018 10:07 PM
> To: The IESG 
> Cc: regext-cha...@ietf.org; pieter.vandepi...@dnsbelgium.be;
> regext@ietf.org; draft-ietf-regext-org-...@ietf.org
> Subject: [EXTERNAL] [regext] Benjamin Kaduk's No Objection on draft-ietf-
> regext-org-ext-10: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-org-ext-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my Discuss points!
> 
> [Original Comment section preserved below]
> 
> Section 1
> 
>In the business model of domain registration, we usually have 3 roles
>of entities: a registrant, a registrar and a registry.  There may be
>other roles of entities involved in the domain registration process
>which are not formally defined, such as resellers, DNS service
>operators, privacy proxies, etc.
> 
> nit: Perhaps I am misreading, but are we not going to formally define
> these entities in the next paragraph (in which case "yet