[regext] Re: Call for agenda items IETF 121

[Victor Zhou]

Hi REGEXT WG and Chairs: Antonin and James

Please find the following updated information about AuthCodeSEC

Presentation slides for IETF-121 REGEXT session:
https://docs.google.com/presentation/d/1FHQa6KyMqIFS9A1Kx8qO0LanDIRtzOeF-nWrpYOYXt8/edit#slide=id.p
Latest RFC draft:
https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/draft-authcodesec-00.txt

Talk to you tomorrow

Victor,
CEO & founder of Namefi , tokenizing domain names for
trading, DeFi and future Internet. https://namefi.io



On Thu, Oct 31, 2024 at 8:20 PM Victor Zhou  wrote:

> Dear REGEXT WG
>
> Thank you for having AuthCodeSEC on the agenda of the IETF121
> agenda-121-regext-01 session
>
> And thank you James, Judy and other distinguished working group members
> for giving feedback and guidance,
> we've pushed the latest snapshot of our draft here
> https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md
>
> Please take a look. For unresolved comments we will soon append to our
> draft notes in the git repo too.
>
> Look forward to talking to you soon!
>
> Victor,
> CEO & founder of Namefi , tokenizing domain names for
> trading, DeFi and future Internet. https://namefi.io
>
>
>
> On Thu, Oct 17, 2024 at 3:03 PM Victor Zhou  wrote:
>
>> Hi Andy and Jim,
>>
>> found you on the REGEXT chair and the call for agenda items email,
>>
>> I am not sure if my earlier email successfully get into REGEXT mailing
>> list, in case it doesn't, may I ask your guidance / faciliation in how to
>> properly apply for agenda item for IETF 121 for the REGEXT wg?
>>
>> Victor
>>
>> -- Forwarded message -
>> From: Victor Zhou 
>> Date: Thu, Oct 17, 2024 at 2:59 PM
>> Subject: Re: [regext] Call for agenda items IETF 121
>> To: 
>>
>>
>> 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] slides for Monday Tech Working Session

[James Galvin]

This is a reminder from your Chairs to get your slides submitted for the 
discussion tomorrow.

We have 7 presenters and only 2 slide decks submitted.

It’s especially important for the 2 presenters who are talking about topics for 
which there is no Internet Draft.  If you expect working group members to be 
prepared for discussion then you should have provided slides before today.

This is our second time with two meetings where one is a technical working 
session.  The Chairs have not been strict about slides but we didn’t have a 
problem last time.  We certainly don’t want the state we’re in right now to 
become a habit so if we continue with two meetings in the future the Chairs 
will be more strict to ensure we all have a proper opportunity to be prepared.

Please do login in to the datatracker and submit your slides directly.

Thanks!

Jim

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

[regext] Re: RDAP versioning draft feedback

[Gould, James]

Jasdip,

Thank you for your review and feedback.  I provide responses to your feedback 
embedded below, prefixed with “JG:”.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

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

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

Verisign.com

From: Jasdip Singh 
Date: Friday, November 1, 2024 at 6:28 PM
To: "regext@ietf.org" 
Subject: [EXTERNAL] [regext] RDAP versioning draft feedback


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 James, Daniel, Mario,

I read the latest draft and to help tighten this spec, have few higher-level 
comments.

VCHAR use:

In section 3.1, the ABNF for “versioning” in “extension-version-identifier” is 
“["-" 1*VCHAR]”. Since the extension version identifiers could be passed in the 
“extensions” parameter of the RDAP-X media type in the HTTP accept and/or 
content-type headers, it would be safer to constrict them to what’s allowed in 
those headers. E.g., for the accept header, a parameter value (per section 
5.6.6 of RFC 9110) is “parameter-value = ( token / quoted-string )” where 
“token” is any VCHAR minus the delimiters (section 5.6.2 of RFC 9110). The 
reason AFAIU is to help prevent injection attacks. From security angle, good to 
address this.

JG – Yes, the versioning rule could be updated to match the tchar rule in 
section 5.6.2 of RFC 9110.  The only exception may be to remove the use of ‘-‘, 
since that separator is used between the extension-identifier and the 
versioning rules.  How about the following:

extension-version-identifier = identifier versioning
identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifier
versioning = ["-" 1*versioning-char]
versioning-char = "!" / "#" / "$" / "%" / "&" / "'" / "*"
 / "+" / "." / "^" / "_" / "`" / "|" / "~"
 / DIGIT / ALPHA

In reviewing the ABNF, I noticed the versioning rule for the Semantic Extension 
Version Identifier, in Section 4.2.1, needed the ‘;’ removed.  It should be:

versioning = "-"  major "." minor


Rationale for versioning:

Section 1 says, “The RDAP Conformance values are identifiers with no standard 
mechanism to support structured, machine-parseable version signaling by the 
server.” It’d be good to elaborate with usage scenarios where such structured 
versioning is a value-add for clients beyond what the opaque (no inner meaning) 
extension identifiers from STD 95 afford. Let’s say an extension is “foo1”, 
then “foo99”, and later “foo2” in terms of “versions”. The server announces its 
support for these non-structured extensions, say, on its web site or through 
the “rdapConformance” member in a /help response, and the clients can then 
negotiate a particular non-structured version of this extension using the 
standard HTTP content negotiation methodology (e.g., using the RDAP-X media 
type). In the spirit of what-not-to-do, it is fair for a client to ask: Why 
should I go through the overhead of processing the “versioning_help” member? 
What value-add does it get me? Is it in some way a better discovery and/or 
negotiation method for RDAP extensions? Would be good to beef up the rationale 
for structured versioning.

JG – We need to ensure that RDAP-X supports the extension version identifier as 
well, so there should be no variance between the versioning extension and the 
RDAP-X extension.  We can add more rationale in Section 2 “Semantic 
Versioning”, where a server could support multiple versions of an extensions 
that are signaled as related.  For the versioning extension itself, there have 
been multiple versions of it that are not structurally different and not 
backward compatible, with the latest version being “versioning-0.3”.  Other 
RDAP extensions could leverage semantic versioning during development to 
encourage implementation with version isolation and with clear relationship 
between the extension version identifiers.  Do you believe that we should look 
to add the concept of relationships between opaque version identifiers?

RDAP-X way:

To help client implementors, beside the “versioning” query parameter examples, 
would be good to include one or more RDAP-X examples.

JG – You mean that you want to see examples like what is included in 
draft-ietf-regext-rdap-x-media-type, such as:

application/rdap-x+json;extensions="rdap_level_0 fred"

and

application/rdap-x+json;extensions="semantic_ext1-0.1 opaque_ext2"

/help path segment:

Section 3.1.6 of RFC 9082 says, “The help path segment can be used to request 
helpful information (command syntax, terms of service, privacy policy, 
rate-limiting policy, supported authentication methods, supported extensions, 
technical support contact, etc.) from an RDAP server.” Using a new “versioning” 
query parameter for /help, is this spec updating RFC 9082? Not sure but thought 
of asking.

JG – No, I don’t see the

[regext] Re: slides for Monday Tech Working Session

[James Galvin]

Many thanks to the presenters who have uploaded slides for tomorrow.

All but one are now present.  WG members may wish to update their downloads and 
review slide decks.

Jim


On 3 Nov 2024, at 14:48, James Galvin wrote:

> This is a reminder from your Chairs to get your slides submitted for the 
> discussion tomorrow.
>
> We have 7 presenters and only 2 slide decks submitted.
>
> It’s especially important for the 2 presenters who are talking about topics 
> for which there is no Internet Draft.  If you expect working group members to 
> be prepared for discussion then you should have provided slides before today.
>
> This is our second time with two meetings where one is a technical working 
> session.  The Chairs have not been strict about slides but we didn’t have a 
> problem last time.  We certainly don’t want the state we’re in right now to 
> become a habit so if we continue with two meetings in the future the Chairs 
> will be more strict to ensure we all have a proper opportunity to be prepared.
>
> Please do login in to the datatracker and submit your slides directly.
>
> Thanks!
>
> Jim

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