> -----Original Message-----
> From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin <gal...@elistx.com>; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
>
> Il 02/10/2020 22:15, James Galvin ha scritto:
> > The WGLC for this document was scheduled to end today. While there is
> > support to move the document forward there is one minor comment that
> > has been raised during the last call.
> >
> > The chairs would like to hear from other working group members as to
> > what to do with this comment. Rather than close the last call and
> > risk another last call, we are extending this last call for another
> > week. If we can come to a consensus as to how to proceed before the
> > end of last call than the document can stay on track to be submitted
> > to the IESG after the last call.
> >
> > The WG last call will end at close of business on Friday, 9 October 2020.
> >
> >
> > Here are the comments as seen on the mailing list. Please respond
> > with your suggestions regarding these two comments.
> >
> >
> > James Gould:
> >
> > Yes, lumping the registrar object with the contact object under a
> > single RDAP entity object interface is the rub. We solved the problem
> > in the RDAP Profile, by supporting entity lookup by IANA ID (number)
> > and registrar name (string) for the registrar objects, and by ROID
> > (“((\w|_){1,80}-\w{1,8}") for the contact objects. Where there is
> > overlap, which is registrar name (string) and ROID
> > ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence. My
> > recommendation is to provide guidance in the section 3.1.5 "Entity
> > Path Segment Specification" for this real world case:
> >
> > The <handle> parameter represents an entity (such as a contact,
> > registrant, or registrar) identifier whose syntax is specific to the
> > registration provider. For example, for some DNRs, contact
> > identifiers are specified in [RFC5730] and [RFC5733], and registrar
> > identifiers are specified using the IANA Registrar ID assigned by
> > ICANN. The server SHOULD define a scheme for the <handle> parameter
> > to differentiate between the supported entity object types (e.g.,
> > contact and registrar), such as using different <handle> formats,
> > using a <handle> precedence order, or a combination of formats and
> > precedence order.
> >
> > The SHOULD could be a MUST, but the point is to provide guidance to
> > implementers of the protocol.
> >
> > Two responses have been offered:
> >
> > Jasdip Singh response:
> >
> > One thought is if it could be in the RDAP profile doc for the DNRs
> > (https://secure-
> web.cisco.com/1_AKsyXhtRLN9h4LEAG65owtJMhHrfLUp94HAp7iv6U5KRK_-
> 2Mtzd56Rf4smGoyDJ4eiIqM3a4E73iWsnhGOX4YnFCyWF_xzCaslHxhJOxiqbH
> hiSRwAiyk8mMkECJoYKSlQ1kmb4u3-
> _sD2Be3SyrMHZApsS3iBtbY3MemXbSWSv4c6DFlq8sfMzGMjqy4PQekUbt9Lt
> HcNRfwPHXhN9IFFpecud-xKW8luC4RDIz7jmjeFU9N11h-
> lUPrhogswglEugCXCl95vnmjQ5lqytQ/https%3A%2F%2Fwww.icann.org%2Fre
> sources%2Fpages%2Frdap-operational-profile-2016-07-26-en).
> > That way no need to update the spec.
> >
> > James Gould response:
> >
> > The RDAP Profile is dependent on the RFC, so I wouldn't create a
> > circular dependency. My recommendation is to take the lessons learned
> > in implementing the RFC and provide guidance on how to handle it in
> > the RFC directly.
> >
> >
> The proposed update seems reasonable to me. However, we don't have to
> make assumptions regarding how handle is generated by RDAP servers. In
> my opinion, the document should simply give guidance to RDAP
> implementers about how to disambiguate cases where overlap may occur.
> Therefore, I would change the sentence as in the following:
>
> OLD
>
> The server SHOULD define a scheme
> for the <handle> parameter to differentiate
>
> NEW
>
> Where overlap may occur, the server SHOULD define a scheme for the
> <handle> parameter to differentiate
I'm still not comfortable with this. If we suggest that the server MUST or
SHOULD do something to define a scheme, we leave open the issue of how a client
discovers that scheme - and if we add a processing step to discover the scheme,
we've changed the protocol from the client's perspective. I still believe that
this is an issue best addressed in an implementation profile document and not
the protocol specification.
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
