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

2024-10-18 Thread Hollenbeck, Scott 
> -Original Message-
> From: Andrew Newton (andy) 
> Sent: Thursday, October 17, 2024 2:10 PM
> To: James Galvin 
> Cc: regext@ietf.org
> Subject: [EXTERNAL] [regext] Re: normative language and references in draft-
> ietf-regext-delete-bcp
> 
> 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.
> 
> This is done. In addition, I noted the informative reference to RFC
> 3915 has changed to normative.

[SAH] Andy, I'd like to suggest one addition to the added text. You added this:

"Additionally, there were discussion regarding the use of BCPs to suggest
practices that are not know to be practiced. In other words, how can a BCP 
normatively
require a practice that has not been observed because it is not a "current" 
practice."

When this came up on-list, I noted that this type of situation is addressed in 
RFC 2026:

"A BCP document is subject to the same basic set of procedures as standards 
track documents and thus is a vehicle by which the IETF community can define 
and ratify the community's best current thinking on a statement of principle or 
on what is believed to be the best way to perform some operations or IETF 
process function."

Note where it says "what is believed to be the best way to perform some 
operations or IETF process function".

Found here:

https://mailarchive.ietf.org/arch/msg/regext/bNqpUibJuzZMB42APSv_tsnFxNo/

Would you please add something like "It was noted that RFC 2026 permits BCPs to 
describe what is believed to be the best way to perform some operations or IETF 
process function" to the end of the new text.

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

[regext] Re: I-D Action: draft-ietf-regext-rdap-geofeed-08.txt

2024-10-18 Thread Jasdip Singh 
Hi.

This version incorporates Gavin’s shepherd feedback.

Thanks,
Jasdip

From: internet-dra...@ietf.org 
Date: Friday, October 18, 2024 at 3:40 AM
To: i-d-annou...@ietf.org 
Cc: regext@ietf.org 
Subject: [regext] I-D Action: draft-ietf-regext-rdap-geofeed-08.txt
Internet-Draft draft-ietf-regext-rdap-geofeed-08.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.

   Title:   An RDAP Extension for Geofeed Data
   Authors: Jasdip Singh
Tom Harrison
   Name:draft-ietf-regext-rdap-geofeed-08.txt
   Pages:   13
   Dates:   2024-10-18

Abstract:

   This document defines a new Registration Data Access Protocol (RDAP)
   extension, "geofeed1", for indicating that an RDAP server hosts
   geofeed URLs for its IP network objects.  It also defines a new media
   type and link relation type for the associated link objects included
   in responses.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-geofeed-08.html

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

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] Re: Question regarding client identifiers and password requirement of RFC-5730

2024-10-18 Thread Victor Zhou 
Thank you Scott!

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



On Fri, Oct 18, 2024 at 5:18 AM Hollenbeck, Scott 
wrote:

> RFC 8807 describes login improvements. There haven’t been ay other
> attempts to extend the protocol that I’m aware of.
>
>
>
> Scott
>
>
>
> *From:* Victor Zhou 
> *Sent:* Thursday, October 17, 2024 5:37 PM
> *To:* regext@ietf.org
> *Cc:* Hollenbeck, Scott 
> *Subject:* [EXTERNAL] Question regarding client identifiers and password
> requirement of RFC-5730
>
>
>
> *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.
>
> Dear REGEXT working group, cc: Scott
>
>
>
> A little while ago, we sent you an email about AuthCodeSEC(
> https://www.mail-archive.com/regext@ietf.org/msg05966.html
> 
> )
>
>
>
> We are looking into authentication model and we found that in Section
> 2.9.1.1 of RFC-5730(https://www.rfc-editor.org/rfc/rfc5730
> ,
> page 20) it reads
>
>
>
> *2.9.1.1 
> .
>   EPP  Command*
>
> ...
>
>
>
>A client identifier and initial password MUST be created on the
>
>server before a client can successfully complete a  command.
>
>The client identifier and initial password MUST be delivered to the
>
>client using an out-of-band method that protects the identifier and
>
>password from inadvertent disclosure.
>
>
>
> This design assumes a client-server authentication with a pre-established
> password saved in the server.
>
>
>
> *Question*: Is there any newer RFC that brings into / extends EPP to
> adopt more sophisticated login / authentication schemes? For example if a
> server announces a public-key authentication algorithm and relevant
> parameter it chose, a client can login with a signature given a server
> challenge.
>
>
>
> Thank you!
>
>
> Victor Zhou,
>
> CEO & founder of Namefi
> ,
>  tokenizing
> domain names for trading, DeFi and future Internet. https://namefi.io
> 
>
>
>
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: Call for agenda items IETF 121

2024-10-18 Thread Victor Zhou 
Greatly appreciated, James, for your detailed discussion. Yes, we are aware
of
RFC-9154 and are honored to have a response from you, the author of it, and
expressed your interest.

We are thinking about proposing two main things to further secure the
transfer:
1. Using a cryptography public-key authentication algorithm enabling
validation
   of the authenticity of the source of approval from the Name Holder or
   someone the Name Holder approves, such as a Registrar.
2. Ensuring specific and more directed approval of the transfer of a
domain, for example,
   to which new Name Holder, identified by a public key, the domain should
be
   transferred.

We will soon publish a newer version on
https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md to
further discuss our proposal goals and how to achieve that.

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



On Fri, Oct 18, 2024 at 4:57 AM Gould, James  wrote:

> Victor,
>
>
>
> You’re probably aware of the Secure Authorization Information for Transfer
> RFC 9154 (https://datatracker.ietf.org/doc/html/rfc9154), which is
> focused on making the authinfo secure by having it short-lived, stored
> securely when needed (e.g., null outside a transfer process or stored as a
> 1-way hash during a transfer process in the registry), and use of a strong
> random authinfo value.  I view aspects of RFC 9154 being applicable to
> authinfo extensions as well, but it had not been considered.
>
>
>
> The Domain Name Mapping (RFC 5731) does include an extension point for the
> authinfo, using the  element if you have a
> different authinfo format to use.  I haven’t seen an attempt the extend the
> authinfo format, but there is an extension point, and there is support for
> the authinfo extension in the Verisign EPP SDK (
> https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks),
> but it hasn’t been tested with the lack of authinfo extensions.  I believe
> the authinfo extension would need to be signaled in the EPP greeting and
> the EPP login command, using the extension URI in a  element.
> Below is a potential example:
>
>
>
>
>
>
>
>  
>
>
>
>  
>   xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>
>example.com
>
>2
>
>
>
>  ns1.example.net
>
>  ns2.example.net
>
>
>
>jd1234
>
>sh8013
>
>sh8013
>
>
>
> * *
>
> *   
> *
> 
> xmlns:authcodesec="urn:ietf:params:xml:ns:epp:authcodesec-0.1">*
>
> *   TBD*
>
> *   *
>
> **
>
>
>
>  
>
>
>
>ABC-12345
>
>  
>
>
>
>
>
> The EPP greeting and the EPP login would include:
>
>
>
>S:  
>
>S:urn:ietf:params:xml:ns:epp:authcodesec-0.1
>
>S:  
>
>
>
> The EPP login command would include:
>
>
>
>C:
>
>C:urn:ietf:params:xml:ns:epp:authcodesec-0.1
>
>C:
>
>
>
> I’m interested in what enhancements you propose.
>
>
>
> Thanks,
>
>
>
> --
>
>
>
> JG
>
>
> [image: cid87442*image001.png@01D960C5.C631DA40]
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Victor Zhou 
> *Date: *Thursday, October 17, 2024 at 5:59 PM
> *To: *"regext@ietf.org" 
> *Subject: *[EXTERNAL] [regext] Re: Call for agenda items IETF 121
>
>
>
> *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.
>
> 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
>

[regext] Re: Question regarding client identifiers and password requirement of RFC-5730

2024-10-18 Thread Hollenbeck, Scott 
RFC 8807 describes login improvements. There haven’t been ay other attempts to 
extend the protocol that I’m aware of.



Scott



From: Victor Zhou 
Sent: Thursday, October 17, 2024 5:37 PM
To: regext@ietf.org
Cc: Hollenbeck, Scott 
Subject: [EXTERNAL] Question regarding client identifiers and password 
requirement of RFC-5730



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.

Dear REGEXT working group, cc: Scott



A little while ago, we sent you an email about 
AuthCodeSEC(https://www.mail-archive.com/regext@ietf.org/msg05966.html)



We are looking into authentication model and we found that in Section 2.9.1.1 
of 
RFC-5730(https://www.rfc-editor.org/rfc/rfc5730,
 page 20) it reads



2.9.1.1.
  EPP  Command
...

   A client identifier and initial password MUST be created on the
   server before a client can successfully complete a  command.
   The client identifier and initial password MUST be delivered to the
   client using an out-of-band method that protects the identifier and
   password from inadvertent disclosure.



This design assumes a client-server authentication with a pre-established 
password saved in the server.



Question: Is there any newer RFC that brings into / extends EPP to adopt more 
sophisticated login / authentication schemes? For example if a server announces 
a public-key authentication algorithm and relevant parameter it chose, a client 
can login with a signature given a server challenge.



Thank you!




Victor Zhou,

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



___
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

2024-10-18 Thread Andrew Newton (andy) 


On 10/18/24 08:15, Hollenbeck, Scott wrote:
Would you please add something like "It was noted that RFC 2026 
permits BCPs to describe what is believed to be the best way to 
perform some operations or IETF process function" to the end of the 
new text.

Scott



Good addition regarding the WG discussion on this topic. This was added.


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

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

2024-10-18 Thread Andrew Newton (andy) 


On 10/17/24 08:05, Gould, James wrote:

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.


Sorry. I think I missed that. Yes, we need to be more specific about 
that the version identification information, and I agree with you that 
it should not change behavior.


I also see that we mistakenly say the version information is "prepended" 
in Section 3.1.5. That needs to be corrected.



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.



With regard to the versioning draft, could we explore expanding the 
scope of the metadata to include other server information, such as 
server software version, server identification (similar to NSID), and 
other information that can be used for debugging purposes? For those of 
us who do troubleshooting of RDAP services, this would be very helpful.


-andy

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

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

2024-10-18 Thread Gould, James 
Andy,

I'll pull my prior feedback and recommendations to help with the updates make 
draft-ietf-regext-rdap-versioning work with draft-ietf-regext-rdap-x-media-type 
compatible.  I believe we can really streamline the two drafts by working 
together to merge them.  Expanding the meta-data in the versioning extension 
help response sounds interesting.  Provide some proposals and let's see what 
makes sense. 

Thanks,

-- 

JG 



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


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

Verisign.com  




On 10/18/24, 4:34 PM, "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. 


On 10/17/24 08:05, Gould, James wrote:
> 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.


Sorry. I think I missed that. Yes, we need to be more specific about 
that the version identification information, and I agree with you that 
it should not change behavior.


I also see that we mistakenly say the version information is "prepended" 
in Section 3.1.5. That needs to be corrected.


> 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.




With regard to the versioning draft, could we explore expanding the 
scope of the metadata to include other server information, such as 
server software version, server identification (similar to NSID), and 
other information that can be used for debugging purposes? For those of 
us who do troubleshooting of RDAP services, this would be very helpful.


-andy





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

[regext] I-D Action: draft-ietf-regext-rdap-geofeed-08.txt

2024-10-18 Thread internet-drafts 
Internet-Draft draft-ietf-regext-rdap-geofeed-08.txt is now available. It is a
work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.

   Title:   An RDAP Extension for Geofeed Data
   Authors: Jasdip Singh
Tom Harrison
   Name:draft-ietf-regext-rdap-geofeed-08.txt
   Pages:   13
   Dates:   2024-10-18

Abstract:

   This document defines a new Registration Data Access Protocol (RDAP)
   extension, "geofeed1", for indicating that an RDAP server hosts
   geofeed URLs for its IP network objects.  It also defines a new media
   type and link relation type for the associated link objects included
   in responses.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-geofeed-08.html

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

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