Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

[Eric Skoglund]

To add my 2 cents I agree with Scott here given what the spec says. We've 
(Swedish internet foundation) interpreted it in our implementation to mean that 
we shouldn't
allow the change to go through.

// Eric Skoglund

From: regext  on behalf of Hollenbeck, Scott 

Sent: 02 December 2022 15:13
To: michael.baul...@knipp.de ; regext@ietf.org 

Subject: Re: [regext] CDS/CDNSKEY vs. EPP update prohibited

> -Original Message-
> From: regext  On Behalf Of Michael Bauland
> Sent: Friday, December 2, 2022 8:55 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] CDS/CDNSKEY vs. EPP update prohibited
>
> 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,
>
> On 02.12.2022 14:07, Gould, James wrote:
> > Michael,
> >
> > The prohibited statuses apply to client requests, which matches Case 2.
> > The
> prohibited statuses can apply to client requests via multiple channels
> (e.g., EPP
> or Web UI).  The prohibited statuses don't apply to server actions (e.g.,
> auto
> renew, transitioning RGP statuses).  Use of CDS/CDNSKEY records to signal a
> server-side change is an interesting case, where does posting CDS/CDNSKEY
> records represent a client request that is processed by the server
> asynchronously?  I view the CDS/CDNSKEY as a new operation (e.g., DNSSEC
> automation update), supported by IETF RFCs, that does not apply to the
> existing
> EPP prohibited statuses.  All domain changes come down to an update, but EPP
> included prohibited statuses on a per operation / command basis.
> >
> > I would then define Case 3, where CDS/CDNSKEY records represent is a new
> client operation that does not apply to the existing EPP prohibited
> statuses.  If
> we did want to prohibit this new operation via EPP, then a new prohibited
> status would be warranted.
>
> I tend to agree. Changing the DNSSEC data here is not an operation
> requested/initiated by the client (i.e., registrar), but it's something the
> server
> (registry) does, because it got triggered via the DNS. For this reason the
> clientUpdateProhibited flag should be ignored.

[SAH] You can't assume that "client" always means "registrar". That's
precisely why you don't see the word "registrar" in the specification. Note,
also, what 5731 actually says about the status (the other RFCs say the same
thing):

"Status values that can be added or removed by a client are prefixed with
"client"."

It's about who can manage the status value. It's not about who can perform the
update.

"Requests to update the object (other than to remove this status) MUST be
rejected."

Again, there's nothing here about *who* is performing the update. This use
case is covered by the existing specification text.

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] Fwd: Idea about AuthCodeSEC: use Public Key Cryptography for AuthCode

[Eric Skoglund]

Hi Victor.

We at .se and .nu recently changed our authcode implementation and for that we 
did have a look around to see what other registries were doing.
I don't think we came across anyone looking at a PKI-based approach and to 
second what Scott said such an approach would probably find it
hard to get any traction.

Here is a talk we did at ICANN78 giving some information about the needs we and 
some other registries have regarding the
authcodes, perhaps giving some idea on why that would be: 
https://github.com/johanix/iis-talks/blob/main/erics/icann78-authcodes/talk.pdf


// Eric
The Swedish Internet Foundation


From: regext  on behalf of Zainan Victor Zhou 

Sent: 24 March 2024 20:21
To: regext@ietf.org 
Cc: shollenb...@verisign.com ; z...@namefi.io 

Subject: [regext] Fwd: Idea about AuthCodeSEC: use Public Key Cryptography for 
AuthCode

Scott, that's very helpful, thank you! Yes I notice that EPP (RFC 5730) was 
intentionally extendable. It's very helpful that you point to me that Section 
4.2 lays the schema that defines authorization information.
I will look into how to leverage existing pwAuthInfoType and extAuthInfoType. 
Let me send this email to REGEXT  -- Victor

(Resending with my email that I use for IETF)


Hi dear REGEXT wg,

TL;DR: are there existing efforts to bring public key authentication to EPP 
that leverage RFC 5730's extendability?
Is this working group the best place to start the conversation about existing 
effort?

The closest related effort in IETF I could found was
- EPPEXT working group that was concluded in 2016 
https://datatracker.ietf.org/wg/eppext/about/
- RFC 9154 Extensible Provisioning Protocol (EPP) Secure Authorization 
Information for Transfer https://datatracker.ietf.org/doc/rfc9154/  which uses 
a short lived cryptographic hash

If there are existing standards, I love to learn more and put that into our 
implementation.
If there were no existing effort, here is an early draft 
https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md
 and I would love to see if anyone is interested in participate in future 
discussion of a possible RFC and maybe co-author?

Victor Zhou
z...@namefi.io (work) / z...@zzn.im 
(personal)

On Sun, Mar 17, 2024 at 3:58 PM Hollenbeck, Scott 
mailto:shollenb...@verisign.com>> wrote:

Thank for the note, Victor. I’m not aware of anyone who has extended EPP’s 
authorization information data structures, though the ability to do so has 
always been available. Note this text from Section 2.9.3.4 of RFC 5730:



“The type of authorization information required is object-specific; passwords 
or more complex mechanisms based on public key cryptography are typical.”



We defined a password-based authorization information approach for domain 
objects because it was felt to be sufficient and secure as long as other 
protocols were used to protect the data while in transit. EPP requires TLS, for 
example, so the authorization information is never exchanged without encryption 
protection. In practice, passwords are NOT received from end-users/registrants 
and stored; they’re more commonly generated on-demand as a result of a domain 
transfer request. They’re short-lived and the risk of exposure is actually 
quite low. I haven’t heard of any issues associated with compromised 
authorization information being used to request a fraudulent transfer. If 
you’re aware of any documented “AuthCode stealing or disputes” I’d be 
interested in hearing about them. I’m not confident that the domain industry 
would be interested in implementing and operating a PKI-based approach given 
that the password approach has been working reliably for more than 20 years. 
There would need to be a significant value proposition for registries and 
registrars to switch.



Having said that, I designed EPP in a way that allows for specification of 
other approaches. Section 4.2 of RFC 5730 includes the schema that defines 
authorization information. Note the “pwAuthInfoType” and the "extAuthInfoType" 
type definitions. "extAuthInfoType" can be used as a “hook” to define a new 
type. Given that the capability exists, I’d suggest that you send a note to the 
IETF REGEXT working group mailing list asking if anyone is interested in the 
possibility of defining an extension for a new PKI-based authorization 
information type. You’d be better of measuring people’s interest in the topic 
before you invest a lot of time working on a proposal.



I hope t

[regext] Re: WGLC: draft-ietf-regext-epp-ttl-08

[Eric Skoglund]

Based on the call to action in the meeting yesterday to get involved I'll add 
my +1 as well (and +1 to the changes proposed by James).

// Eric Skoglund, The Swedish Internet Foundation (.se & .nu)


From: regext  on behalf of Gould, James 

Sent: 06 May 2024 14:30
To: mario.loffredo=40iit.cnr...@dmarc.ietf.org 
; gal...@elistx.com 
; regext@ietf.org 
Subject: Re: [regext] WGLC: draft-ietf-regext-epp-ttl-08


I support publication, so +1.



Upon a re-review of -08, and I have the following nit feedback:



Section 1.2.1.2 “Supported DNS record types”



"This eliminates the need to update this document in the event that new DNS 
records that exist above a zone cut (Section 7 of [RFC9499]) see is 
specified.".  I believe that "see" needs to be removed, where it would read 
"...above a zone cut (Section 7 of [RFC9499]) is specified" or "...above a zone 
cut (see Section 7 of [RFC9499]) is specified".



Address the multiple which’s in the paragraph below, such as:



“A server that receives a  or  command, which includes an 
invalid DNS record type, MUST respond with a 2004 "Parameter value range" 
error.”





Section 1.2.1.2.1 "Glue records"



Update second paragraph to remove the multiple which's, such as:



“A server supporting host objects which receives a command that attempts to set 
TTL values for A and  records on a domain object MUST respond with a 2004 
"Parameter value range" error.”



Section 2.1.1 “EPP  command”



Add comma to be consist to the Default Mode bullet, such as:



“The Policy Mode (Section 
2.1.1.2<https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl#policy-mode>),
 which …“



Section 2.1.1.1 “Default Mode”



Update the first paragraph by addressing the run on sentence and use double 
quotes for the attributes and values (“0” and “false”), such as:



“If a server receives an  command for a domain or host object which 
includes a  element with a “policy” attribute value of “0” or 
“false”, then the EPP response MUST contain  elements for all DNS 
record types that have non-default TTL values. These elements MUST NOT have the 
“min”, “default” and “max” attributes.”



Section 2.1.1.2 “Policy Mode”



Update the first paragraph by addressing the run on sentence and use double 
quotes for the attributes and values (“1” and “true”), such as:



“If a server receives an  command for a domain or host object which 
includes a  element with a “policy” attribute value of “1” or “true”, 
then the EPP response MUST contain  elements for all supported DNS 
record types, irrespective of whether those record types are in use by the 
object in question.”  These elements MUST have the “min”, “default” and “max” 
attributes.”



Section 5.1 “Operational impact of TTL values”



Revise the first paragraph for readability, such as:



“Domain registry operators must consider the balance between the registrant 
desire for domain changes to be visible in the DNS quickly, and the increased 
DNS query traffic that short TTLs can bring. Historically, registry operators 
have used a global TTL value for all delegations within their zones, which 
could then be tuned to an optimum value.”



Thanks,





--



JG







James Gould

Fellow Engineer

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>









On 5/6/24, 3:27 AM, "regext on behalf of Mario Loffredo" 
mailto:regext-boun...@ietf.org> on behalf of 
mario.loffredo=40iit.cnr...@dmarc.ietf.org 
<mailto:40iit.cnr...@dmarc.ietf.org>> 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.





+1





Mario





Il 29/04/2024 16:27, James Galvin ha scritto:

> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Proposed 
> Standard:

>

> Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) 
> values

> https://secure-web.cisco.com/1c1FkOdAKZ0pc8IHVuo4T0I5emiofMuSpTU--2s4xgNy06ipCF6iplze1N6Lt1ZW2FZ9y_CrkZaKrecsE7C6PKABKg9DciQ-01ZbJ1SRYlci293K7rKSFSxftmPGCFXDAGSYVWLfZmtQa68W2wS3k_aZ04bbVHBLMcYuAVRguqe9zQPz9TdbRuBGKTW-Slt8Ebd9HwZRRbRVn_h9YKPE9iWBrofBCMRVbcAmE9t0HJv1060Qe_bwZBUCeSkV2b44GNVF4epB4DJUQz7grrvEUNxBQiSEZnaK0l8aHRzSEXew/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-epp-ttl%2F08%2F
>  
> <https://secure-web.cisco.com/1c1FkOdAKZ0pc8IHVuo4T0I5emiofMuSpTU--2s4xgNy06ipCF6iplze1N6Lt1ZW2FZ9y_CrkZaKrecsE7C6PKABKg9DciQ-01ZbJ1SRYlci293K7rKSFSxftmPGCFXDAGSYVWLfZmtQa68W2wS3k_aZ04bbVHBLMcYuAVRguqe9zQPz9TdbRuBGKTW-Slt8Ebd9HwZRRbRVn_h9YKPE9iWBrofBCMRVbcAmE9t0HJv1060Qe_bwZBUCeSkV2b44GNVF4epB4DJUQz7grrvEUNxBQiSEZnaK0l8aHRzSEXew/https%3A%2F%2Fdatatrack

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[Eric Skoglund]

Did a quick readthrough this evening, found some minor nits.

In the paragraph:

"Some domain registrars, acting as EPP clients, have rename host
  objects to subdomains of "as112.arpa," such as "empty.as112.arpa"
  [risky-bizness-irtf].  This practice has been observed in use."

"rename" should be "renamed" and for "as112.arpa," the comma should be outside 
the quotes.

In 5.2.2.1.5.2.:

"since there is no limit with the number of associations to delegated domains."

Change the "with" to either "to" or "on".

"since there is no limit to the number of associations to delegated domains."

IMHO the headings for

5.1.3.  Renaming Observed Practices
5.1.4.  Renaming Potential Practices
5.2.1.  Deletion Observed Practices
5.2.2.  Deletion Potential Practices

Reads a bit clunky to me, how about dropping the "Renaming/Deletion" or 
conversely something like "Observed Practices for Renaming" etc?

Regards,
Eric




From: Carroll, William 
Sent: 21 June 2024 19:09
To: kowa...@denic.de ; 
shollenbeck=40verisign@dmarc.ietf.org 
; regext@ietf.org 
Subject: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

Pawel,
I've uploaded a version 04 of the doc with the practices organized into 
observed and potential subsections. We didn't want multiple listings of best 
current practices in both sections 5 and 6. Hopefully this version is clear 
enough.
Thanks!
Bill

On 6/19/24, 6:37 AM, "kowa...@denic.de " 
mailto:kowa...@denic.de>> wrote:


Hi Bill,


TBH I didn't know of the structure in 00 and I must admit it's a way
more straightforward to follow, especially with "practices to avoid".
This determination was not that obvious to me when reading the current
version with each method having Benefits/Detriments section. And I think
this is the value I would expect from BCP.


Just thinking, that maybe the best of both, taking into account that
Section 5 only hast 2 Subsections, would be to have the split "practices
to avoid," "best current practices," and "potential practices" under
each of the subsections? This would keep similar practices together and
still be very straightforward as to what is to be avoided and what is
experimental.


Kind Regards,


Pawel




On 18.06.24 21:25, Carroll, William wrote:
> Pawel,
>
> Thanks for the feedback and for catching the mismatch between the abstract 
> and content.
>
> About the suggestion to split section 5, the 00 version of the document split 
> out practices into "practices to avoid," "best current practices," and 
> "potential practices" sections. We found that organization made it difficult 
> to keep track of and compare similar practices across the sections (it 
> required a lot of jumping back and forth), so we reorganized it to the major 
> categories ("renaming to sacrificial hosts" and "deletion of hosts"). I would 
> prefer to keep the current organization but am open to other ideas.
>
> Thanks,
>
> Bill
>
> On 6/18/24, 1:43 PM, "Hollenbeck, Scott" 
>    >> 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.
>
>
> Section 5 already identifies the practices as observed or not, but we can add 
> clarity by splitting it into two sections. We can also update the abstract. 
> Thanks for the feedback.
>
>
> Scott
>
>
>> -Original Message-
>> From: kowa...@denic.de  > > mailto:kowa...@denic.de> 
>> >>
>> Sent: Tuesday, June 18, 2024 12:03 PM
>> To: Hollenbeck, Scott >  > >>; regext@ietf.org 
>>  >
>> Subject: [EXTERNAL] Re: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-
>> 03
>>
>> Hi Scott,
>>
>> Splitting Section 5 into "Current Practices" and "Proposed experimental
>> Practices" would offer a lot of more clarity in this respect.
>>
>> Also abstract is not mentioning proposed practices:
>>
>> "This document describes best practices to delete domain and host objects
>> that reduce the risk of DNS resolution failure and maintain client-server 
>> data
>> consistency."
>>
>> I would change to:
>> "This document describes best current practices as well as proposes new
>> experimental practices to delete domain and host objects that reduce the risk
>> of DNS resolution failure and maintain client-server data consistency.
>>
>> Kind Regards,
>>
>> Pawel
>>
>> On 18.06.24 17:46, Hollenbeck, Scott wrote:
>>> Pawel, the document already describes known practices, their issues, and
>> those that are proposed, along with analysis of how they're thought to be
>> better. Wha

[regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

[Eric Skoglund]

+1

From: James Galvin 
Sent: 24 June 2024 15:26
To: REGEXT Working Group 
Subject: [regext] Re: WGLC: draft-ietf-regext-epp-delete-bcp-03

The Chairs have decided to extend this WGLC last call for two weeks, one more 
week from the date of this message.  There has only been on indication of 
support and two different threads discussing some minor changes.  We would like 
these discussion to resolve and for there to be more indications of support for 
this document.

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 1 July 2024.

Thanks,

Antoin and Jim


On 3 Jun 2024, at 10:56, James Galvin wrote:

> The document editors have indicated that the following document is ready for 
> submission to the IESG to be considered for publication as a Best Current 
> Practice:
>
> Best Practices for Deletion of Domain and Host Objects in the Extensible 
> Provisioning Protocol (EPP)
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-delete-bcp/03/
>
> Please indicate your support or no objection for the publication of this 
> document by replying to this message on list (a simple “+1” is sufficient).
>
> If any working group member has questions regarding the publication of this 
> document please respond on the list with your concerns by close of business 
> everywhere, Monday, 17 June 2024.
>
> If there are no objections the document will be submitted to the IESG.
>
> The Document Shepherd for this document is Andy Newton.
>
> Thanks,
>
> Antoin and Jim
> REGEXT WG Co-Chairs

___
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] Clarifications on server error responses in EPP over HTTP (draft-loffredo-regext-epp-over-http )

[Eric Skoglund]

After Jim Goulds presentation on implementing EoH and EoQ I was inspired to 
start hacking on the two protocols in our own EPP server implementation, while 
doing so, some questions about EoH popped up.

In the EoH draft there is a couple of MUSTs for the client when sending a 
request:

 - The GET request MUST include "application/epp+xml" (Appendix B of [RFC5730]) 
in the "Accept" HTTP   header.
 - An EPP client MUST send all commands as HTTP POST requests (Section 6.4 of 
[RFC9110]).
 - Each POST request MUST include the HTTP session identifier in the "Cookie" 
header and "application/epp+xml" in the "Accept" header.

The current draft provides the following for dealing with misbehaving clients.

  Servers MUST NOT use HTTP return codes to signal clients about the
  failure of the EPP commands.  The HTTP code 200 MUST be used for both
  successful and unsuccessful EPP requests.  Servers MUST use HTTP codes
  to signal clients about the failure of the HTTP requests.

  Servers MUST return an EPP 2002 response (i.e.  Command use error) if
  the client issues an EPP command with either an empty or an invalid
  HTTP session identifier.

The only thing covered in detail is what should happen if an EoH server 
receives a request without a session identifier. I think it would be useful for 
the spec to be clear on what a server should return if any
of the requirements above are broken.

My 2 cents on what a server should do:

- A request with the correct Accept header but wrong HTTP method (say we get a 
PATCH instead of a POST): A server MUST return a 405 HTTP status code
- A request with the incorrect Accept header: A server MAY return a 406 HTTP 
status code (I guess one could think of a server that handles EPP and other 
stuff so MAY is probably best).

// Eric
The Swedish Internet Foundation
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: CALL FOR ADOPTION: draft-yao-regext-epp-quic and draft-loffredo-regext-epp-over-http

[Eric Skoglund]

Hi Jim,

I support the adoption of both. I'm willing to contribute and review text.

// Eric

From: James Galvin 
Sent: 03 February 2025 15:05
To: Registration Protocols Extensions 
Subject: [regext] CALL FOR ADOPTION: draft-yao-regext-epp-quic and 
draft-loffredo-regext-epp-over-http

Continuing our potential adoption of new documents, as previously discussed the 
next two documents will be taken together.  The suggestion is to advance them 
together, although if these are adopted the working group can choose to advance 
them separately.

This is a formal adoption request for both:

Extensible Provisioning Protocol (EPP) Transport over QUIC
https://datatracker.ietf.org/doc/draft-yao-regext-epp-quic/

Extensible Provisioning Protocol (EPP) Transport over HTTPS
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/

Please review these drafts to see if you think they are suitable for adoption 
by REGEXT and reply to this message on the list, clearly stating your view.  
Optionally indicate if you are willing to contribute text, review text, or be a 
document shepherd.

This Call For Adoption will close on Sunday, 16 February 2025.

If there are no objections, the chairs will consider these documents adopted.

Thanks,

Your REGEXT co-chairs Antoin and Jim

___
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: Experimental Extensions (was Re: ONE WEEK REVIEW of FINAL proposed revised charter for REGEXT)

[Eric Skoglund]

+1 from me as well

// Eric Skoglund

From: Andrew (andy) Newton 
Sent: 29 April 2025 15:22
To: James Galvin ; REGEXT Working Group 
Subject: [regext] Experimental Extensions (was Re: ONE WEEK REVIEW of FINAL 
proposed revised charter for REGEXT)

Hi all,

The current wording of the proposed charter excludes the working group from 
working on experimental extensions, which has been offered as a solution to 
move some documents forward in the wg. IMHO, disallowing experimentation runs 
counter to the "running code" nature of IETF work and takes away from the tools 
the working group has to create interoperable specifications.

The proposed charter has the following paragraphs:

 Proprietary documented extensions and individual submissions of 
informational or
 experimental extensions will follow the expert review process as 
described in the
 appropriate extensions registry. These extension documents will not be 
part of the
 REGEXT working group work or milestones. The working group may discuss 
or advise
 on these documents.

Extensions that seek standards track status can be suggested for WG
adoption. If accepted by the working group then the development of the
standard may proceed.

I propose the following change to the second paragraph:

Extensions that seek IETF consensus can be suggested for WG
adoption. If accepted by the working group then the development of the
standard may proceed.

This change does not exclude experimental status if the working group decides 
that is a good path for a document. It also draws the distinction between those 
documents accepted by the working group in contrast to the proprietary 
extensions mentioned in the first paragraph.

What do people think?

-andy, not the responsible AD for this wg

On 4/28/25 09:48, James Galvin wrote:
> Two weeks ago the Chairs distributed a proposed revised charter and opened a 
> review period for the working group.  That review period closed yesterday.  
> Many thanks to those who took the time to review the proposal.
>
> Today begins a one week review of the final, proposed revised charter.  
> Everyone should have access and can still leave comments or suggest changes 
> to the text.  The review closes on Sunday, 4 May 2025, close of business 
> everywhere.
>
> Here is the current, FINAL proposed revised charter:
>
> https://docs.google.com/document/d/1ZEqVSc28YoiFJKDKlXgBfLHUSpYKfS1OIIgz4aVBOq0/edit?tab=t.0
>
>
> In consultation with our Area Director, all the comments were reviewed.  
> Almost all were accepted as is, a few were accepted in principle and the 
> proposed text was revised to accommodate.  There were a couple that were 
> rejected and those should have gotten a comment sent to them regarding why 
> the change was rejected.
>
> For ease of reference, here is the current charter of the REGEXT working 
> group:
>
> https://datatracker.ietf.org/group/regext/about/
>
> Please note, this revised proposed charter is still subject to IESG review.  
> While this version may represent our consensus, there may still be questions 
> and comments to be resolved from the IESG.
>
>
> Thanks again to all who reviewed the proposal.  The Chairs believe our 
> Charter overall is better now than it was and hopefully you agree.
>
> Antoin and Jim
>
> ___
> 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: [IANA #1419774] Swedish Internet Foundation IANA EPP registration

[Eric Skoglund]

Thanks Scott!

Agree with everything you said.

// Eric - The Swedish Internet Foundation

From: Hollenbeck, Scott 
Sent: 28 May 2025 15:41
To: iana-prot-param-comm...@iana.org 
Cc: regext@ietf.org 
Subject: [regext] Re: [IANA #1419774] Swedish Internet Foundation IANA EPP 
registration

(cc'ing the regext list)

David, this request looks fine. I recommend changing the name of the "Registry 
Lock" extension to something like "The Swedish Internet Foundation Registry 
Lock Extension" to avoid confusion with other potential registry lock 
extensions. I also recommend removing the old registry entry and replacing it 
with the two new entries to avoid confusion.

Scott

> -Original Message-
> From: David Dong via RT 
> Sent: Tuesday, May 27, 2025 4:29 PM
> Cc: Hollenbeck, Scott 
> Subject: [EXTERNAL] [IANA #1419774] Swedish Internet Foundation IANA
> EPP registration
>
> 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 Scott,
>
> As the designated expert for the Extensions for the Extensible Provisioning
> Protocol (EPP) registry, can you review the registration proposal below? If 
> this
> is OK, we'll make the registration in:
>
> https://secure-web.cisco.com/16Z7dH55IrqyJCEbhD0M2yOA_h_F27I0YF-
> zoUGh5ASHtUFAJpfq2_wi8rCwbx4iuyluczXlZo9y4S9JzVE_wiJW1l6GWi6qf88
> gUHN64lwQpgxY91ea0qnFtr9xfXctisR5q16C4bqissBvLdjM0JeoQB2N-
> ekwocewaJLDftQCJXxHhzAleHqk38xxAG351TqvNzAW4T4kQQpHRfjzFqJG57q
> P5f34UO4wHNpOmSxKxSUXl-
> 3iAHYBQWDTdO2vD79GcyJjWHpkbOOrwSPnE2QRk44-
> enklU2yiI9e1RVMA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fep
> p-extensions%2F
>
> They currently have a listing, which will be obsoleted by these two new
> registrations being made. Should we mark the existing ".SE extension" as
> obsoleted or remove it?
>
> The IESG has asked us to request that reviews be returned within two weeks,
> which in this case would make the due date June 10th. We'll consider your
> response to be the consensus response.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Tue May 27 08:35:09 2025, eric.skogl...@internetstiftelsen.se wrote:
> > Hello! I was informed that our information in the EPP registry is
> > currently not updated and points to a dead link. It currently sits
> > under the name ".SE extensions".
> > To accurately reflect the current state of affairs here is an update
> > that splits the extensions that live under different namespaces and
> > updates to the correct link pointing to the current specification.
> >
> > I also saw that the "Contact Information" section has us under the
> > name "Internet Infrastructure Foundation" which should be changed to
> > "The Swedish Internet Foundation"
> >
> > -BEGIN FORM-
> > Name of Extension:
> > "Swedish Internet Foundation EPP Extensions"
> >
> > Document Status:
> > Informal
> >
> > Reference:
> > https://secure-
> web.cisco.com/16YN8qDpHuE025EVR5FbT6iSGWllsWi1fkmtwrkBa
> >
> ZIbTffClR4DlL1xK8IbJsd4VF2OIpPr3iK3XHns6qLffudlsAu98G8OvUTfM5hh95i
> eMgt
> >
> fGZoG2lm85kYD3UhHhwtXiykBtxthLZzKIA2WNDwkUm8qkMXMdHKA1yAXp
> qqyxnj2ZTuAF
> > oaSyH37ohY47JqAH1k2swFfYo_dDnnKr-
> q_tgfLvwpH0APTmJi_R7jG3jtGUdxa6mqfg--
> >
> gMV9QRSqsMSpVnOef6EK5fbwSP330lH6PKEQWQsmKDY424In8/https%3A
> %2F%2Fsuppor
> > t.registry.se%2Fen-US%2Fdownloads%2Ffiles%2Fepp-protocol-
> > description-for-se-and-nu
> >
> > Registrant Name and Email Address:
> > The Swedish Internet Foundation, hostmas...@iis.se
> >
> > TLDs: se,nu
> >
> > IPR Disclosure: None
> >
> > Status: Active
> >
> > Notes: None
> > -END FORM-
> >
> >
> > -BEGIN FORM-
> > Name of Extension:
> > "Registry Lock"
> >
> > Document Status:
> > Informal
> >
> > Reference:
> > https://secure-
> web.cisco.com/16YN8qDpHuE025EVR5FbT6iSGWllsWi1fkmtwrkBa
> >
> ZIbTffClR4DlL1xK8IbJsd4VF2OIpPr3iK3XHns6qLffudlsAu98G8OvUTfM5hh95i
> eMgt
> >
> fGZoG2lm85kYD3UhHhwtXiykBtxthLZzKIA2WNDwkUm8qkMXMdHKA1yAXp
> qqyxnj2ZTuAF
> > oaSyH37ohY47JqAH1k2swFfYo_dDnnKr-
> q_tgfLvwpH0APTmJi_R7jG3jtGUdxa6mqfg--
> >
> gMV9QRSqsMSpVnOef6EK5fbwSP330lH6PKEQWQsmKDY424In8/https%3A
> %2F%2Fsuppor
> > t.registry.se%2Fen-US%2Fdownloads%2Ffiles%2Fepp-protocol-
> > description-for-se-and-nu
> >
> > Registrant Name and Email Address:
> > The Swedish Internet Foundation, hostmas...@iis.se
> >
> > TLDs: se,nu
> >
> > IPR Disclosure: None
> >
> > Status: Active
> >
> > Notes: None
> > -END FORM-
> >
> > EPP - Protocol description for .se and
> > .nu web.cisco.com/16YN8qDpHuE025EVR5FbT6iSGWllsWi1fkmtw
> >
> rkBaZIbTffClR4DlL1xK8IbJsd4VF2OIpPr3iK3XHns6qLffudlsAu98G8OvUTfM5h
> h95i
> >
> eMgtfGZoG2lm85kYD3UhHhwtXiykBtxthLZzKIA2WNDwkUm8qkMXMdHKA1
> yAXpqqyxnj2Z
> > TuAFoaSyH37ohY47JqAH1k2swFfYo_dDnnKr-
> q_tgfLvwpH0APTmJi_R7jG3jtGUdxa6mq
> > fg--
> gMV9QRSqsMSpVnOef6EK5fbwSP330lH6PKEQWQsmKDY424In8/https%3A
> %2F%2Fsu
> > pport.registry.se%2Fe

[regext] Re: EXTENDED CALL FOR ADOPTION: draft-brown-rdap-ttl-extension

[Eric Skoglund]

+1 for adoption

// Eric

From: Jorge Cano 
Sent: 07 July 2025 17:15
To: regext@ietf.org 
Subject: [regext] EXTENDED CALL FOR ADOPTION: draft-brown-rdap-ttl-extension

Hi all,

This is an extended adoption request for RDAP Extension for DNS
Time-To-Live:

 https://datatracker.ietf.org/doc/draft-brown-rdap-ttl-extension/

We received only a few responses to this call for adoption, so we are
extending the deadline for one week. It's crucial that we know the
group's thoughts about this document to proceed.

Please review this draft to see if you think it is suitable for adoption
by REGEXT and comment to this message on the list, clearly stating your
view.

This Extended Call For Adoption will close on Sunday, July 13.

Thanks,
Your REGEXT co-chairs Antoin, Jim, and Jorge



On 23/06/25 9:30 AM, Jorge Cano wrote:
> Hi all,
>
> This is a formal adoption request for RDAP Extension for DNS
> Time-To-Live:
>
> https://datatracker.ietf.org/doc/draft-brown-rdap-ttl-extension/
>
> Please review this draft to see if you think it is suitable for
> adoption by REGEXT and comment to this message on the list, clearly
> stating your view.
>
> Optionally indicate if you are willing to contribute text, review
> text, or be a document shepherd.
>
> This Call For Adoption will close on Sunday, 6 July.
>
> If there are no objections, the chairs will consider this document
> adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Antoin, Jim and Jorge
>
> ___
> 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