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

Already done.
On Wed, Oct 31, 2018 at 5:11 AM Adam Roach <adam@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 <zhoulinlin@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
>
>