[regext] Re: I-D Action: draft-ietf-regext-rdap-x-media-type-02.txt

[Gould, James]

Andy,

I'll provide a full review, but upon my initial review 
draft-ietf-regext-rdap-x-media-type-02 still doesn't support the Extension 
Version Identifier in draft-ietf-regext-rdap-versioning, following the ABNF:

extension-version-identifier = identifier versioning
identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer
versioning = ["-" 1*VCHAR]

The Extension Version Identifier needs to be unique from the Extension 
Identifier, which is why the '-' separator is optionally used.  All that is 
required in draft-ietf-regext-rdap-x-media-type is to broaden the format of the 
"extensions" values passed to include support for the Extension Version 
Identifier.  I provided a proposal in my prior feedback.  I also don't believe 
the behavior of draft-ietf-regext-rdap-x-media-type should be any different 
whether the server is implementing draft-ietf-regext-rdap-versioning.

We should look to merge the two drafts, since 
draft-ietf-regext-rdap-x-media-type is a subset of 
draft-ietf-regext-rdap-versioning, and we need to ensure that there is full 
compatibility.  

Thanks,

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  




On 10/17/24, 7:00 AM, "Andrew Newton (andy)" mailto:a...@hxr.us>> wrote:


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 


Hi all,


We have updated this draft based on feedback from this working group, 
including a section on how this draft works with the versioning draft.


Additionally, we have added many examples.


Many thanks to those who have provided feedback.


-andy


On 10/17/24 06:55, internet-dra...@ietf.org  
wrote:
> Internet-Draft draft-ietf-regext-rdap-x-media-type-02.txt is now available. It
> is a work item of the Registration Protocols Extensions (REGEXT) WG of the
> IETF.
>
> Title: An RDAP With Extensions Media Type
> Authors: Andy Newton
> Jasdip Singh
> Name: draft-ietf-regext-rdap-x-media-type-02.txt
> Pages: 16
> Dates: 2024-10-17
>
> Abstract:
>
> This document defines a media type for RDAP that can be used to
> describe RDAP content with RDAP extensions. Additionally, this
> document describes the usage of this media type with RDAP for the
> purposes of signalling RDAP extensions during content negotiation.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://secure-web.cisco.com/1B7PFgZ5nw6j1dfpylAfAUnfNBoYLtl6SHAJBWyd8L7KIA9EpZ0j-zGU657KqnBJO0EA0v3JU2bmdCW-idaNsxaAVC12TxX-epPBKgjuUDAUuKqFDtCanD0VjBmJixZWOb6egWw7gAke4h0EuhdGljZPHxHxHZD9PQbs4htrZxF4naJhOV5vc70dzUYhlu15suYuSIjUrAqVsT98Ry_U3b1znWzGA0in-Mycu1dUKTHvQ4P9htir7jxR3D-lEygdNXpU9h8m1svJUWd_knWjPEAG8c5fLHpEA-RAFmn39fzc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-x-media-type%2F
>  
> 
>
> There is also an HTML version available at:
> https://secure-web.cisco.com/19ITBvpQVRIgi9qkSGUcFWmowcTtSxOvqy4SZ_-uFqUMQ02g3hb4RbxFfUjnveGolrIzBO9Kscy0OrA8tU5uS_2UlJqjzusABFonQ5UBs38YLDCEA6-7O4q2_6q_C5iuUzp45-c7BZ4eWi42TfwtfPazeGeK8KmnViH52cn-XnObM2EMqn7gHoi_8qzpEcxpt4QGHV_MldNCZObDYg1sG1pgokIEobjlthB2yJZ8ykDObpHZxUM0-gVew9jP-ZIg-Ttc4YpnknvmZavxOENF34i84bEJlPKRIIMeGUdoU6NI/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-x-media-type-02.html
>  
> 
>
> A diff from the previous version is available at:
> https://secure-web.cisco.com/1hWyB9nazhPx9Qb54HBaMC7S9scWUAVwww7-pDTLlP8ac_ZCKWJ9vH0S0RUKffJVcVVPbtC5Pjp5arliZVVe5bgEXcSs6JyqyTG7dYpOF1mH19UcvcWf-NydpzOaL40EcpbrhSbIF1ot9WBJMOygqHy_VsDJOySldfkffg5cWhuObSH3NvpAw6ftTimnydapoig9Dp51E6G9QkWH3gZMs8GccnmiLgsNFCvSTtcoYMuP-LVPERnDorkSLPvCCYtRjmhdcz0QnbQWG2SA3F1qNuss-3ipfaVhrrF1oh5z5wyM/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-regext-rdap-x-media-type-02
>  
> 

[regext] Re: I-D Action: draft-ietf-regext-rdap-x-media-type-02.txt

[Andrew Newton (andy)]

Hi all,

We have updated this draft based on feedback from this working group, 
including a section on how this draft works with the versioning draft.


Additionally, we have added many examples.

Many thanks to those who have provided feedback.

-andy

On 10/17/24 06:55, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-regext-rdap-x-media-type-02.txt is now available. It
is a work item of the Registration Protocols Extensions (REGEXT) WG of the
IETF.

Title:   An RDAP With Extensions Media Type
Authors: Andy Newton
 Jasdip Singh
Name:draft-ietf-regext-rdap-x-media-type-02.txt
Pages:   16
Dates:   2024-10-17

Abstract:

This document defines a media type for RDAP that can be used to
describe RDAP content with RDAP extensions.  Additionally, this
document describes the usage of this media type with RDAP for the
purposes of signalling RDAP extensions during content negotiation.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-x-media-type-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-x-media-type-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org


___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] I-D Action: draft-ietf-regext-rdap-x-media-type-02.txt

[internet-drafts]

Internet-Draft draft-ietf-regext-rdap-x-media-type-02.txt is now available. It
is a work item of the Registration Protocols Extensions (REGEXT) WG of the
IETF.

   Title:   An RDAP With Extensions Media Type
   Authors: Andy Newton
Jasdip Singh
   Name:draft-ietf-regext-rdap-x-media-type-02.txt
   Pages:   16
   Dates:   2024-10-17

Abstract:

   This document defines a media type for RDAP that can be used to
   describe RDAP content with RDAP extensions.  Additionally, this
   document describes the usage of this media type with RDAP for the
   purposes of signalling RDAP extensions during content negotiation.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-x-media-type-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-x-media-type-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Call for agenda items IETF 121

[Victor Zhou]

Dear REGEXT WG and chairs,

Could we have 10min to talk about

rfc-draft-AuthCodeSEC:
https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md

Victor Zhou,
Building Namefi (https://namefi.io) by D3Serve Labs Inc (https://d3serve.xyz
)

---


Dear REGEXT WG,

This is a call for agenda items for IETF 121.
Just as last time, we will have 2 slots in Dublin.
1 hour for administrative items and a 2 hour slot for new work with
more technical in dept presentations.

Please send any requests to the chairs or respond to this email.

Please forgive me if I have missed requests already sent to the
mailinglist in the past weeks. I’m trying to catch up after some weeks
of absence.
So far I have noted 1 request from James Gould on implementation
experience with the EoH and EoQ drafts on the preliminary agenda.

Regards,

Your co-chairs Jim and Antoin.
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Call for agenda items IETF 121

[Joseph Yee]

Will EPP-Variant (
https://datatracker.ietf.org/doc/draft-galvin-regext-epp-variants/) be
discussed in IETF121?

Thanks
Joseph


On Wed, Oct 2, 2024 at 10:07 AM Andrew Newton (andy)  wrote:

> Hi,
>
> Could we have some time to discuss the rdap-extensions draft?
>
> -andy
>
> On Mon, Sep 30, 2024 at 9:45 AM Antoin Verschuren
>  wrote:
> >
> > Dear REGEXT WG,
> >
> > This is a call for agenda items for IETF 121.
> > Just as last time, we will have 2 slots in Dublin.
> > 1 hour for administrative items and a 2 hour slot for new work with more
> technical in dept presentations.
> >
> > Please send any requests to the chairs or respond to this email.
> >
> > Please forgive me if I have missed requests already sent to the
> mailinglist in the past weeks. I’m trying to catch up after some weeks of
> absence.
> > So far I have noted 1 request from James Gould on implementation
> experience with the EoH and EoQ drafts on the preliminary agenda.
> >
> > Regards,
> >
> > Your co-chairs Jim and Antoin.
> > ___
> > regext mailing list -- regext@ietf.org
> > To unsubscribe send an email to regext-le...@ietf.org
>
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: normative language and references in draft-ietf-regext-delete-bcp

[Andrew Newton (andy)]

This is done. In addition, I noted the informative reference to RFC
3915 has changed to normative.

However, during my review of the traffic on this list, it appears
there was a tacit agreement on changing some of the normative
language.

See: https://mailarchive.ietf.org/arch/msg/regext/mcMbVUspJuALOHWAGQWeuoxAyYM/

If this draft is revised with such a change before moving to the AD, I
will need to revise the write-up as well.

-andy

On Tue, Oct 15, 2024 at 8:19 PM James Galvin  wrote:
>
> Speaking as co-Chair, here is where I believe this discussion has landed.
>
> From a consensus point of view, I’m declaring the working group consensus to 
> be that v08 of draft-ietf-regext-delete-bcp is ready for submission to the 
> IESG.  We’ve been through WGLC and we’ve had quite some discussion since then 
> but I do not believe the changes have been material and require a second WGLC.
>
> However, we do have one significant dissenting voice in that consensus.  In 
> our working group we only have a few people who are very active and we’ve 
> been fortunate that we typically have full consensus amongst those who speak 
> up regarding a document’s status.  The Chairs are sensitive to alternate 
> points of view when the number of those who engage is frequently small.
>
> The Chair’s suggestion is to acknowledge the point of view in the Shepherd 
> Writeup.  We think it’s important so that if questions arise within the IESG 
> or during IETF Last Call, particularly from anyone who happens to check our 
> mailing list and notices the extended dialogue, we are being clear that the 
> working group considered the question and the document represents consensus.
>
> Andy Newton, as Document Shepherd, please update the write-up accordingly.  
> Upon completion the Chairs will review it and then submit the document to the 
> IESG for publication as a Best Current Practice.
>
> Thanks to all for your passionate and detailed discussion of the questions.  
> I know our work is better when so many of us are so engaged.
>
> Antoin and Jim
>
>
> On 19 Sep 2024, at 13:48, Hollenbeck, Scott wrote:
>
> >> -Original Message-
> >> From: kowa...@denic.de 
> >> Sent: Thursday, September 19, 2024 9:47 AM
> >> To: Hollenbeck, Scott ; regext@ietf.org
> >> Subject: [EXTERNAL] Re: [regext] FW: Re: normative language and references
> >> in draft-ietf-regext-delete-bcp
> >>
> >> Hi Scott,
> >>
> >> On 12.09.24 14:39, Hollenbeck, Scott wrote:
>  -Original Message-
>  From: kowa...@denic.de 
>  Sent: Thursday, September 12, 2024 2:29 AM
>  To: Hollenbeck, Scott 
>  Subject: [EXTERNAL] Re: [regext] FW: Re: normative language and
>  references in draft-ietf-regext-delete-bcp
> 
>  Hi Scott,
> 
>  I think I am missing your comment on this issue from the previous thread
> >> [1].
> 
>    >> I am still not sure how useful it is to have normative language
>  as such in BCP, especially if it's only used in the section 6, which
>  refers to other sections like 5.1.4.3 which in turn does not contain any
> >> normative language at all.
>  Whether it's a MUST or SHOULD is likely a secondary concern and here
>  at least I would like to learn the logic behind the change.
> >>> [SAH] The value of normative language in a BCP is described in Section 6 
> >>> of
> >> RFC 2119:
> >>>
> >>> "Imperatives of the type defined in this memo must be used with care and
> >> sparingly.  In particular, they MUST only be used where it is  actually 
> >> required
> >> for interoperation or to limit behavior which has  potential for causing 
> >> harm
> >> (e.g., limiting retransmisssions)"
> >>>
> >>> "or to limit behavior which has  potential for causing harm". The guidance
> >> found in Section 6 of the draft uses normative language in the spirit of 
> >> limiting
> >> behavior which has potential for causing harm. As it says in the draft, 
> >> "with
> >> minimal undesired side effects".
> >>>
> >> [PK] This was not exactly my concern.
> >>
> >> Section 6 refers to 5.1.4.3 as one of alternatives of MUST.
> >>
> >> 5.1.4.3 reads: "EPP clients MAY rename the host object to be deleted...". 
> >> This
> >> is followed by "This requires that the client maintain...". I would expect 
> >> some
> >> normative language here to be able to follow the recommendation of Section
> >> 6.
> >>
> >> The same applies to the other alternatives of section 6.
> >
> > [SAH] Pawel, at this point I'm inclined to wait to see what our chairs say 
> > about document readiness for AD review (hint, hint, WG chairs) before we 
> > make any more changes to the text. Having said that, I just read through 
> > Section 5 again. It's titled "Analysis of Practices for Domain and Host 
> > Object Deletion". If we accept that title, I'd actually prefer to *remove* 
> > all normative language from Section 5 so that it remains focused on 
> > *analysis*. The normative language can be used in Section 6, 
> > "Recommendations".
> >