[regext] regext - Requested session has been scheduled for IETF 106
Dear Antoin Verschuren, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. regext Session 1 (2:00 requested) Wednesday, 20 November 2019, Morning Session I 1000-1200 Room Name: Hullet size: 100 - iCalendar: https://datatracker.ietf.org/meeting/106/sessions/regext.ics Request Information: - Working Group Name: Registration Protocols Extensions Area Name: Applications and Real-Time Area Session Requester: Antoin Verschuren Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: cacao add sacm saag doh Key Participant Conflict: dnsop dprive dnssd hrpc People who must be present: James Galvin Barry Leiba Antoin Verschuren Resources Requested: Special Requests: - ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] I-D Action: draft-ietf-regext-dnrd-objects-mapping-02.txt
Hello, An interoperability issue with draft-ietf-regext-dnrd-objects-mapping was reported to the authors a few weeks ago. Version 2 of the draft was published today. The new version of the draft fixes the issue (verified by the implementer that reported it), and its backward compatible. The authors believe that the changes are no substantive, but a quick WGLC may be a good idea. Section 16.14 of the draft describes the changes. Regards, Gustavo On 10/25/19, 10:06, "regext on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions WG of the IETF. Title : Domain Name Registration Data (DNRD) Objects Mapping Authors : Gustavo Lozano James Gould Chethan Thippeswamy Filename: draft-ietf-regext-dnrd-objects-mapping-02.txt Pages : 182 Date: 2019-10-25 Abstract: This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dregext-2Ddnrd-2Dobjects-2Dmapping_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=n_IaJcy1dPcVid4ef6G-Ivj58fE_oHIUopW6FOPD0Y4&e= There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dregext-2Ddnrd-2Dobjects-2Dmapping-2D02&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=wlxj_Zwo2vlZJCNvg_rw8pzxiXI4IjQeaYRuToqWVRA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dregext-2Ddnrd-2Dobjects-2Dmapping-2D02&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=x7TwXNuQ5aUzby0a18xTvLNBpAsqRNhrn_yghGmyGGw&e= A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dregext-2Ddnrd-2Dobjects-2Dmapping-2D02&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=LKAtEw_xxrduXLLhsSTVAX2usXd7p7rAoYiNkumHrBI&e= Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=wnV99YGGVLCeEmzhKudGxP8maUXHfUTRCZgoRXd3N7I&e= ___ regext mailing list regext@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-0BvgAgfmwfE0&m=wQqlX1QMrQecjbnCG8lFOH2vQSkTJBy0mkRLlnZq59E&s=uF0AHlvEBpnaFAJhf0Qb3lKuTqO-o4spYZaeEBPBNZM&e= ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] I-D Action: draft-ietf-regext-dnrd-objects-mapping-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions WG of the IETF. Title : Domain Name Registration Data (DNRD) Objects Mapping Authors : Gustavo Lozano James Gould Chethan Thippeswamy Filename: draft-ietf-regext-dnrd-objects-mapping-02.txt Pages : 182 Date: 2019-10-25 Abstract: This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping-02 https://datatracker.ietf.org/doc/html/draft-ietf-regext-dnrd-objects-mapping-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: Incompatibility between RFC 8521 and RFC 7484
Yeah, if nobody cares that strongly then an errata will suffice. Perhaps we can do something about this in a set of bis versions of the specs if/when that comes about. -andy On Fri, Oct 25, 2019 at 10:05 AM Hollenbeck, Scott wrote: > > There've been no other contributions to this discussion, so I'm leaning > towards the path of least work to address the issue Patrick identified. That > means errata for 8521 to note that the structure of the registry is based on > the structure from 7484, but it includes the additional contact information. > > Scott > > > -Original Message- > > From: regext On Behalf Of Patrick Mevzek > > Sent: Wednesday, October 16, 2019 2:02 AM > > To: regext@ietf.org > > Subject: [EXTERNAL] Re: [regext] FW: Incompatibility between RFC 8521 and > > RFC 7484 > > > > > > > > On Tue, Oct 15, 2019, at 10:17, Hollenbeck, Scott wrote: > > > FYI, folks. Does anyone have any thoughts on the better path forward? > > > > Between: > > 1) Publish errata for 8521 noting that "The bootstrap service registry for > > the > > RDAP service provider space is represented using the structure specified in > > Section 3 of RFC 7484" should be changed to " The bootstrap service registry > > for the RDAP service provider space is _modeled after_ the structure > > specified in Section 3 of RFC 7484", or > > > > and > > > > 2) Publish errata for 8521 to change the contact stuff, and then work with > > IANA to remove the contact values. > > > > I think it depends on the need or not to have contact information. > > > > If needed: > > > > - then option 1 applies, but I would think you need a little more > > explanation > > than just "is _modeled after_"; this is still probably the faster solution > > - or contact information could be handled elsewhere in the document, with > > inspiration from other RDAP specifications, using "remarks", "notices" or > > even "links" but that would need far more changes including to 8521 and is > > really more a 8521-bis than an errata. Or else just considering that for any > > URL given it can still be used with the "help" query case, which should be > > enough as the first step to know "who" is behind a given RDAP URL. > > > > If not needed: > > > > - option 2 is better but more work. Maybe interoperability issues for anyone > > already implementing this RFC? > > > > > > I think the contact information comes because of §3.1 So it seems useful to > > have, but then why not say contact information is useful for all other > > bootstrap documents (domain, IPv4, IPv6, etc.) also? > > This would mean an 7484-bis, so again quite some work. > > > > > > What do people having implemented RFC 8521 think about that? > > > > -- > > Patrick Mevzek > > p...@dotandco.com > > > > ___ > > 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
Re: [regext] FW: Incompatibility between RFC 8521 and RFC 7484
There've been no other contributions to this discussion, so I'm leaning towards the path of least work to address the issue Patrick identified. That means errata for 8521 to note that the structure of the registry is based on the structure from 7484, but it includes the additional contact information. Scott > -Original Message- > From: regext On Behalf Of Patrick Mevzek > Sent: Wednesday, October 16, 2019 2:02 AM > To: regext@ietf.org > Subject: [EXTERNAL] Re: [regext] FW: Incompatibility between RFC 8521 and > RFC 7484 > > > > On Tue, Oct 15, 2019, at 10:17, Hollenbeck, Scott wrote: > > FYI, folks. Does anyone have any thoughts on the better path forward? > > Between: > 1) Publish errata for 8521 noting that "The bootstrap service registry for the > RDAP service provider space is represented using the structure specified in > Section 3 of RFC 7484" should be changed to " The bootstrap service registry > for the RDAP service provider space is _modeled after_ the structure > specified in Section 3 of RFC 7484", or > > and > > 2) Publish errata for 8521 to change the contact stuff, and then work with > IANA to remove the contact values. > > I think it depends on the need or not to have contact information. > > If needed: > > - then option 1 applies, but I would think you need a little more explanation > than just "is _modeled after_"; this is still probably the faster solution > - or contact information could be handled elsewhere in the document, with > inspiration from other RDAP specifications, using "remarks", "notices" or > even "links" but that would need far more changes including to 8521 and is > really more a 8521-bis than an errata. Or else just considering that for any > URL given it can still be used with the "help" query case, which should be > enough as the first step to know "who" is behind a given RDAP URL. > > If not needed: > > - option 2 is better but more work. Maybe interoperability issues for anyone > already implementing this RFC? > > > I think the contact information comes because of §3.1 So it seems useful to > have, but then why not say contact information is useful for all other > bootstrap documents (domain, IPv4, IPv6, etc.) also? > This would mean an 7484-bis, so again quite some work. > > > What do people having implemented RFC 8521 think about that? > > -- > Patrick Mevzek > p...@dotandco.com > > ___ > 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] Milestones changed for regext WG
Changed milestone "Submit for publication "Login Security Extension for the Extensible Provisioning Protocol (EPP)"", resolved as "Done". URL: https://datatracker.ietf.org/wg/regext/about/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Publication has been requested for draft-ietf-regext-login-security-04
James Galvin has requested publication of draft-ietf-regext-login-security-04 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
