Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Thank you Scott and all others that replied during the extended WGLC..
The chairs agree with the Authors that there was no consensus reached during
the extended WGLC to make changes to the document.
Therefor this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and one concern
whose required changes were not supported by 3 others.
We will submit the document to the IESG as is.
The document shepherd for this document is Mario Loffredo.
Mario, could you please start your shepherd writeup?
Regards,
Jim and Antoin
> Op 12 okt. 2020, om 17:09 heeft Hollenbeck, Scott
> het volgende geschreven:
>
>> -Original Message-
>> From: regext mailto:regext-boun...@ietf.org>> On
>> Behalf Of James Galvin
>> Sent: Friday, October 2, 2020 4:15 PM
>> To: regext@ietf.org <mailto:regext@ietf.org>
>> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>>
>> 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 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 parameter to differentiate between the
>> supported entity object types (e.g., contact and registrar),
>> such as using different formats, using a
>> 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/1k4lL- <https://secure-web.cisco.com/1k4lL->
>> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
>> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
>> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
>> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
>> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
>> u_lM-
>> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org
>> <http://2fwww.icann.org/>%2Fresources%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.
>
> [SAH] I don't think we reached consensus to change anything in the draft, so
> I left this one alone.
>
> Scott
> ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext
> <https://www.ietf.org/mailman/listinfo/regext>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
> -Original Message-
> From: regext On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:15 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> 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 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 parameter to differentiate between the
> supported entity object types (e.g., contact and registrar),
> such as using different formats, using a
> 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/1k4lL-
> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
> u_lM-
> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org%2Fresources%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.
[SAH] I don't think we reached consensus to change anything in the draft, so I
left this one alone.
Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
On Wed, Oct 07, 2020 at 10:46:52AM +0200, Thomas Corte (TANGO support) wrote: > On 10/7/20 03:17, Tom Harrison wrote: The question is whether the RDAP protocol should provide guidance with how to handle overlapping non-unique handles. >>> >>> I don't think it should. A Jasdip pointed out, the definition of a >>> handle notes that they're supposed to be registry-unique. >> >> I agree with Scott and Jasdip on this point. > > I think it's problematic to have a standard like this (which will > eventually have to be implemented by all ICANN-regulated registries) > impose such a requirement (unique handles across all object types) > out of the blue when there are already hundreds of databases out > there that were not build with this assumption in mind. Entity identifiers aren't RDAP 'entry points', though, in that there are no guarantees that you can take an identifier from some other context and construct a usable query like 'https://rdap.example.net/entity/$identifier' (putting RFC 8521 object tags to one side), so it's not clear that it actually imposes this requirement. For example, it's open to an implementor to prefix their existing identifiers with strings describing the underlying object types, in order to construct unique entity handles. -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Hello, On 10/7/20 03:17, Tom Harrison wrote: >>> The question is whether the RDAP protocol should provide guidance with >>> how to handle overlapping non-unique handles. >> >> I don't think it should. A Jasdip pointed out, the definition of a >> handle notes that they're supposed to be registry-unique. > > I agree with Scott and Jasdip on this point. I think it's problematic to have a standard like this (which will eventually have to be implemented by all ICANN-regulated registries) impose such a requirement (unique handles across all object types) out of the blue when there are already hundreds of databases out there that were not build with this assumption in mind. Sure, a migration of non-unique handles is possible, and we did that when ICANN demanded a specific ROID prefix per TLD, but that was a minor change as the ROID isn't really used for operationally addressing anything. Renaming contact IDs and/or registrar IDs would have more of an impact, as it would also require all registrars to update their own databases/configurations as well to reflect the new handles. If "using a precedence order" means that a server can choose to e.h. just deliver the contact when there's a registrar with the same handle, that's an acceptably lenient interpretation. Otherwise, no assumption about the uniqueness of entity handles should be made long after the fact. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
On Mon, Oct 05, 2020 at 04:03:40PM +, Hollenbeck, Scott wrote: >>> The phrase 'registry-unique identifier' connotes a unique lookup >>> key for entities, irrespective of their type. It puts the onus on >>> a registry to ensure so. Does that not suffice? >> >> There are cases where the entity lookup key is not unique, since >> the RDAP entity object can support multiple independent registry >> objects (contact and registrar). The recommended text provides >> guidance for this use case: >> >> The 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 parameter >> to differentiate between the supported entity object types (e.g., >> contact and registrar), such as using different formats, >> using a precedence order, or a combination of formats and >> precedence order. >> >> The question is whether the RDAP protocol should provide guidance with >> how to handle overlapping non-unique handles. > > I don't think it should. A Jasdip pointed out, the definition of a > handle notes that they're supposed to be registry-unique. I agree with Scott and Jasdip on this point. -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
> -Original Message- > From: Gould, James > Sent: Monday, October 5, 2020 11:41 AM > To: jasd...@arin.net; Hollenbeck, Scott ; > mario.loffr...@iit.cnr.it; gal...@elistx.com; regext@ietf.org > Subject: Re: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext- > rfc7482bis > > >> The phrase 'registry-unique identifier' connotes a unique lookup key for > entities, irrespective of their type. It puts the onus on a registry to > ensure so. > Does that not suffice? > > There are cases where the entity lookup key is not unique, since the RDAP > entity object can support multiple independent registry objects (contact and > registrar). The recommended text provides guidance for this use case: > > The 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 parameter > to differentiate between the supported entity object types (e.g., > contact and registrar), such as using different formats, > using a precedence order, or a combination of formats and > precedence order. > > The question is whether the RDAP protocol should provide guidance with > how to handle overlapping non-unique handles. I don't think it should. A Jasdip pointed out, the definition of a handle notes that they're supposed to be registry-unique. Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>> The phrase 'registry-unique identifier' connotes a unique lookup key for
>> entities, irrespective of their type. It puts the onus on a registry to
>> ensure so. Does that not suffice?
There are cases where the entity lookup key is not unique, since the RDAP
entity object can support multiple independent registry objects (contact and
registrar). The recommended text provides guidance for this use case:
The 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 parameter
to differentiate between the supported entity object types (e.g.,
contact and registrar), such as using different formats,
using a precedence order, or a combination of formats and
precedence order.
The question is whether the RDAP protocol should provide guidance with how to
handle overlapping non-unique handles.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 10/5/20, 11:21 AM, "Jasdip Singh" wrote:
Hi.
Section 5.1 of 7483bis (
https://secure-web.cisco.com/1RB1WjHV1xP4ZSnvfV4N05YxMIUObjUDb1GSrtNRvknotxXZOR4r6KW5Mj3Gn99W8QZ13Y0iFQ04zJ7R_BKOXERI2tpouy1xS_xtTQKTLonQ90L6F_w_cgXMfIozB57eTNsab-6w2lvmRt77MpWM-K5Pu5LK-Fqk54dm9dQy3cLegMP53VV8WzcfvWEZRurzAyRPmNaz15FXIiRxZE7bmMEHJZ8KryIFe8Cn0m3YBCQOeaWD3mfU90e79jvRsN6fGjwj4e6YlktqOb45uycsLagfTLuJ9gZ6tH62OL5d8K_Y/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-rfc7483bis-01%23section-5.1
) defines handle as:
handle -- a string representing a registry-unique identifier of the entity
The phrase 'registry-unique identifier' connotes a unique lookup key for
entities, irrespective of their type. It puts the onus on a registry to ensure
so. Does that not suffice?
Jasdip
On 10/5/20, 9:15 AM, "regext on behalf of Gould, James"
wrote:
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
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
<http://secure-web.cisco.com/1bFp-HGXba90S-TZ720loQzOpgdlPHGtU1fQDrQ9fNgiBVvG2oS5BdIzJWl-ABbwRYIlChnZa-3-BARuMmAflz70zFR_bKIJwhdh0Nr1ZcSKNw7BWdMwC2ymrNNvJ7x52GuJAD5RE9q6FlpO0x4HgCZERFWRRmVLdn48hUgR6lqWjyR6qJwDpIZnLVA5YGBPSGHTynKhyv-_P3tY2ymxlwtAb56j-wQMA2mll8TNEFQ3XQ6-mkIFWQd_3j-DtwfmEgQ4K50V1RGMHkR3QiZL0pg/http%3A%2F%2Fverisigninc.com%2F>
On 10/5/20, 9:00 AM, "regext on behalf of Hollenbeck, Scott"
wrote:
> -Original Message-
> From: regext On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin ; 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.
> >
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Hi.
Section 5.1 of 7483bis (
https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-01#section-5.1 )
defines handle as:
handle -- a string representing a registry-unique identifier of the entity
The phrase 'registry-unique identifier' connotes a unique lookup key for
entities, irrespective of their type. It puts the onus on a registry to ensure
so. Does that not suffice?
Jasdip
On 10/5/20, 9:15 AM, "regext on behalf of Gould, James"
wrote:
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
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"
wrote:
> -Original Message-
> From: regext On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin ; 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 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 parameter
> > to differentiate between the supported entity object types (e.g.,
> > contact and registrar), such as using different formats,
> > using a 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 th
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
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
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"
wrote:
> -Original Message-
> From: regext On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin ; 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 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 parameter
> > to differentiate between the supported entity object types (e.g.,
> > contact and registrar), such as using different formats,
> > using a 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
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
> -Original Message-
> From: regext On Behalf Of Mario Loffredo
> Sent: Saturday, October 3, 2020 3:18 AM
> To: James Galvin ; 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 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 parameter
> > to differentiate between the supported entity object types (e.g.,
> > contact and registrar), such as using different formats,
> > using a 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 parameter to differentiate
>
> NEW
>
> Where overlap may occur, the server SHOULD define a scheme for the
> 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
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
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 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 parameter to differentiate between the
supported entity object types (e.g., contact and registrar),
such as using different formats, using a
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://www.icann.org/resources/pages/rdap-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.
Thanks!
Antoin and Jim
On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:
The following working group document is believed to be ready for
submission to the IESG for publication as a standards track document:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/
This WG last call will end at close of business, Friday, 2 October
2020.
Please review this document and indicate your support (a simple
“+1” is sufficient) or concerns with the publication of this
document by replying to this message on the list.
The document shepherd for this document is Mario Loffredo.
Regards,
Jim and Antoin
___
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] WG LAST CALL: draft-ietf-regext-rfc7482bis
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.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 9/24/20, 12:36 PM, "Jasdip Singh" wrote:
Hello Scott, James.
One thought is if it could be in the RDAP profile doc for the DNRs
(https://secure-web.cisco.com/1rpKdfnEnk1Kr48jubRhCwGFht_mdOahH1FgtC67Iah_PrHMRfoEWU7HXESyJMsZ1OIrHjKe_tH2TpZoS255ApsvovkAtXUNwdbGgZJvfSeVCCqQLWq9VITVXtaoP1CXev-IOKJzpfYJuv2IdKIbkjHbWdjq01FUNgLIDCk7SmcLSunTUIorviDc_vhPujx8fojQQ7yt8yaTmqpI7NSwr0xLY-umkpcXmEOIqjCmmh5tYAW-z9AdTAX4NVP2ncoTILCIvB-TlRg1bVusnHZKw-w/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages%2Frdap-operational-profile-2016-07-26-en).
That way no need to update the spec.
Jasdip
On 9/24/20, 12:31 PM, "regext on behalf of Hollenbeck, Scott"
wrote:
> -Original Message-
> From: Gould, James
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott ; i...@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL:
draft-ietf-regext-rfc7482bis
>
> Scott,
>
> 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 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
> parameter to differentiate between the supported entity object types
(e.g.,
> contact and registrar), such as using different formats,
using a
> 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.
I'd like to see some discussion of this suggestion, too. What do people
think? Is it necessary?
Scott
___
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/1uhNzuchIJztHae6LWfJ1n71r6h9keZVyeLYMKk6XBzqFZnzlPYXz-bTVm89lsK1lzwy0KyQfVMQ8yJyvj9OdK0HdlDXnwqlJyCWvYxKMcoWJ5UX1QpTKu1Of5rVVaQ3gqoUUX9fZbQ2dKWdiqxIcPeMU9MUI9It8e8-1ekP-xHK6Ng4p0MArEn2aMHH9Clo6k9uay0NVzUFQnTS0IU2wEzDaxqi5PNRTrhSdGWfQpVOjXyxbDih5ZMQvLhBtws3QbhtzNJ4K1o0VstyjQ_K_yICHdzzOR5kl_eewjxddliM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Hello Scott, James.
One thought is if it could be in the RDAP profile doc for the DNRs
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en).
That way no need to update the spec.
Jasdip
On 9/24/20, 12:31 PM, "regext on behalf of Hollenbeck, Scott"
wrote:
> -Original Message-
> From: Gould, James
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott ; i...@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL:
draft-ietf-regext-rfc7482bis
>
> Scott,
>
> 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 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
> parameter to differentiate between the supported entity object types
(e.g.,
> contact and registrar), such as using different formats, using a
> 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.
I'd like to see some discussion of this suggestion, too. What do people
think? Is it necessary?
Scott
___
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] WG LAST CALL: draft-ietf-regext-rfc7482bis
> -Original Message-
> From: Gould, James
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott ; i...@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Scott,
>
> 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 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
> parameter to differentiate between the supported entity object types (e.g.,
> contact and registrar), such as using different formats, using a
> 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.
I'd like to see some discussion of this suggestion, too. What do people think?
Is it necessary?
Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
Scott,
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 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 parameter to differentiate between the
supported entity object types (e.g., contact and registrar),
such as using different formats, using a
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.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 9/21/20, 2:01 PM, "Hollenbeck, Scott"
wrote:
> -Original Message-
> From: regext On Behalf Of Gould, James
> Sent: Monday, September 21, 2020 11:22 AM
> To: i...@antoin.nl; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL:
draft-ietf-regext-rfc7482bis
>
> Upon review of draft-ietf-regext-rfc7482bis, I have the following
feedback:
>
> Use of entity lookup for registrar objects was added, but there is no
guidance
> related to handling entity lookups for different independent object types,
> where the object identifier and subsequently the may overlap. An
> example is the ROID format for contacts “((\w|_){1,80}-\w{1,8}” is unique
> from the use of the IANA Registrar ID “\d+” for registrars but not unique
> from the registrar name (“fn element” in RFC 7483 with “\w+”). The
registrar
> name is a superset of the ROID, so a following the ROID format
can
> take precedence as a contact object lookup instead of a registrar object
> lookup. A is a unique for all RDAP objects except for the entity
> object that can be mapped to multiple distinct object types (contact and
> registrar). Should the RFC cover the case of possible overlapping
> values for different types of entity objects, such as contact and
registrar
> objects, where the server must define a unique scheme or define
> a precedence order?
Jim, RDAP doesn't have any notion of registrar entities that are somehow
different from any other type of entity, so I'm not sure what, if anything,
makes sense to say in the document. If you have a specific suggestion for text,
it would be worth sharing to see what others think.
Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
> -Original Message-
> From: regext On Behalf Of Gould, James
> Sent: Monday, September 21, 2020 11:22 AM
> To: i...@antoin.nl; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Upon review of draft-ietf-regext-rfc7482bis, I have the following feedback:
>
> Use of entity lookup for registrar objects was added, but there is no guidance
> related to handling entity lookups for different independent object types,
> where the object identifier and subsequently the may overlap. An
> example is the ROID format for contacts “((\w|_){1,80}-\w{1,8}” is unique
> from the use of the IANA Registrar ID “\d+” for registrars but not unique
> from the registrar name (“fn element” in RFC 7483 with “\w+”). The registrar
> name is a superset of the ROID, so a following the ROID format can
> take precedence as a contact object lookup instead of a registrar object
> lookup. A is a unique for all RDAP objects except for the entity
> object that can be mapped to multiple distinct object types (contact and
> registrar). Should the RFC cover the case of possible overlapping
> values for different types of entity objects, such as contact and registrar
> objects, where the server must define a unique scheme or define
> a precedence order?
Jim, RDAP doesn't have any notion of registrar entities that are somehow
different from any other type of entity, so I'm not sure what, if anything,
makes sense to say in the document. If you have a specific suggestion for text,
it would be worth sharing to see what others think.
Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
+1 From: regext on behalf of Mario Loffredo Sent: Monday, September 21, 2020 12:49 AM To: Antoin Verschuren ; regext@ietf.org Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis Notice: This email is from an external sender. +1 Mario Il 18/09/2020 15:52, Antoin Verschuren ha scritto: > The following working group document is believed to be ready for submission > to the IESG for publication as a standards track document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ > > This WG last call will end at close of business, Friday, 2 October 2020. > > Please review this document and indicate your support (a simple “+1” is > sufficient) or concerns with the publication of this document by replying to > this message on the list. > > The document shepherd for this document is Mario Loffredo. > > Regards, > > Jim and Antoin > > > > > > > > > ___ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext -- Dr. Mario Loffredo Systems and Technological Development Unit Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo ___ 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] WG LAST CALL: draft-ietf-regext-rfc7482bis
+1 Mario Il 18/09/2020 15:52, Antoin Verschuren ha scritto: The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ This WG last call will end at close of business, Friday, 2 October 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Mario Loffredo. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dr. Mario Loffredo Systems and Technological Development Unit Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
On Fri, Sep 18, 2020 at 03:52:44PM +0200, Antoin Verschuren wrote: > The following working group document is believed to be ready for > submission to the IESG for publication as a standards track > document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis > > This WG last call will end at close of business, Friday, 2 October 2020. > > Please review this document and indicate your support (a simple “+1” > is sufficient) or concerns with the publication of this document by > replying to this message on the list. +1 -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ This WG last call will end at close of business, Friday, 2 October 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is Mario Loffredo. Regards, Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
