Already done. On Wed, Oct 31, 2018 at 5:11 AM Adam Roach <a...@nostrum.com> 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 <zhoulin...@cnnic.cn> 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
