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 <jgo...@verisign.com> 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 <info> 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 <info> command has been processed successfully, the EPP
<resData> element MUST contain a child <org:infData> element that
identifies the organization namespace. The <org:infData> element
contains the following child elements:
[…]
o Zero or more <org:status> 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 <org:status> elements...” to
match the XML schema.
Ok
[Linlin] This was changed.
4.2.5. EPP <update> Command
[...]
Zero or more <org:role> 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 <secDNS:keyData> 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 -- <secDNS:flags>, <secDNS:protocol>, <secDNS:
alg>, and <secDNS:pubKey> -- 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
<org:type> 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 <org:type> 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 to remove a contact, I would also add these
instructies to parentId, voice, fax email and url:
An empty <org:___> 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 <contact:chg> sub-elements do have replace semantics
Existing sub-element data deleted first and then set with updated data.
<contact:postalInfo> types treated independently
Exclusion of a <contact:postalInfo> type does not implicitely delete it.
<contact:postalInfo> type deleted via empty element
<contact:postalInfo type=”int/> or <contact:postalInfo type=”loc”/>
The elements supported by the <org:add> and <org:rem> are the list elements
<org:contact>, <org:role>, and <org:status>. The individual attributes
(postalInfo can be considered two separate attributes “int” and “loc”) are
updated using the <org:chg>. Maybe the introduction sentence “An OPTIONAL
<org:chg> element containing the following element, where at least one child
element MUST be present”, can be revised to clarify how the simple elements and
complex child elements added, updated, or removed via the <org:chg> element.
How about something like “An OPTIONAL <org:chg> element used to add, update,
and delete non-list organization attributes. An empty <org:chg> sub-element
(<org:parentId>, <org:voice>, <org:fax>, <org:email>, and <org:url>,
<org:postalInfo> with “type” attribute) is used to remove it and a non-empty
sub-element is used to replace it. For the <org:postalInfo> complex
sub-element, the types (“int” and “loc”) are treated independently with replace
semantics, where the <org:postalInfo> sub-element data is deleted first and
then set with the update data. The <org:chg> element MUST contain one of the
following child elements:”.
There is one big item with my proposal in supporting the removal of the simple
<org:postalInfo> sub-elements using empty elements in that the XSD does not
support empty elements with the following type definitions:
parentId - eppcom:clIDType
<simpleType name="clIDType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="16"/>
</restriction>
</simpleType>
voice – org: e164Type
<complexType name="e164Type">
<simpleContent>
<extension base="org:e164StringType">
<attribute name="x" type="token" />
</extension>
</simpleContent>
</complexType>
<simpleType name="e164StringType">
<restriction base="token">
<pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?" />
<maxLength value="17" />
</restriction>
</simpleType>
fax – org:e164Type
Same as voice
email – eppcom:minTokenType
<simpleType name="minTokenType">
<restriction base="token">
<minLength value="1"/>
</restriction>
</simpleType>
url – anyURI
Does support empty element
The alternative is to make removal explicit with the <org:rem> element by
supporting a list of empty elements to remove instead of using the <org:chg>
element with empty elements. For example, the <org:rem> element can support
removing elements from the list attributes and can be used to remove the
non-list attributes with empty elements (<org:parentId>, <org:voice>,
<org:fax>, <org:email>, and <org:url>, <org:postalInfo> with “type” attribute).
This is different from the semantics for RFC 5733. If this is the case,
should the <org:add> element only be capable of adding list items or should it
be used to add non-existing attributes.
Thoughts?
To be honest, I think it is OK as it is now. An empty postalInfo to remove it,
otherwise, to update it, provide the complete contents of the postalInfo (if I
understand it well). It's pretty intuitive
[Linlin] So I'll keep it as it is now.
===
Shouldn't we have a section like RFC 5731, 5732, 5733 regarding offline review
of requested actions?
===
Yes, that makes sense.
[Linlin] A new section named "Offline Review of Requested Actions" with new
elements <org:id>, <org:paTRID> and <org:paDate> will be added.
===
Do we need to remove the Change Log section?
===
The change log will get removed prior to publication by the RFC Editor.
===
XSD maxOccurs opinion:
<element name="status"
type="org:statusType" maxOccurs="9"/>
Why 9? I would set this to unbounded. A client may send an org create with 10
times clientDeleteProbited. It should just work.
I thought the same thing, but if you do the math, the maximum number of unique
statuses is 9. The statuses are unique and there should be no duplicates. If
you look at the RFC 5733, the statuses are defined with a maximum, which is
being mirrored here based on the unique set of organization statuses.
I can live with a 9
===
XSD sequence anti pattern
we keep on copying old XML schema's, and hence, for data structures we keep on
using xsd:sequence (ordered) instead of xsd:choice. If order is not important
(which is the case in this draft and a lot of other RFCs), don't enforce it. It
makes implementation and testing often unnecessarily harder.
I don’t view the use of XSD sequence as an anti pattern. I believe the
sequence makes implementation and testing easier and not harder.
I'm trying to understand how it makes implementation and testing better. When
parsing XML without XML to object binding libraries?
===
Model issue: because org:name is part of org:postalInfo, and org:addr is also
part of org:postalInfo but required, it is impossible create an organization
with a name, but without address... I think this must be possible as this was
one of the first discussions in the mailing list: reseller in a separate object
vs. or simply add ID and name to a domain.
Proposal: move org:name to a higher level (it's not the name belonging to the
address of the org, but the name belonging to the org itself)
How about simply making the addr element in the org:postalInfoType optional
(minOccurs=”0”) and add OPTIONAL to the references to <org:addr> in the text?
This would be a huge improvement. @Linlin, can you change this in both XSD and
text?
[Linlin]
The XSD file will be updated <element name="addr" type="org:addrType"
minOccurs="0"/>, and add OPTIONAL in the text of <org:addr> reference.
Kind regards
Pieter
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
