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 <orgext:id> 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 <orgext:id> 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 <orgext:add> element that contains one or more <orgext:id> > elements, as defined in [section 3.1], that add non-existent organization > roles to the object. The <orgext:id> element MUST have a non-empty > organization identifier value. The server SHOULD validate that the > <orgext:id> element role does not exist. > > o An OPTIONAL <orgext:rem> element that contains one or more <orgext:id> > elements, as defined in [section 3.1], that remove organization roles from > the object. The <orgext:id> element MAY have an empty organization identifier > value. The server SHOULD validate the existence of the <orgext:id> element > role and the organization identifier if provided. > > o An OPTIONAL <orgext:chg> element that one or more <orgext:id> 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 > <orgext:id> element role. > > At least one <orgext:add>, <orgext:rem> or <orgext:chg> element MUST be > provided. The <orgext:add>, <orgext:rem> and <orgext:chg> elements contain > the following child element: > > o One or more <orgext:id> 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; > 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 <orgext:id> 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 <orgext:add>, <orgext:rem> and the <orgext:chg>. The following bullet > could be removed from the update (4.2.5): > > One or more <orgext:id> 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 <orgext:id> child elements and the expected behavior can > be embedded under the definition of the <orgext:add>, <orgext:rem>, and > <orgext:chg> elements, such as: > > o An OPTIONAL <orgext:add> element that contains one or more <orgext:id> > elements, as defined in [section 3.1], that add non-existent organization > roles to the object. The <orgext:id> element MUST have a non-empty > organization identifier value. The server SHOULD validate that the > <orgext:id> element role does not exist. > > o An OPTIONAL <orgext:rem> element that contains one or more <orgext:id> > elements, as defined in [section 3.1], that remove organization roles from > the object. The <orgext:id> element MAY have an empty organization > identifier value. The server SHOULD validate the existence of the > <orgext:id> element role and the organization identifier if provided. > > o An OPTIONAL <orgext:chg> element that one or more <orgext:id> 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 > <orgext:id> 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" > <regext-boun...@ietf.org on behalf of ka...@mit.edu> 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 <orgext:id> 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 <orgext:id> 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 <orgext:id> elements in <create>? (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 > <update> > > description that the semantics of <orgext:chg> 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 > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
