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 they are required or optional may be different in a create than in a 
info response. The attributes are duplicated in the other EPP RFCs (RFC 5731 – 
5733) for ease in implementation. Attempting to collapse the attributes will 
make it more dif

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] IANA Considerations for draft-ietf-regext-org and draft-ietf-regext-org-ext

[Hollenbeck, Scott]

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] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Mon, Oct 29, 2018 at 1:17 AM Linlin Zhou  wrote:

> 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.
>
>
I'm sorry, but this still isn't clear. Can you perhaps send some
pseudocode?

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



>
> --
> 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.
>
>
Then you should say so in the text.

>
>
>> 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.
>
>
Sorry, still not clear.

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

[regext] Secdir Last Call assignment: draft-ietf-regext-change-poll

[Valery Smyslov]

Reviewer: Valery Smyslov
Review result: Ready with Nits

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft defines an extension for an Extensible Provisioning Protocol (EPP, 
RFC 5730)
that allows servers to notify clients about operations which were not 
initiated by clients, but which modify state of client-sponsored objects.

The extension is defined using standard EPP mechanism for adding extensions,
so Security Considerations from RFC 5730 are applied and no new ones are added. 
Keeping long message queues consume server resources and can
potentially be a surface for DoS attack, however as far as I understand
unauthorized entities cannot cause server to perform actions resulted in 
operations on other clients' objects, so it seems that it is not a security 
issue here.
Nevertheless adding a few words that it is not a security issue would be 
helpful.

General comment not related to security. It seems to me that the protocol 
description
is inconsistent. The Introduction Section states, that this extension only 
extends 
the response to the EPP  command. However, Section 3 of this 
specification, 
which describes the EPP Command Mapping, extends only the response 
to the EPP  command with poll message, and the  command is not 
mentioned 
there at all. I'm not familiar with the EPP protocol, but I believe that  
and  
are different commands, so unless I've missed something, it seems that the 
protocol 
description is inconsistent (or incomplete). Since it is not related to 
security, 
I think the document is Ready (from security perspective), but this 
inconsistency 
must either be fixed or some clarification be provided.


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

Re: [regext] Secdir Last Call assignment: draft-ietf-regext-change-poll

[Gould, James]

Thank you for the review and feedback.  I can understand the confusion if 
you're not familiar with the EPP protocol.  I attempt to clarify things below.  

The info command and the poll command are different commands, but where the 
confusion lies is with the response.  A poll response can be any EPP response, 
since the information for a poll response is built into the general EPP 
response with the  element (section 2.6 of RFC 5730), so any EPP response 
"has a" relationship with the poll queue information.  A concrete EPP response, 
which in this case is an info response, extends ("is a" relationship) the EPP 
general response, so a concrete EPP response can be used in the response to an 
EPP command or an EPP poll command.  In the case of the 
draft-ietf-regext-change-poll, it specifies the use of the info response of 
other EPP objects (e.g., domain in RFC 5731, host in RFC 5732, or contact in 
RFC 5733) with the Change Poll Extension that defines the server-side operation 
meta-data of what, when, who, and why.  A concrete example is the server adding 
a server status on a domain name, as defined in RFC 5731, where it can insert 
an EPP poll message in the form of a domain info response that includes the 
added server status, with the poll message  element populated, and with 
the Change Poll Extension added.  The responses of 
draft-ietf-regext-change-poll are associated with poll responses, where the 
concrete poll responses used are info responses with the Change Poll extension. 
 A client would request the poll message using the EPP RFC 5730 poll command 
and would receive the poll message in the form of an info response, with the 
poll queue information included, and with the Change Poll extension.

I hope this helps.   

Thanks,
  
—
 
JG



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

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

Verisign.com  

On 10/29/18, 9:36 AM, "Valery Smyslov"  wrote:

Reviewer: Valery Smyslov
Review result: Ready with Nits

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft defines an extension for an Extensible Provisioning Protocol 
(EPP, RFC 5730)
that allows servers to notify clients about operations which were not 
initiated by clients, but which modify state of client-sponsored objects.

The extension is defined using standard EPP mechanism for adding extensions,
so Security Considerations from RFC 5730 are applied and no new ones are 
added. 
Keeping long message queues consume server resources and can
potentially be a surface for DoS attack, however as far as I understand
unauthorized entities cannot cause server to perform actions resulted in 
operations on other clients' objects, so it seems that it is not a security 
issue here.
Nevertheless adding a few words that it is not a security issue would be 
helpful.

General comment not related to security. It seems to me that the protocol 
description
is inconsistent. The Introduction Section states, that this extension only 
extends 
the response to the EPP  command. However, Section 3 of this 
specification, 
which describes the EPP Command Mapping, extends only the response 
to the EPP  command with poll message, and the  command is not 
mentioned 
there at all. I'm not familiar with the EPP protocol, but I believe that 
 and  
are different commands, so unless I've missed something, it seems that the 
protocol 
description is inconsistent (or incomplete). Since it is not related to 
security, 
I think the document is Ready (from security perspective), but this 
inconsistency 
must either be fixed or some clarification be provided.




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

Re: [regext] Secdir Last Call assignment: draft-ietf-regext-change-poll

[Valery Smyslov]

Hi James,

thank you for clarification. I presume all these things are clear for those who 
are familiar with EPP,
and probably most of potential readers of this document fall into this 
category, but if you can add short
explanation for the others it would be great. 

Regards,
Valery Smyslov.


> Thank you for the review and feedback.  I can understand the confusion if 
> you're not familiar with the EPP
> protocol.  I attempt to clarify things below.
> 
> The info command and the poll command are different commands, but where the 
> confusion lies is with the
> response.  A poll response can be any EPP response, since the information for 
> a poll response is built into the
> general EPP response with the  element (section 2.6 of RFC 5730), so 
> any EPP response "has a"
> relationship with the poll queue information.  A concrete EPP response, which 
> in this case is an info response,
> extends ("is a" relationship) the EPP general response, so a concrete EPP 
> response can be used in the response
> to an EPP command or an EPP poll command.  In the case of the 
> draft-ietf-regext-change-poll, it specifies the
> use of the info response of other EPP objects (e.g., domain in RFC 5731, host 
> in RFC 5732, or contact in RFC
> 5733) with the Change Poll Extension that defines the server-side operation 
> meta-data of what, when, who,
> and why.  A concrete example is the server adding a server status on a domain 
> name, as defined in RFC 5731,
> where it can insert an EPP poll message in the form of a domain info response 
> that includes the added server
> status, with the poll message  element populated, and with the Change 
> Poll Extension added.  The
> responses of draft-ietf-regext-change-poll are associated with poll 
> responses, where the concrete poll
> responses used are info responses with the Change Poll extension.  A client 
> would request the poll message
> using the EPP RFC 5730 poll command and would receive the poll message in the 
> form of an info response,
> with the poll queue information included, and with the Change Poll extension.
> 
> I hope this helps.
> 
> Thanks,
> 
> —
> 
> JG
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> 
> On 10/29/18, 9:36 AM, "Valery Smyslov"  wrote:
> 
> Reviewer: Valery Smyslov
> Review result: Ready with Nits
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This draft defines an extension for an Extensible Provisioning Protocol 
> (EPP, RFC 5730)
> that allows servers to notify clients about operations which were not
> initiated by clients, but which modify state of client-sponsored objects.
> 
> The extension is defined using standard EPP mechanism for adding 
> extensions,
> so Security Considerations from RFC 5730 are applied and no new ones are 
> added.
> Keeping long message queues consume server resources and can
> potentially be a surface for DoS attack, however as far as I understand
> unauthorized entities cannot cause server to perform actions resulted in
> operations on other clients' objects, so it seems that it is not a 
> security issue here.
> Nevertheless adding a few words that it is not a security issue would be 
> helpful.
> 
> General comment not related to security. It seems to me that the protocol 
> description
> is inconsistent. The Introduction Section states, that this extension 
> only extends
> the response to the EPP  command. However, Section 3 of this 
> specification,
> which describes the EPP Command Mapping, extends only the response
> to the EPP  command with poll message, and the  command is 
> not mentioned
> there at all. I'm not familiar with the EPP protocol, but I believe that 
>  and 
> are different commands, so unless I've missed something, it seems that 
> the protocol
> description is inconsistent (or incomplete). Since it is not related to 
> security,
> I think the document is Ready (from security perspective), but this 
> inconsistency
> must either be fixed or some clarification be provided.
> 
> 
> 


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

Re: [regext] [Ext] regarding adopting new documents and milestones

[Adam Roach]

[as Area Director]

Hi!

While I appreciate that the proposal you've put forth is trying to 
ensure that popular or urgent work doesn't end up getting blocked on 
lower priority items (and pushed into other venues), we have pretty 
solid historical data that shows that the approach you're describing 
leads to very slow progress in moving documents towards publication. 
What's important to keep in mind is that the working group is entirely 
in charge of which milestones to add to its chartered work, and that 
it's possible to remove milestones if you later decide that you need the 
slot for something more important.


The chairs have been very good about working with the working group to 
actively manage which documents should become and stay milestones. As 
this active management approach has led to more regext documents 
reaching the "publication requested" state rather than fewer, it seems 
that it is more likely to stave off the need to publish mechanisms 
outside the IETF than the previous, lower-throughput approach.


/a


On 10/26/18 7:16 PM, Gustavo Lozano wrote:

Antoin, Jim, et.al.

My understanding of this message is that only a certain number of I-Ds will be 
allowed to be adopted as WG documents.

If my understanding is correct, I feel uncomfortable with defining a number, 
because it appears to exist a recent enthusiasm for creating I-Ds (probably 
related to the popularity of registration data privacy in several 
jurisdictions) and having an artificial gate could push authors and 
implementers to define the standards outside of the WG/IETF.

My preference is for allowing any I-D, that the WG believes that is a good fit, 
to be adopted. If a subset of the WG participants or non-participants want to 
get involved in the development of an I-D that is not part of the milestones, 
they should be free to do so, and the I-D should be allowed to reach RFC status 
based on the number of reviewers, running code and the last calls.

Regards,
Gustavo


-Original Message-
From: regext  On Behalf Of James Galvin
Sent: Friday, October 19, 2018 07:15
To: Registration Protocols Extensions 
Subject: [Ext] [regext] regarding adopting new documents and milestones

By now you should have seen the draft agenda for IETF103.  On it you will see 8
requests for adopting new documents as working group milestones.  The chairs
are concerned that we should not adopt quite that many new documents all at
once.

If you look at our current milestone list, there are 3 open milestones.
One of these (“EPP Domain Name Mapping Extension for Bundling
Registration”) we expect to close quite soon as the shepherd is actively
preparing the writeup.  This leaves us with 2 milestones we may wish to
reconsider whether to keep or not.

The chairs are proposing that the working group should not have more than 5
open milestones at a time.  We can discuss if that’s the right number but for
now we will use that as our starting point.

Given that two milestones will remain on our list we will only have room for 3
new documents to adopt.

We are asking the group to think about the following questions.

1. How many open milestones should we allow ourselves to have?

2. Do we want to reconsider any currently open milestones?

3. Of the 8 documents being proposed for adoption, which ones are the
priorities, i.e., the documents we want to adopt first?

The last item on our agenda is a discussion of our milestones.  We will use this
time to consider the questions listed above.

Please note, whatever priorities we create from this discussion will need to be
brought to the mailing list for final agreement.  We will follow that with a
separate individual request for adoption of each document selected by the
working group.

If you have any questions or comments please do respond to the list.

Thanks,

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



___
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)

[Benjamin Kaduk]

On Mon, Oct 29, 2018 at 09:55:22AM +0800, Linlin Zhou wrote:
> 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 
> > status means "status in

Re: [regext] [Ext] regarding adopting new documents and milestones

[Andrew Newton]

Perhaps priority should be given to those I-Ds with running code.

-andy
On Mon, Oct 29, 2018 at 12:41 PM Adam Roach  wrote:
>
> [as Area Director]
>
> Hi!
>
> While I appreciate that the proposal you've put forth is trying to ensure 
> that popular or urgent work doesn't end up getting blocked on lower priority 
> items (and pushed into other venues), we have pretty solid historical data 
> that shows that the approach you're describing leads to very slow progress in 
> moving documents towards publication. What's important to keep in mind is 
> that the working group is entirely in charge of which milestones to add to 
> its chartered work, and that it's possible to remove milestones if you later 
> decide that you need the slot for something more important.
>
> The chairs have been very good about working with the working group to 
> actively manage which documents should become and stay milestones. As this 
> active management approach has led to more regext documents reaching the 
> "publication requested" state rather than fewer, it seems that it is more 
> likely to stave off the need to publish mechanisms outside the IETF than the 
> previous, lower-throughput approach.
>
> /a
>
>
> On 10/26/18 7:16 PM, Gustavo Lozano wrote:
>
> Antoin, Jim, et.al.
>
> My understanding of this message is that only a certain number of I-Ds will 
> be allowed to be adopted as WG documents.
>
> If my understanding is correct, I feel uncomfortable with defining a number, 
> because it appears to exist a recent enthusiasm for creating I-Ds (probably 
> related to the popularity of registration data privacy in several 
> jurisdictions) and having an artificial gate could push authors and 
> implementers to define the standards outside of the WG/IETF.
>
> My preference is for allowing any I-D, that the WG believes that is a good 
> fit, to be adopted. If a subset of the WG participants or non-participants 
> want to get involved in the development of an I-D that is not part of the 
> milestones, they should be free to do so, and the I-D should be allowed to 
> reach RFC status based on the number of reviewers, running code and the last 
> calls.
>
> Regards,
> Gustavo
>
> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Friday, October 19, 2018 07:15
> To: Registration Protocols Extensions 
> Subject: [Ext] [regext] regarding adopting new documents and milestones
>
> By now you should have seen the draft agenda for IETF103.  On it you will see 
> 8
> requests for adopting new documents as working group milestones.  The chairs
> are concerned that we should not adopt quite that many new documents all at
> once.
>
> If you look at our current milestone list, there are 3 open milestones.
> One of these (“EPP Domain Name Mapping Extension for Bundling
> Registration”) we expect to close quite soon as the shepherd is actively
> preparing the writeup.  This leaves us with 2 milestones we may wish to
> reconsider whether to keep or not.
>
> The chairs are proposing that the working group should not have more than 5
> open milestones at a time.  We can discuss if that’s the right number but for
> now we will use that as our starting point.
>
> Given that two milestones will remain on our list we will only have room for 3
> new documents to adopt.
>
> We are asking the group to think about the following questions.
>
> 1. How many open milestones should we allow ourselves to have?
>
> 2. Do we want to reconsider any currently open milestones?
>
> 3. Of the 8 documents being proposed for adoption, which ones are the
> priorities, i.e., the documents we want to adopt first?
>
> The last item on our agenda is a discussion of our milestones.  We will use 
> this
> time to consider the questions listed above.
>
> Please note, whatever priorities we create from this discussion will need to 
> be
> brought to the mailing list for final agreement.  We will follow that with a
> separate individual request for adoption of each document selected by the
> working group.
>
> If you have any questions or comments please do respond to the list.
>
> Thanks,
>
> 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
>
>
> ___
> 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