Scott, >> 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.
I believe that providing guidance in the protocol to the real-world overlapping of entity handles (contact and registrar) as necessary. The protocol would have explicit language on how to handle the case of overlapping entity handles. A discovery mechanism is not needed, since we didn't have a need to create one based on the approach taken. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott" <regext-boun...@ietf.org on behalf of shollenbeck=40verisign....@dmarc.ietf.org> wrote: > -----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%2Fhttp://secure-web.cisco.com/1KzaMJBYCbHehlcyM7qgPzBHHaQvr1dOBGVjKZpsDWq867Y5KK33Xpj7gO1ijGMStZiT2-3TBK7ej3U5yYTxNbvIluknka0M48pQzXdUZwKvNgHeKhpieimICcERv8ytTgpOTh6oH_p_deFEo_xT15mJU5eJufBCSCEnu_AQMtR3VgaaURwLueY0Bw-Am4T5mb12dNiJHS_Uy6RpnXYUflqWBeQ0NCXczhOd7XkXyO62Kk1SHZ5UHdFFWrOFdBbuRuOkpX8FDJHhiWXx2xy2thQ/http%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://secure-web.cisco.com/14qQ5GBAbqizg1W93npsiyV-qaIPAEr0IPtYJq1e7X-_7EoaNxVfB1TEiGzncUFjJiWvcnx6HykFwrZ-ABrD6xiCsFOMEGvVa2nDcW_IEtcp3Kp7hIrt7QPfU1p8toWJrW6Cam0kzs62ESNznCXJSwbu2i9LvV_B2lJ_5iFZL_W3yetKjwXg0uiEC8RQ26Ce90KoEXMuk-nZ5uY-UUHWe1MXXF9N0PIwrFts920hzq-qzWa1SHCEGSw3o0Odax04AFTW15t-zXQUXQWTY0UPnWd5ve9mRKR1zu3ao84TP6yA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
